Exigencia de Certificación ISO 27001:2013 como requisito de Capacidad Técnica
¿De qué manera la Convocante justifica la pertinencia y proporcionalidad de la exigencia del ISO 27001:2013 dentro de un proceso orientado al suministro e instalación de cableado estructurado, y si considera viable sustituir dicha exigencia por certificaciones equivalentes (p. ej., ISO 9001 u otras que acrediten la capacidad técnica del oferente), conforme al principio de libre concurrencia establecido en el artículo 40 de la Ley 7021/22?
Análisis técnico-normativo:
En el apartado de Capacidad Técnica, se exige que el oferente cuente con certificación ISO 27001:2013 o superior.
Dicha exigencia constituye una barrera de entrada innecesaria, puesto que la norma ISO 27001 regula sistemas de gestión de seguridad de la información, y no guarda relación directa con las actividades de instalación o mantenimiento de cableado estructurado, objeto del presente llamado.
La restricción impuesta carece de proporcionalidad y vulnera el principio de libre concurrencia previsto en el artículo 40 de la Ley 7021/22, al limitar injustificadamente la participación de oferentes calificados que no cuentan con dicha certificación, pero sí con estándares equivalentes como ISO 9001:2015 (Gestión de Calidad) u otras acreditaciones técnicas aplicables al rubro.
El requisito, además de no garantizar una mejor calidad en la ejecución del contrato, favorece indirectamente a empresas que ya poseen dicha certificación, generando un posible direccionamiento del procedimiento y afectando los principios de igualdad, razonabilidad y valor por dinero.
10-10-2025
14-10-2025
Exigencia de Certificación ISO 27001:2013 como requisito de Capacidad Técnica
¿De qué manera la Convocante justifica la pertinencia y proporcionalidad de la exigencia del ISO 27001:2013 dentro de un proceso orientado al suministro e instalación de cableado estructurado, y si considera viable sustituir dicha exigencia por certificaciones equivalentes (p. ej., ISO 9001 u otras que acrediten la capacidad técnica del oferente), conforme al principio de libre concurrencia establecido en el artículo 40 de la Ley 7021/22?
Análisis técnico-normativo:
En el apartado de Capacidad Técnica, se exige que el oferente cuente con certificación ISO 27001:2013 o superior.
Dicha exigencia constituye una barrera de entrada innecesaria, puesto que la norma ISO 27001 regula sistemas de gestión de seguridad de la información, y no guarda relación directa con las actividades de instalación o mantenimiento de cableado estructurado, objeto del presente llamado.
La restricción impuesta carece de proporcionalidad y vulnera el principio de libre concurrencia previsto en el artículo 40 de la Ley 7021/22, al limitar injustificadamente la participación de oferentes calificados que no cuentan con dicha certificación, pero sí con estándares equivalentes como ISO 9001:2015 (Gestión de Calidad) u otras acreditaciones técnicas aplicables al rubro.
El requisito, además de no garantizar una mejor calidad en la ejecución del contrato, favorece indirectamente a empresas que ya poseen dicha certificación, generando un posible direccionamiento del procedimiento y afectando los principios de igualdad, razonabilidad y valor por dinero.
Remítase al PBC. Se mantiene la exigencia de contar con la certificación ISO 27001.
32
Aclaración sobre el parámetro de Throughput IPSec exigido en el Ítem 3.2.1 (Firewall)
¿Podría la Convocante aclarar si el valor de Throughput IPSec de 10 Gbps corresponde al rendimiento agregado bidireccional (cifrado + descifrado) o al valor unidireccional efectivo medido bajo condiciones de laboratorio (RFC 2544/IMIX)? Asimismo, considerando las prácticas internacionales de benchmarking y la escala del presente llamado, ¿resultaría viable ajustar el valor mínimo exigido a 5 Gbps efectivos, garantizando la participación de equipos de categoría Enterprise que ofrezcan mayor protección, estabilidad y eficiencia energética, en coherencia con los principios de razonabilidad y valor por dinero establecidos en los artículos 4 y 40 de la Ley 7021/22?
Análisis técnico-normativo:
En el Ítem 3.2.1 – Firewall, el pliego exige que el equipo ofertado cuente con Throughput IPSec mínimo de 10 Gbps.
Sin embargo, la especificación carece de precisión técnica respecto al método de medición (si corresponde al throughput agregado en modo bidireccional —cifrado y descifrado simultáneo— o al valor unidireccional bajo condiciones controladas).
La ausencia de aclaración metodológica puede generar interpretaciones dispares y restringir la participación de oferentes cuyos equipos, aun sin alcanzar los 10 Gbps de throughput IPSec, superan los niveles de desempeño general, seguridad y eficiencia energética, ofreciendo una relación costo-beneficio más favorable al Estado.
El principio de razonabilidad (art. 4 inc. k) de la Ley 7021/22) exige que los parámetros técnicos guarden proporción con la magnitud del objeto y no excluyan soluciones tecnológicamente equivalentes. En este sentido, equipos de categoría Enterprise con throughput de firewall superior a 10 Gbps y throughput IPSec efectivo de 5 Gbps —medido según prácticas internacionales como RFC 2544 o perfiles IMIX— satisfacen los requerimientos funcionales del llamado, garantizando eficiencia, seguridad y sostenibilidad energética.
Por tanto, mantener un umbral rígido de 10 Gbps podría constituir una barrera técnica injustificada, limitando la competencia y contrariando los principios de valor por dinero y eficiencia en el gasto público previstos por la Ley 7021/22 y el Decreto 2264/24.
10-10-2025
14-10-2025
Aclaración sobre el parámetro de Throughput IPSec exigido en el Ítem 3.2.1 (Firewall)
¿Podría la Convocante aclarar si el valor de Throughput IPSec de 10 Gbps corresponde al rendimiento agregado bidireccional (cifrado + descifrado) o al valor unidireccional efectivo medido bajo condiciones de laboratorio (RFC 2544/IMIX)? Asimismo, considerando las prácticas internacionales de benchmarking y la escala del presente llamado, ¿resultaría viable ajustar el valor mínimo exigido a 5 Gbps efectivos, garantizando la participación de equipos de categoría Enterprise que ofrezcan mayor protección, estabilidad y eficiencia energética, en coherencia con los principios de razonabilidad y valor por dinero establecidos en los artículos 4 y 40 de la Ley 7021/22?
Análisis técnico-normativo:
En el Ítem 3.2.1 – Firewall, el pliego exige que el equipo ofertado cuente con Throughput IPSec mínimo de 10 Gbps.
Sin embargo, la especificación carece de precisión técnica respecto al método de medición (si corresponde al throughput agregado en modo bidireccional —cifrado y descifrado simultáneo— o al valor unidireccional bajo condiciones controladas).
La ausencia de aclaración metodológica puede generar interpretaciones dispares y restringir la participación de oferentes cuyos equipos, aun sin alcanzar los 10 Gbps de throughput IPSec, superan los niveles de desempeño general, seguridad y eficiencia energética, ofreciendo una relación costo-beneficio más favorable al Estado.
El principio de razonabilidad (art. 4 inc. k) de la Ley 7021/22) exige que los parámetros técnicos guarden proporción con la magnitud del objeto y no excluyan soluciones tecnológicamente equivalentes. En este sentido, equipos de categoría Enterprise con throughput de firewall superior a 10 Gbps y throughput IPSec efectivo de 5 Gbps —medido según prácticas internacionales como RFC 2544 o perfiles IMIX— satisfacen los requerimientos funcionales del llamado, garantizando eficiencia, seguridad y sostenibilidad energética.
Por tanto, mantener un umbral rígido de 10 Gbps podría constituir una barrera técnica injustificada, limitando la competencia y contrariando los principios de valor por dinero y eficiencia en el gasto público previstos por la Ley 7021/22 y el Decreto 2264/24.
Remitirse al PBC. Se aclara que el requerimiento corresponde al valor del rendimiento unidireccional efectivo, determinado mediante pruebas de laboratorio realizadas con tamaños de paquete fijos o mixtos.
33
Exigencia de experiencia en proyectos de gran envergadura (150 puntos de red y 200 m de fibra óptica)
¿Considerará la Convocante la aceptación de la sumatoria de contratos menores realizados en el mismo período de tiempo como medio válido de acreditación de experiencia, y la extensión del plazo de evaluación de años para favorecer la libre concurrencia y evitar el direccionamiento del proceso, conforme a los principios de igualdad, razonabilidad y valor por dinero previstos en los artículos 4 y 40 de la Ley 7021/22?
Análisis técnico-normativo:
El pliego exige acreditar experiencia previa en proyectos con un mínimo de 150 puntos de red y 200 metros de fibra óptica. Tal requerimiento resulta desproporcionado respecto al objeto del llamado, ya que no guarda relación directa con la complejidad ni el volumen de trabajo que se demanda.
La limitación a contratos de gran envergadura restringe innecesariamente la participación de oferentes locales y MIPYMES, contraviniendo el principio de libre concurrencia (art. 40 de la Ley 7021/22) y el principio de valor por dinero, ya que la experiencia acumulada en contratos de menor escala puede reflejar idéntica competencia técnica y capacidad de cumplimiento.
El Decreto 2264/24 refuerza que los requisitos de participación deben responder a criterios de pertinencia y proporcionalidad, evitando exigencias que generen barreras de entrada o direccionamiento. Asimismo, la DNCP tiene facultades para verificar la razonabilidad de las condiciones establecidas por la convocante cuando estas limiten la competencia efectiva en el mercado público.
Por ello, resulta procedente permitir que los oferentes acrediten su experiencia mediante la sumatoria de contratos menores dentro del mismo período de tiempo, si estos en conjunto alcanzan la cantidad de puntos de red y metros de fibra requeridos, así como extender el plazo temporal de evaluación de experiencia para ampliar la concurrencia y promover la participación de empresas nacionales competitivas.
10-10-2025
14-10-2025
Exigencia de experiencia en proyectos de gran envergadura (150 puntos de red y 200 m de fibra óptica)
¿Considerará la Convocante la aceptación de la sumatoria de contratos menores realizados en el mismo período de tiempo como medio válido de acreditación de experiencia, y la extensión del plazo de evaluación de años para favorecer la libre concurrencia y evitar el direccionamiento del proceso, conforme a los principios de igualdad, razonabilidad y valor por dinero previstos en los artículos 4 y 40 de la Ley 7021/22?
Análisis técnico-normativo:
El pliego exige acreditar experiencia previa en proyectos con un mínimo de 150 puntos de red y 200 metros de fibra óptica. Tal requerimiento resulta desproporcionado respecto al objeto del llamado, ya que no guarda relación directa con la complejidad ni el volumen de trabajo que se demanda.
La limitación a contratos de gran envergadura restringe innecesariamente la participación de oferentes locales y MIPYMES, contraviniendo el principio de libre concurrencia (art. 40 de la Ley 7021/22) y el principio de valor por dinero, ya que la experiencia acumulada en contratos de menor escala puede reflejar idéntica competencia técnica y capacidad de cumplimiento.
El Decreto 2264/24 refuerza que los requisitos de participación deben responder a criterios de pertinencia y proporcionalidad, evitando exigencias que generen barreras de entrada o direccionamiento. Asimismo, la DNCP tiene facultades para verificar la razonabilidad de las condiciones establecidas por la convocante cuando estas limiten la competencia efectiva en el mercado público.
Por ello, resulta procedente permitir que los oferentes acrediten su experiencia mediante la sumatoria de contratos menores dentro del mismo período de tiempo, si estos en conjunto alcanzan la cantidad de puntos de red y metros de fibra requeridos, así como extender el plazo temporal de evaluación de experiencia para ampliar la concurrencia y promover la participación de empresas nacionales competitivas.
Remitirse al PBC. La Convocante ha establecido un rango de tiempo considerable para permitir acreditar las experiencias solicitadas, no se permitiran las sumatorias.
34
Aclaración sobre el alcance del requisito de “análisis heurístico” en la clasificación de aplicaciones (Ítem 3.2.1 – Firewall)
¿Podrá la Convocante aclarar si el requerimiento de “análisis heurístico” incluye también la detección y clasificación de amenazas, en cuyo caso debería contemplarse el uso de sandboxing como mecanismo de análisis dinámico?
En caso afirmativo, y con el fin de alinear el pliego con las mejores prácticas internacionales en seguridad perimetral, se propone sustituir el texto actual por la siguiente redacción:
“El equipo deberá soportar múltiples métodos de identificación y clasificación de aplicaciones, incluyendo chequeo de firmas, decodificación de protocolos, análisis heurístico y análisis dinámico en sandbox, para detección avanzada de amenazas y comportamientos anómalos.”
Esta modificación asegura claridad técnica, promueve la adopción de estándares internacionales en seguridad y refuerza los principios de eficiencia, razonabilidad y valor por dinero establecidos en los artículos 4° y 40° de la Ley 7021/22.
Análisis técnico-normativo:
El pliego, en el Ítem 3.2.1 – Firewall, dispone:
“Deberá soportar múltiples métodos de identificación y clasificación de las aplicaciones, por lo menos chequeo de firmas, decodificación de protocolos y análisis heurístico.”
El término “análisis heurístico” posee un alcance amplio y puede referirse tanto a la detección basada en patrones de comportamiento (estática o predictiva) como a la ejecución controlada en entornos seguros (sandboxing), utilizada para identificar amenazas desconocidas o variantes de malware de tipo zero-day.
Los firewalls de próxima generación (NGFW) de clase empresarial implementan precisamente mecanismos de sandbox como extensión del análisis heurístico, permitiendo realizar inspección dinámica de archivos y flujos sospechosos en entornos aislados. Este enfoque complementa el motor de detección estática y es recomendado por los estándares internacionales en materia de ciberseguridad, tales como:
NIST SP 800-94 (“Guide to Intrusion Detection and Prevention Systems”),
ISO/IEC 27002:2022, y
Best Practices for Next-Generation Firewalls (Gartner & MITRE ATT&CK Framework).
Por tanto, la ausencia de mención expresa al sandboxing podría generar ambigüedad interpretativa sobre el alcance funcional requerido, limitando la posibilidad de incorporar soluciones con detección dinámica avanzada y protección proactiva frente a amenazas emergentes.
De conformidad con el principio de razonabilidad (art. 4 inc. k) y la obligación de especificar de forma clara, objetiva y proporcional, resulta pertinente que la Convocante aclare o modifique el requisito a fin de explicitar la inclusión del sandbox como herramienta de detección heurística avanzada.
10-10-2025
14-10-2025
Aclaración sobre el alcance del requisito de “análisis heurístico” en la clasificación de aplicaciones (Ítem 3.2.1 – Firewall)
¿Podrá la Convocante aclarar si el requerimiento de “análisis heurístico” incluye también la detección y clasificación de amenazas, en cuyo caso debería contemplarse el uso de sandboxing como mecanismo de análisis dinámico?
En caso afirmativo, y con el fin de alinear el pliego con las mejores prácticas internacionales en seguridad perimetral, se propone sustituir el texto actual por la siguiente redacción:
“El equipo deberá soportar múltiples métodos de identificación y clasificación de aplicaciones, incluyendo chequeo de firmas, decodificación de protocolos, análisis heurístico y análisis dinámico en sandbox, para detección avanzada de amenazas y comportamientos anómalos.”
Esta modificación asegura claridad técnica, promueve la adopción de estándares internacionales en seguridad y refuerza los principios de eficiencia, razonabilidad y valor por dinero establecidos en los artículos 4° y 40° de la Ley 7021/22.
Análisis técnico-normativo:
El pliego, en el Ítem 3.2.1 – Firewall, dispone:
“Deberá soportar múltiples métodos de identificación y clasificación de las aplicaciones, por lo menos chequeo de firmas, decodificación de protocolos y análisis heurístico.”
El término “análisis heurístico” posee un alcance amplio y puede referirse tanto a la detección basada en patrones de comportamiento (estática o predictiva) como a la ejecución controlada en entornos seguros (sandboxing), utilizada para identificar amenazas desconocidas o variantes de malware de tipo zero-day.
Los firewalls de próxima generación (NGFW) de clase empresarial implementan precisamente mecanismos de sandbox como extensión del análisis heurístico, permitiendo realizar inspección dinámica de archivos y flujos sospechosos en entornos aislados. Este enfoque complementa el motor de detección estática y es recomendado por los estándares internacionales en materia de ciberseguridad, tales como:
NIST SP 800-94 (“Guide to Intrusion Detection and Prevention Systems”),
ISO/IEC 27002:2022, y
Best Practices for Next-Generation Firewalls (Gartner & MITRE ATT&CK Framework).
Por tanto, la ausencia de mención expresa al sandboxing podría generar ambigüedad interpretativa sobre el alcance funcional requerido, limitando la posibilidad de incorporar soluciones con detección dinámica avanzada y protección proactiva frente a amenazas emergentes.
De conformidad con el principio de razonabilidad (art. 4 inc. k) y la obligación de especificar de forma clara, objetiva y proporcional, resulta pertinente que la Convocante aclare o modifique el requisito a fin de explicitar la inclusión del sandbox como herramienta de detección heurística avanzada.
Remitirse al PBC. El análisis heurístico comprende técnicas de identificación y clasificación basadas en comportamiento, sin que ello implique restricción alguna respecto a los mecanismos o metodologías de implementación. Se ratifica que la capacidad requerida esta disponible para multiples fabricantes.
35
Aclaración y modificación del requerimiento sobre bloqueo de vulnerabilidades y exploits conocidos (Ítem 3.2.1 – Firewall)
¿Podrá la Convocante aclarar si el requerimiento de “bloqueo de vulnerabilidades” y “bloqueo de exploits conocidos” se refiere a la funcionalidad general del motor IPS/Threat Protection, en cuyo caso resultaría procedente reformular el texto en términos genéricos y técnicamente neutrales?
Se propone la siguiente redacción alternativa, más precisa y acorde con las prácticas internacionales del sector:
“El equipo deberá contar con un motor de prevención de intrusiones (IPS) capaz de detectar y bloquear ataques, exploits y vulnerabilidades conocidas, incluyendo firmas IPS actualizables y mecanismos de protección contra amenazas emergentes.”
Esta modificación mantiene intacto el objetivo de seguridad, evita el direccionamiento hacia un fabricante específico y cumple con los principios de razonabilidad, neutralidad tecnológica, igualdad y valor por dinero establecidos en los artículos 4° y 40° de la Ley 7021/22.
Análisis técnico-normativo:
En el Ítem 3.2.1 – Firewall, el pliego establece los siguientes requerimientos:
“Debe permitir el bloqueo de vulnerabilidades. Deberá permitir el bloqueo de exploits conocidos.”
La terminología empleada en ambos puntos no refleja la nomenclatura técnica estándar del mercado, sino que corresponde textualmente a la utilizada por un fabricante específico (Fortinet) en sus hojas de datos y fichas técnicas públicas —en particular, los modelos FortiGate 100F / 200F—.
Esta coincidencia literal evidencia un posible direccionamiento del pliego hacia una marca y oferente determinados, vulnerando los principios de igualdad, libre competencia y neutralidad tecnológica previstos en los artículos 4° y 40° de la Ley 7021/22.
Desde el punto de vista técnico, todos los Sistemas de Prevención de Intrusiones (IPS) de clase empresarial poseen la capacidad de detectar y bloquear exploits y vulnerabilidades conocidas, pero lo hacen a través de mecanismos de detección basados en firmas, correlación de patrones, análisis de comportamiento, inteligencia de amenazas (Threat Intelligence Feeds) y técnicas de mitigación activa, sin utilizar necesariamente la denominación literal de “bloqueo de vulnerabilidades” o “bloqueo de exploits conocidos”.
En las fichas técnicas de otros fabricantes líderes (p. ej. Palo Alto Networks, Check Point, Sophos, Cisco, Huawei, WatchGuard, entre otros), estas capacidades se documentan como:
“Intrusion Prevention / Threat Protection / Exploit Detection and Mitigation”,
o bien como parte del módulo de “Advanced Threat Prevention (ATP)”.
Por tanto, lo que debe verificarse no es la coincidencia semántica con el término empleado, sino la capacidad funcional efectiva del equipo de prevenir, detectar y bloquear amenazas y exploits mediante firmas IPS actualizables y análisis avanzado.
De acuerdo con el principio de razonabilidad (art. 4 inc. k) y el Decreto 2264/24, la DNCP y las convocantes deben formular especificaciones que sean técnicamente objetivas, verificables y neutrales, evitando el uso de terminología propia de una marca comercial.
10-10-2025
14-10-2025
Aclaración y modificación del requerimiento sobre bloqueo de vulnerabilidades y exploits conocidos (Ítem 3.2.1 – Firewall)
¿Podrá la Convocante aclarar si el requerimiento de “bloqueo de vulnerabilidades” y “bloqueo de exploits conocidos” se refiere a la funcionalidad general del motor IPS/Threat Protection, en cuyo caso resultaría procedente reformular el texto en términos genéricos y técnicamente neutrales?
Se propone la siguiente redacción alternativa, más precisa y acorde con las prácticas internacionales del sector:
“El equipo deberá contar con un motor de prevención de intrusiones (IPS) capaz de detectar y bloquear ataques, exploits y vulnerabilidades conocidas, incluyendo firmas IPS actualizables y mecanismos de protección contra amenazas emergentes.”
Esta modificación mantiene intacto el objetivo de seguridad, evita el direccionamiento hacia un fabricante específico y cumple con los principios de razonabilidad, neutralidad tecnológica, igualdad y valor por dinero establecidos en los artículos 4° y 40° de la Ley 7021/22.
Análisis técnico-normativo:
En el Ítem 3.2.1 – Firewall, el pliego establece los siguientes requerimientos:
“Debe permitir el bloqueo de vulnerabilidades. Deberá permitir el bloqueo de exploits conocidos.”
La terminología empleada en ambos puntos no refleja la nomenclatura técnica estándar del mercado, sino que corresponde textualmente a la utilizada por un fabricante específico (Fortinet) en sus hojas de datos y fichas técnicas públicas —en particular, los modelos FortiGate 100F / 200F—.
Esta coincidencia literal evidencia un posible direccionamiento del pliego hacia una marca y oferente determinados, vulnerando los principios de igualdad, libre competencia y neutralidad tecnológica previstos en los artículos 4° y 40° de la Ley 7021/22.
Desde el punto de vista técnico, todos los Sistemas de Prevención de Intrusiones (IPS) de clase empresarial poseen la capacidad de detectar y bloquear exploits y vulnerabilidades conocidas, pero lo hacen a través de mecanismos de detección basados en firmas, correlación de patrones, análisis de comportamiento, inteligencia de amenazas (Threat Intelligence Feeds) y técnicas de mitigación activa, sin utilizar necesariamente la denominación literal de “bloqueo de vulnerabilidades” o “bloqueo de exploits conocidos”.
En las fichas técnicas de otros fabricantes líderes (p. ej. Palo Alto Networks, Check Point, Sophos, Cisco, Huawei, WatchGuard, entre otros), estas capacidades se documentan como:
“Intrusion Prevention / Threat Protection / Exploit Detection and Mitigation”,
o bien como parte del módulo de “Advanced Threat Prevention (ATP)”.
Por tanto, lo que debe verificarse no es la coincidencia semántica con el término empleado, sino la capacidad funcional efectiva del equipo de prevenir, detectar y bloquear amenazas y exploits mediante firmas IPS actualizables y análisis avanzado.
De acuerdo con el principio de razonabilidad (art. 4 inc. k) y el Decreto 2264/24, la DNCP y las convocantes deben formular especificaciones que sean técnicamente objetivas, verificables y neutrales, evitando el uso de terminología propia de una marca comercial.
Remitirse al PBC. Se aclara que la funcionalidad de bloqueo de vulnerabilidades y de exploits conocidos hace referencia a la detección y prevención de ataques que aprovechan vulnerabilidades presentes en los sistemas o aplicaciones o patrones de ataques. Existen múltiples fabricantes en el mercado que incorporan dicha funcionalidad, por lo que el requerimiento no resulta restrictivo ni direccionado hacia una marca específica
36
ESPECIFICACIONES TÉCNICAS
En el Pliego de Bases y Condiciones se especifican los estándares requeridos para la fibra óptica, solicitamos a la Convocante puedan aceptar sistema de protección contra la humedad mediante geles protectores contra el agua.
Esto favorecerá a una mayor participación de potenciales oferentes.
En el Pliego de Bases y Condiciones se especifican los estándares requeridos para la fibra óptica, solicitamos a la Convocante puedan aceptar sistema de protección contra la humedad mediante geles protectores contra el agua.
Esto favorecerá a una mayor participación de potenciales oferentes.
De conformidad con lo dispuesto en los artículos 18, 19, 56 y concordantes de la Ley N.º 7021/2022 “De Suministros y Contrataciones Públicas”, así como los artículos 77, 78 y 80 del Decreto Reglamentario N.º 2264/2024, se formula la presente consulta y solicitud de verificación respecto al proceso licitatorio de referencia, atendiendo a que del análisis técnico y documental del Pliego de Bases y Condiciones (PBC) se advierten indicios de posible direccionamiento en las especificaciones técnicas y en los requisitos documentales exigidos. En virtud del principio de igualdad de oportunidades y libre concurrencia, consagrado en el artículo 5 de la Ley 7021/2022, se solicita a la DNCP realizar una verificación integral del presente llamado, a fin de constatar si las condiciones establecidas en el PBC se ajustan al marco normativo vigente y garantizan la participación efectiva de todos los potenciales oferentes sin discriminación ni ventajas indebidas. Asimismo, se requiere que la Convocante se abstenga de responder remitiéndose de forma genérica al PBC, y que en su lugar fundamente de manera jurídica y/o técnica las razones que sustenten los criterios y requisitos establecidos, en cumplimiento del principio de transparencia y razonabilidad establecido en los artículos 6 y 19 de la Ley 7021/2022. Por tanto, se solicita la intervención y pronunciamiento de la DNCP respecto a la adecuación de las especificaciones técnicas y documentales del presente llamado a las disposiciones de la Ley N.º 7021/2022 y su Decreto N.º 2264/2024.
De conformidad con lo dispuesto en los artículos 18, 19, 56 y concordantes de la Ley N.º 7021/2022 “De Suministros y Contrataciones Públicas”, así como los artículos 77, 78 y 80 del Decreto Reglamentario N.º 2264/2024, se formula la presente consulta y solicitud de verificación respecto al proceso licitatorio de referencia, atendiendo a que del análisis técnico y documental del Pliego de Bases y Condiciones (PBC) se advierten indicios de posible direccionamiento en las especificaciones técnicas y en los requisitos documentales exigidos. En virtud del principio de igualdad de oportunidades y libre concurrencia, consagrado en el artículo 5 de la Ley 7021/2022, se solicita a la DNCP realizar una verificación integral del presente llamado, a fin de constatar si las condiciones establecidas en el PBC se ajustan al marco normativo vigente y garantizan la participación efectiva de todos los potenciales oferentes sin discriminación ni ventajas indebidas. Asimismo, se requiere que la Convocante se abstenga de responder remitiéndose de forma genérica al PBC, y que en su lugar fundamente de manera jurídica y/o técnica las razones que sustenten los criterios y requisitos establecidos, en cumplimiento del principio de transparencia y razonabilidad establecido en los artículos 6 y 19 de la Ley 7021/2022. Por tanto, se solicita la intervención y pronunciamiento de la DNCP respecto a la adecuación de las especificaciones técnicas y documentales del presente llamado a las disposiciones de la Ley N.º 7021/2022 y su Decreto N.º 2264/2024.
Aclaración y modificación del requerimiento sobre “resolución de direcciones vía DNS” (Ítem 3.2.1 – Firewall)
¿Podrá la Convocante justificar la pertinencia técnica de exigir que la “resolución de direcciones vía DNS” se realice mediante asignación a direcciones IPv4/IPv6 predefinidas por el firewall, considerando que esta arquitectura corresponde a una tecnología propietaria (DNS Filter de Fortinet) y no constituye un estándar general de mercado?
Asimismo, se propone modificar o eliminar este requisito, reemplazándolo por una redacción funcional y tecnológicamente neutral, como la siguiente:
“El equipo deberá contar con un mecanismo de protección DNS capaz de identificar y bloquear consultas hacia dominios maliciosos o sospechosos, basándose en servicios de reputación, inteligencia de amenazas o listas de bloqueo dinámicas, garantizando compatibilidad con IPv4 e IPv6.”
Esta modificación mantiene la finalidad de protección de seguridad, evita el direccionamiento hacia un fabricante específico, y se alinea con los principios de igualdad, razonabilidad, neutralidad tecnológica y valor por dinero previstos en los artículos 4° y 40° de la Ley 7021/22.
Análisis técnico-normativo:
En el Ítem 3.2.1 – Firewall, el pliego establece el siguiente requerimiento:
“Deberá poseer la función resolución de direcciones vía DNS, para que conexiones como destino a dominios maliciosos sean resueltas por el Firewall como direcciones (IPv4 e IPv6), previamente definidos.”
La redacción de este punto coincide casi textualmente con la descripción del servicio “DNS Filter” de la marca Fortinet (FortiGate), el cual emplea una arquitectura propietaria de resolución DNS local, asignando direcciones IP predefinidas a dominios maliciosos detectados.
Esta formulación no representa un estándar del mercado, ya que los demás fabricantes de firewalls de próxima generación (NGFW) —como Palo Alto Networks, Sophos, Cisco, Check Point o Huawei— implementan mecanismos equivalentes de protección DNS mediante DNS Proxy, Threat Intelligence DNS Filtering, Security Reputation Services o DNS Sinkhole dinámico, que bloquean o redirigen consultas DNS con base en reputación o listas negras en la nube, sin realizar resolución local a direcciones IPv4/IPv6 predefinidas.
En consecuencia, mantener la redacción actual restringe la competencia, dado que impone un modo de implementación propietario y no funcionalmente indispensable, direccionando el pliego hacia una marca y oferente específicos.
Lo técnicamente relevante es que el firewall detecte, clasifique y bloquee las solicitudes hacia dominios maliciosos o sospechosos, independientemente del método de resolución DNS empleado.
El principio de razonabilidad (art. 4 inc. k) y la neutralidad tecnológica (art. 40) de la Ley 7021/22 establecen que los pliegos deben definir los requerimientos en términos de resultados o desempeño, y no en función de tecnologías particulares o metodologías propietarias.
El Decreto 2264/24 refuerza que las especificaciones deben basarse en criterios objetivos, verificables y no excluyentes, priorizando el logro del valor público y la libre concurrencia.
10-10-2025
14-10-2025
Aclaración y modificación del requerimiento sobre “resolución de direcciones vía DNS” (Ítem 3.2.1 – Firewall)
¿Podrá la Convocante justificar la pertinencia técnica de exigir que la “resolución de direcciones vía DNS” se realice mediante asignación a direcciones IPv4/IPv6 predefinidas por el firewall, considerando que esta arquitectura corresponde a una tecnología propietaria (DNS Filter de Fortinet) y no constituye un estándar general de mercado?
Asimismo, se propone modificar o eliminar este requisito, reemplazándolo por una redacción funcional y tecnológicamente neutral, como la siguiente:
“El equipo deberá contar con un mecanismo de protección DNS capaz de identificar y bloquear consultas hacia dominios maliciosos o sospechosos, basándose en servicios de reputación, inteligencia de amenazas o listas de bloqueo dinámicas, garantizando compatibilidad con IPv4 e IPv6.”
Esta modificación mantiene la finalidad de protección de seguridad, evita el direccionamiento hacia un fabricante específico, y se alinea con los principios de igualdad, razonabilidad, neutralidad tecnológica y valor por dinero previstos en los artículos 4° y 40° de la Ley 7021/22.
Análisis técnico-normativo:
En el Ítem 3.2.1 – Firewall, el pliego establece el siguiente requerimiento:
“Deberá poseer la función resolución de direcciones vía DNS, para que conexiones como destino a dominios maliciosos sean resueltas por el Firewall como direcciones (IPv4 e IPv6), previamente definidos.”
La redacción de este punto coincide casi textualmente con la descripción del servicio “DNS Filter” de la marca Fortinet (FortiGate), el cual emplea una arquitectura propietaria de resolución DNS local, asignando direcciones IP predefinidas a dominios maliciosos detectados.
Esta formulación no representa un estándar del mercado, ya que los demás fabricantes de firewalls de próxima generación (NGFW) —como Palo Alto Networks, Sophos, Cisco, Check Point o Huawei— implementan mecanismos equivalentes de protección DNS mediante DNS Proxy, Threat Intelligence DNS Filtering, Security Reputation Services o DNS Sinkhole dinámico, que bloquean o redirigen consultas DNS con base en reputación o listas negras en la nube, sin realizar resolución local a direcciones IPv4/IPv6 predefinidas.
En consecuencia, mantener la redacción actual restringe la competencia, dado que impone un modo de implementación propietario y no funcionalmente indispensable, direccionando el pliego hacia una marca y oferente específicos.
Lo técnicamente relevante es que el firewall detecte, clasifique y bloquee las solicitudes hacia dominios maliciosos o sospechosos, independientemente del método de resolución DNS empleado.
El principio de razonabilidad (art. 4 inc. k) y la neutralidad tecnológica (art. 40) de la Ley 7021/22 establecen que los pliegos deben definir los requerimientos en términos de resultados o desempeño, y no en función de tecnologías particulares o metodologías propietarias.
El Decreto 2264/24 refuerza que las especificaciones deben basarse en criterios objetivos, verificables y no excluyentes, priorizando el logro del valor público y la libre concurrencia.
Remitirse al PBC. El requerimiento hace referencia a la capacidad del firewall de interceptar y controlar las respuestas DNS dirigidas a dominios maliciosos o no deseados, de modo que la dirección IP resultante no corresponda al sitio real, sino a una dirección configurable -como una página de bloqueo, una dirección interna u otro destino definido- con fines de seguridad, registro o contención de amenazas. Asimismo, se ratifica que múltiples fabricantes disponen de esta funcionalidad, por lo que el requerimiento no resulta restrictivo ni orientado hacia una marca específica.
39
ESPECIFICACIONES TÉCNICAS
En el apartado CAPACIDAD TÉCNICA se solicita “carta del fabricante conforme a los requerimientos mencionados en las especificaciones técnicas”, Sin embargo, en el apartado AUTORIZACIÓN DEL FABRICANTE se indica no aplica. Solicitamos a la convocante adecuar dicho apartado a "si aplica" en consideración a las autorizaciones solicitadas por las especificaciones técnicas a modo de evitar malas interpretaciones.
En el apartado CAPACIDAD TÉCNICA se solicita “carta del fabricante conforme a los requerimientos mencionados en las especificaciones técnicas”, Sin embargo, en el apartado AUTORIZACIÓN DEL FABRICANTE se indica no aplica. Solicitamos a la convocante adecuar dicho apartado a "si aplica" en consideración a las autorizaciones solicitadas por las especificaciones técnicas a modo de evitar malas interpretaciones.
Modificación del requerimiento sobre protocolos de autenticación VPN (Ítem 3.2.1 – Firewall)
¿Podrá la Convocante reconsiderar el requisito de compatibilidad obligatoria con ACE Management Servers (SecurID) y modificar el texto del pliego para que dicha compatibilidad sea opcional o sustituible por protocolos equivalentes de autenticación multifactor (2FA/MFA)?
Se propone la siguiente redacción alternativa:
“La solución de VPN deberá soportar la integración con servidores de autenticación LDAP, RADIUS y otros equivalentes (SAML, OAuth2, OpenID Connect, TACACS+), permitiendo además la autenticación mediante certificados digitales.
La compatibilidad con ACE Management Servers (SecurID) será considerada opcional, pudiendo aceptarse cualquier protocolo o sistema de autenticación multifactor (2FA/MFA) de funcionalidad equivalente.”
Esta modificación preserva la seguridad exigida, promueve la interoperabilidad, y cumple con los principios de neutralidad tecnológica, razonabilidad y libre concurrencia previstos en los artículos 4° y 40° de la Ley 7021/22.
Análisis técnico-normativo:
En el Ítem 3.2.1 – Firewall, el pliego dispone que:
“La solución de VPN debe soportar la integración con los siguientes protocolos de autenticación:
• Lightweight Directory Access Protocol (LDAP) Servers
• Remote Authentication Dial-in User Service (RADIUS)
• ACE Management Servers (SecurID)
• Client certificates, authenticated by trusted CAs.”
El punto referido a ACE Management Servers (SecurID) introduce una dependencia directa con un producto propietario de RSA, lo que configura una restricción tecnológica injustificada. Esta exigencia reduce la participación de marcas que emplean sistemas equivalentes de autenticación fuerte o multifactor (2FA/MFA) basados en RADIUS, SAML, OAuth2 u OpenID Connect, todos ellos compatibles entre sí y capaces de integrarse con RSA SecurID u otros proveedores de tokens OTP.
La Ley 7021/22 (arts. 4 y 40) y el Decreto 2264/24 establecen que las especificaciones deben ser neutrales, razonables y funcionales, evitando la mención de tecnologías o marcas determinadas cuando existan soluciones equivalentes que aseguren el mismo nivel de seguridad y compatibilidad.
Desde la perspectiva técnica y de interoperabilidad, cualquier firewall con soporte para RADIUS o SAML puede integrarse con ACE Management Server sin requerir compatibilidad nativa; por tanto, exigirla expresamente constituye una barrera innecesaria y direcciona el pliego hacia un conjunto reducido de fabricantes.
La propuesta de redacción alternativa garantiza neutralidad tecnológica, mantiene el nivel de protección requerido y se ajusta al principio de valor por dinero, permitiendo que distintas soluciones con capacidades equivalentes participen en igualdad de condiciones.
10-10-2025
14-10-2025
Modificación del requerimiento sobre protocolos de autenticación VPN (Ítem 3.2.1 – Firewall)
¿Podrá la Convocante reconsiderar el requisito de compatibilidad obligatoria con ACE Management Servers (SecurID) y modificar el texto del pliego para que dicha compatibilidad sea opcional o sustituible por protocolos equivalentes de autenticación multifactor (2FA/MFA)?
Se propone la siguiente redacción alternativa:
“La solución de VPN deberá soportar la integración con servidores de autenticación LDAP, RADIUS y otros equivalentes (SAML, OAuth2, OpenID Connect, TACACS+), permitiendo además la autenticación mediante certificados digitales.
La compatibilidad con ACE Management Servers (SecurID) será considerada opcional, pudiendo aceptarse cualquier protocolo o sistema de autenticación multifactor (2FA/MFA) de funcionalidad equivalente.”
Esta modificación preserva la seguridad exigida, promueve la interoperabilidad, y cumple con los principios de neutralidad tecnológica, razonabilidad y libre concurrencia previstos en los artículos 4° y 40° de la Ley 7021/22.
Análisis técnico-normativo:
En el Ítem 3.2.1 – Firewall, el pliego dispone que:
“La solución de VPN debe soportar la integración con los siguientes protocolos de autenticación:
• Lightweight Directory Access Protocol (LDAP) Servers
• Remote Authentication Dial-in User Service (RADIUS)
• ACE Management Servers (SecurID)
• Client certificates, authenticated by trusted CAs.”
El punto referido a ACE Management Servers (SecurID) introduce una dependencia directa con un producto propietario de RSA, lo que configura una restricción tecnológica injustificada. Esta exigencia reduce la participación de marcas que emplean sistemas equivalentes de autenticación fuerte o multifactor (2FA/MFA) basados en RADIUS, SAML, OAuth2 u OpenID Connect, todos ellos compatibles entre sí y capaces de integrarse con RSA SecurID u otros proveedores de tokens OTP.
La Ley 7021/22 (arts. 4 y 40) y el Decreto 2264/24 establecen que las especificaciones deben ser neutrales, razonables y funcionales, evitando la mención de tecnologías o marcas determinadas cuando existan soluciones equivalentes que aseguren el mismo nivel de seguridad y compatibilidad.
Desde la perspectiva técnica y de interoperabilidad, cualquier firewall con soporte para RADIUS o SAML puede integrarse con ACE Management Server sin requerir compatibilidad nativa; por tanto, exigirla expresamente constituye una barrera innecesaria y direcciona el pliego hacia un conjunto reducido de fabricantes.
La propuesta de redacción alternativa garantiza neutralidad tecnológica, mantiene el nivel de protección requerido y se ajusta al principio de valor por dinero, permitiendo que distintas soluciones con capacidades equivalentes participen en igualdad de condiciones.