Solicitamos a la convocante precisar el volumen mensual estimado de tráfico HTTP/HTTPS a proteger (TB/mes), con promedio y picos. Esta métrica impacta directamente en el dimensionamiento y licenciamiento de la plataforma WAAP.
Solicitamos a la convocante precisar el volumen mensual estimado de tráfico HTTP/HTTPS a proteger (TB/mes), con promedio y picos. Esta métrica impacta directamente en el dimensionamiento y licenciamiento de la plataforma WAAP.
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: El tráfico aproximado seria de ±10 Gbps/mes
12
11) Métrica de solicitudes (requests)
Solicitamos el total de solicitudes mensuales y los picos de RPS (tanto global como por aplicación). Esta información es crucial, ya que ciertos módulos, como la gestión de bots y la limitación de tasas (rate limiting), se licencian por volumen de solicitudes o picos de RPS.
Solicitamos el total de solicitudes mensuales y los picos de RPS (tanto global como por aplicación). Esta información es crucial, ya que ciertos módulos, como la gestión de bots y la limitación de tasas (rate limiting), se licencian por volumen de solicitudes o picos de RPS.
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: La cantidad aproximada de solicitudes mensuales global seria de ±25.000.000
13
12) Distribución de políticas
“El portal de servicios debe permitir la distribución de una política de seguridad de una aplicación a otra permitiendo configurar la distribución de forma periódica.”
Solicitamos a la convocante modificar el texto, ya que la exigencia de que la distribución sea de forma “periódica” presupone un mecanismo de programación automática en el portal que no es necesario en todos los fabricantes o no están disponibles, lo cual limita la participación de más oferentes.
“El portal de servicios debe permitir la distribución de una política de seguridad de una aplicación a otra permitiendo configurar la distribución de forma periódica.”
Solicitamos a la convocante modificar el texto, ya que la exigencia de que la distribución sea de forma “periódica” presupone un mecanismo de programación automática en el portal que no es necesario en todos los fabricantes o no están disponibles, lo cual limita la participación de más oferentes.
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: Remítase a lo establecido en Adenda Nº:1.
14
13) Nivel de Partner
Solicitamos a la convocante modificar el requerimiento “Debido a la criticidad del servicio, el proveedor local deberá contar con el mayor nivel de certificación/partnership de la marca ofertada, para garantizar el buen servicio y respaldo del soporte local.”
Solicitamos a la convocante modificar este requerimiento, ya que condicionar la calificación del proveedor local al “mayor nivel de partnership” responde principalmente a criterios comerciales y no necesariamente refleja la capacidad técnica ni la calidad del servicio que se prestará al cliente.
Lo que mejor asegura la calidad de un proveedor es su experiencia real en proyectos críticos y el nivel de certificación técnica de su personal y del proveedor.
Solicitamos a la convocante modificar el requerimiento “Debido a la criticidad del servicio, el proveedor local deberá contar con el mayor nivel de certificación/partnership de la marca ofertada, para garantizar el buen servicio y respaldo del soporte local.”
Solicitamos a la convocante modificar este requerimiento, ya que condicionar la calificación del proveedor local al “mayor nivel de partnership” responde principalmente a criterios comerciales y no necesariamente refleja la capacidad técnica ni la calidad del servicio que se prestará al cliente.
Lo que mejor asegura la calidad de un proveedor es su experiencia real en proyectos críticos y el nivel de certificación técnica de su personal y del proveedor.
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: Remitirse a lo establecido en el Pliego de Bases y Condiciones publicado.
15
14) Certificación Técnica
Solicitamos que el requerimiento “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” Solicitamos a la convocante modificar este requerimiento, ya que contar únicamente con 2 técnicos certificados resulta insuficiente para un servicio que debe brindarse 24x7x365. Ante permisos, turnos rotativos o indisponibilidades, se pone en riesgo el tiempo de respuesta.
Solicitamos que el requerimiento “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” Solicitamos a la convocante modificar este requerimiento, ya que contar únicamente con 2 técnicos certificados resulta insuficiente para un servicio que debe brindarse 24x7x365. Ante permisos, turnos rotativos o indisponibilidades, se pone en riesgo el tiempo de respuesta.
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: Remitirse a lo establecido en el Pliego de Bases y Condiciones publicado.
16
Requerimientos Experiencia
se solicita:
El proveedor debe pertenecer a rubros relacionados a Tecnologías de la Información y Comunicación, específicamente a desarrollo, mantenimiento y/o implementación de software, comprobable con en el objeto de su Constitución o Constancia de RUC.
Experiencia mínima de tres (3) años (2022, 2023 y 2024) demostrable en el rubro de software orientado a la ciberseguridad, específicamente trabajos relacionados al objeto de la contratación.
Presentar diez (10) referencias verificables, cumpliendo con lo siguiente:
1. Cada referencia deberá corresponder a trabajos relacionados a desarrollo, implementación y/o actualización de software relacionados al objeto de la contratación (pudiendo ser en el marco de la provisión de otros bienes o servicios TIC, pero demostrable en cada caso).
2. Constancias, facturas y/o contratos emitidos por entidades privadas, públicas y/o mixtas de al menos tres (3) provisiones, instalaciones y/o actualizaciones relacionados al objeto de la contratación en infraestructuras dentro del territorio nacional,
3. Cumplir al menos uno de los siguientes requisitos:
a) La sumatoria de referencias representa mínimo el sesenta por ciento (60%) del monto referencial de la contratación.
b) Una referencia individual representa al menos el cuarenta por ciento (40%) del monto referencial.
La Convocante sumará el monto indicado en cada documento para verificar el cumplimiento de este requisito.
La evaluación se realizará aplicando el sistema CUMPLE o NO CUMPLE.
Consulta1: en el punto 1 es que solicitan 10 referencias verificables, pero el punto 2 solicitan 3 constancias, estas ultimas 3 constancias forman parte de las 10 referencias verificables?
Consulta 2: Cuando mencionan relacionados al objeto de la contratación ¿a que hacen referencia?
se solicita:
El proveedor debe pertenecer a rubros relacionados a Tecnologías de la Información y Comunicación, específicamente a desarrollo, mantenimiento y/o implementación de software, comprobable con en el objeto de su Constitución o Constancia de RUC.
Experiencia mínima de tres (3) años (2022, 2023 y 2024) demostrable en el rubro de software orientado a la ciberseguridad, específicamente trabajos relacionados al objeto de la contratación.
Presentar diez (10) referencias verificables, cumpliendo con lo siguiente:
1. Cada referencia deberá corresponder a trabajos relacionados a desarrollo, implementación y/o actualización de software relacionados al objeto de la contratación (pudiendo ser en el marco de la provisión de otros bienes o servicios TIC, pero demostrable en cada caso).
2. Constancias, facturas y/o contratos emitidos por entidades privadas, públicas y/o mixtas de al menos tres (3) provisiones, instalaciones y/o actualizaciones relacionados al objeto de la contratación en infraestructuras dentro del territorio nacional,
3. Cumplir al menos uno de los siguientes requisitos:
a) La sumatoria de referencias representa mínimo el sesenta por ciento (60%) del monto referencial de la contratación.
b) Una referencia individual representa al menos el cuarenta por ciento (40%) del monto referencial.
La Convocante sumará el monto indicado en cada documento para verificar el cumplimiento de este requisito.
La evaluación se realizará aplicando el sistema CUMPLE o NO CUMPLE.
Consulta1: en el punto 1 es que solicitan 10 referencias verificables, pero el punto 2 solicitan 3 constancias, estas ultimas 3 constancias forman parte de las 10 referencias verificables?
Consulta 2: Cuando mencionan relacionados al objeto de la contratación ¿a que hacen referencia?
Sírvanse considerar para la elaboración de sus ofertas lo siguiente:
Consulta 1: Las 3 constancias forman parte de las 10 referencias verificables.
Consulta 2: "Relacionados al objeto de la contratación" se refiere a trabajos de desarrollo, implementación y/o actualización de software de ciberseguridad
17
EETT
Donde DICE:
2 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.
Solicitamos amablemente este requerimiento fuera OPCIONAL atendiendo que:
No es requisito de seguridad indispensable
Limita la concurrencia de oferentes: Exigir obligatoriamente un modelo API restringe innecesariamente la participación de proveedores.Algunas marcas líderes (Fortinet, Palo Alto, F5, Check Point, Radware, etc.) ofrecen mecanismos equivalentes que no requieren, y al imponerlo como requisito obligatorio se descartan soluciones robustas y probadas.
Interoperabilidad y flexibilidad: Al dejarlo como opcional, se permite que el oferente proponga la arquitectura más adecuada (API o tradicional) de acuerdo con la infraestructura existente del cliente.
Donde DICE:
2 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.
Solicitamos amablemente este requerimiento fuera OPCIONAL atendiendo que:
No es requisito de seguridad indispensable
Limita la concurrencia de oferentes: Exigir obligatoriamente un modelo API restringe innecesariamente la participación de proveedores.Algunas marcas líderes (Fortinet, Palo Alto, F5, Check Point, Radware, etc.) ofrecen mecanismos equivalentes que no requieren, y al imponerlo como requisito obligatorio se descartan soluciones robustas y probadas.
Interoperabilidad y flexibilidad: Al dejarlo como opcional, se permite que el oferente proponga la arquitectura más adecuada (API o tradicional) de acuerdo con la infraestructura existente del cliente.
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: Remítase a lo establecido en Adenda Nº:1.
18
EETT
Donde DICE:
16 La solución debe proveer una página de bloqueo por defecto la cual es mostrada a usuarios identificados como atacantes que intentan acceder la aplicación, debe permitir también la opción de personalizar la página de bloqueo por medio de redireccionamiento a un sitio web específico.
Solicitamos amablemente este requerimiento fuera OPCIONAL atendiendo que se trata de una característica cosmética o de conveniencia operativa, no un requisito esencial de seguridad.
La funcionalidad de mostrar o personalizar una página de bloqueo no es indispensable para la protección de aplicaciones.
El objetivo de seguridad (bloquear al atacante) se cumple igualmente con un simple rechazo de conexión o código de error estándar.
De esta manera se garantiza seguridad efectiva, sin limitar innecesariamente la concurrencia de oferentes
Donde DICE:
16 La solución debe proveer una página de bloqueo por defecto la cual es mostrada a usuarios identificados como atacantes que intentan acceder la aplicación, debe permitir también la opción de personalizar la página de bloqueo por medio de redireccionamiento a un sitio web específico.
Solicitamos amablemente este requerimiento fuera OPCIONAL atendiendo que se trata de una característica cosmética o de conveniencia operativa, no un requisito esencial de seguridad.
La funcionalidad de mostrar o personalizar una página de bloqueo no es indispensable para la protección de aplicaciones.
El objetivo de seguridad (bloquear al atacante) se cumple igualmente con un simple rechazo de conexión o código de error estándar.
De esta manera se garantiza seguridad efectiva, sin limitar innecesariamente la concurrencia de oferentes
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: Remítase a lo establecido en Adenda Nº:1.
19
EETT
Donde DICE:
23 La solución debe contar con un mecanismo que permita visualizar los subdominios y/o URLs que invocan los scripts de java (JS) desde el navegador de los usuarios que consumen las aplicaciones, así como el nivel de amenaza de los mismos y si es que estos cuentan o no con certificados de seguridad.
Solicitamos amablemente este requerimiento pueda contemplar alternativas de soluciones como HTTP Header Protection, CSRF Protection, MiTB Defense, Cookie Security y Bot Mitigation.
El objetivo principal del requerimiento es proteger la integridad de las aplicaciones frente a amenazas en el navegador del usuario y la ejecución de scripts externos.
Los mecanismos mencionados (HTTP headers, CSRF, MiTB Defense, Cookie Security, Bot Mitigation) cumplen la misma función de prevención de explotación de scripts, robo de datos o manipulación del navegador.
Donde DICE:
23 La solución debe contar con un mecanismo que permita visualizar los subdominios y/o URLs que invocan los scripts de java (JS) desde el navegador de los usuarios que consumen las aplicaciones, así como el nivel de amenaza de los mismos y si es que estos cuentan o no con certificados de seguridad.
Solicitamos amablemente este requerimiento pueda contemplar alternativas de soluciones como HTTP Header Protection, CSRF Protection, MiTB Defense, Cookie Security y Bot Mitigation.
El objetivo principal del requerimiento es proteger la integridad de las aplicaciones frente a amenazas en el navegador del usuario y la ejecución de scripts externos.
Los mecanismos mencionados (HTTP headers, CSRF, MiTB Defense, Cookie Security, Bot Mitigation) cumplen la misma función de prevención de explotación de scripts, robo de datos o manipulación del navegador.
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: Remitirse a lo establecido en el Pliego de Bases y Condiciones publicado.
20
EETT
Donde DICE:
24 La protección del lado del cliente debe proveer el descubrimiento y monitoreo continuo de todos los servicios de terceros, incluyendo un seguimiento detallado de las actividades.
Solicitamos amablemente este requerimiento fuera OPCIONAL atendiendo que si bien es una funcionalidad interesante, no constituye un requisito de seguridad esencial ni universal en la mayoría de arquitecturas actuales de protección de aplicaciones.
También de esta forma se asegura mayor flexibilidad, más competencia en la licitación y optimización de costos, sin afectar el nivel de seguridad requerido.
Donde DICE:
24 La protección del lado del cliente debe proveer el descubrimiento y monitoreo continuo de todos los servicios de terceros, incluyendo un seguimiento detallado de las actividades.
Solicitamos amablemente este requerimiento fuera OPCIONAL atendiendo que si bien es una funcionalidad interesante, no constituye un requisito de seguridad esencial ni universal en la mayoría de arquitecturas actuales de protección de aplicaciones.
También de esta forma se asegura mayor flexibilidad, más competencia en la licitación y optimización de costos, sin afectar el nivel de seguridad requerido.
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 requisito de seguridad proactiva en entornos cloud.