ADQUISICIÓN DE UNA SOLUCIÓN DE RESPALDOS DE CONFIGURACIONES DE EQUIPOS DE RED.

2         REQUISITOS DE ADMISIBILIDAD

2.1        La participación en el presente procedimiento de contratación pública implica la aceptación plena e incondicional de todas las disposiciones contenidas en el pliego de condiciones y sus anexos. La oferta presentada deberá cumplir íntegramente con los requisitos legales, técnicos, administrativos y formales establecidos en el presente pliego, así como con la normativa vigente en materia de contratación pública.

2.2        El oferente deberá presentar en su oferta, un documento emitido por el fabricante, con no más de tres (3) meses de antigüedad, que indique que la empresa oferente es un distribuidor autorizado para Costa Rica

1         ESPECIFICACIONES TÉCNICAS

1.1        Se requiere de una solución de respaldos de configuraciones de equipos de red, con al menos las siguientes características:

1.1.1      Características Generales

1.1.1.1     El oferente debe proporcionar una solución basada en Virtual Appliance con el licenciamiento que permita gestionar al menos 250 dispositivos de red, seguridad y almacenamiento multi-vendor.

1.1.1.2     La solución debe estar disponible como Virtual Appliance compatible con VMWARE.

1.1.1.3     La solución debe incluir el licenciamiento en High-Availability con failover automático en caso de que el virtual appliance primario no esté disponible.

1.1.1.4     La solución, el virtual appliance, las licencias y los componentes de software deberán ser originales, de uso legítimo para el BCCR y corresponder a versiones vigentes y soportadas por el fabricante durante el período contractual.

1.1.1.5     La solución deberá incluir todas las licencias, módulos, conectores, imágenes de despliegue, archivos de instalación, documentación y demás componentes lógicos necesarios para su implementación, configuración, alta disponibilidad, operación, respaldo, recuperación, automatización, integración y soporte, sin costos adicionales no declarados en la oferta.

1.1.1.6     Cuando el Contratista proponga una versión o componente de software diferente del ofertado como mejora tecnológica, deberá demostrar que sus características son iguales o superiores y obtener aceptación previa y expresa del Administrador del Contrato.

1.1.2      Características de Capacidades y Rendimiento

1.1.2.1     Para soportar una red diversa, la solución debe ser capaz de gestionar dispositivos de red de múltiples fabricantes de forma nativa, considerando al menos los siguientes: F5 Big-IP, F5 Velos, Cisco ACI, Cisco Switches con IOS y NXOS, Cisco WLC, Cisco SDWAN Rotuers,Cisco ISE, Cisco Firepower, NetScout PFS, Arbor AED, OpenGear OM, OpenGearLighthouse.

1.1.2.2     Para garantizar una recuperación rápida ante una interrupción, la solución debe ser capaz de realizar backups completos de configuración conforme a las recomendaciones del fabricante soportado.

1.1.2.3     La solución debe ser capaz de realizar backups y analizar configuraciones que pueden incluir sistemas que generan grandes volúmenes de datos en formato de archivo estructurado de hasta 5GB.

1.1.2.4     La solución debe realizar operaciones de backup y recovery de las marcas mencionadas de forma nativa, sin que sea estrictamente necesario el desarrollo de scripts por parte del usuario para la funcionalidad base.

1.1.2.5     La solución debe almacenar todas las configuraciones y ajustes en formato cifrado.

1.1.2.6     La solución debe verificar el tamaño, la integridad y la seguridad de los backups durante la transferencia.

1.1.2.7     La solución debe permitir múltiples programaciones de backup para un mismo dispositivo.

1.1.2.8     La solución debe incluir la funcionalidad de reintentar automáticamente los backups cuando fallen.

1.1.2.9     La solución debe retener versiones únicas de configuración para reducir el uso de almacenamiento y proporcionar historial o comparación de configuraciones.

1.1.2.10  La solución debe ofrecer la recuperación de configuraciones para todos los tipos de fabricantes soportados.

1.1.2.11  La solución debe ser capaz de realizar descubrimiento de activos de red y programar automáticamente backups basados en parámetros debiendo soportar al menos los siguientes: ubicación, tipo de dispositivo o patrones de hostname.

1.1.2.12  La solución debe ser capaz de comparar configuraciones del dispositivo del cual fue tomada con la de otros dispositivos del mismo tipo.

1.1.3      Características de Seguridad

1.1.3.1     La solución debe proporcionar un motor de análisis de cumplimiento integrado, no un sistema de terceros.

1.1.3.2     La solución debe ser capaz de analizar automáticamente configuraciones de dispositivos y proporcionar un puntaje de cumplimiento contra políticas internas de seguridad de la institución.

1.1.3.3     La solución debe incluir una función de búsqueda rápida capaz de buscar en todos los datos de configuración, como direcciones IP, protocolos, usernames u otros parámetros.

1.1.3.4     La solución debe ser capaz de revisar configuraciones o ajustes de dispositivos sin necesidad de escanear la red.

1.1.3.5     La solución debe soportar verificaciones avanzadas de configuración utilizando condiciones y dependencias.

1.1.3.6     La solución debe ser capaz de enviar alertas vía Email, SNMP y Syslog.

1.1.3.7     La solución debe tener un sistema de reporteo que soporte filtros personalizados y capacidades de programación.

1.1.3.8     La solución debe proporcionar verificaciones de contraseñas para asegurar que no se utilicen passwords por defecto del fabricante o passwords débiles para gestionar dispositivos de red.

1.1.3.9     La solución debe soportar múltiples equipos y restringir el acceso al equipo o grupo correspondiente.

1.1.4      Características de Automatización

1.1.4.1     La solución debe ser capaz de automatizar cambios masivos en dispositivos mediante interfaces CLI o API.

1.1.4.2     La solución debe soportar cambios programados. Los resultados (output) de los comandos CLI deben almacenarse para fines de reporting.

1.1.4.3     Para simplificar cambios masivos, la solución debe permitir enviar cambios a dispositivos utilizando Variable Input por dispositivo cargado desde archivos CSV.

1.1.4.4     La solución debe ser capaz de realizar cambios utilizando condiciones (IF / THEN).

1.1.4.5     La solución debe registrar los cambios realizados por los administradores de los dispositivos de red a través de la plataforma.

1.1.4.6     Los cambios realizados deben ser sujetos de búsquedas.

1.1.4.7     La solución debe contar con una JSON API para integración con otras plataformas, permitiendo la configuración de dispositivos vía API o la integración con plataformas de monitoreo y alertamiento por medio de dicha API.

1.1.5      Especificaciones generales

1.1.5.1     Configuración

1.1.5.1.1    La configuración base de la solución deberá ser llevada a cabo por el contratista.  Entendiendo como configuración base:

1.1.5.1.2    Actualización de la solución

1.1.5.1.3    Configuración del servicio AAA hacia un servidor TACAS+.

1.1.5.1.4    Configuración del envío de logs.

1.1.5.1.5    Configuración del servicio de NTP.

1.1.5.1.6    Configuración del sistema de alta disponibilidad.

1.1.5.1.7    Configuración de respaldos de al menos un equipo de cada tipo de los mencionados en el punto 1.1.2.1

1.1.5.2     Otros Aspectos

1.1.5.2.1    El contratista deberá velar porque las licencias de la solución contratada, cuando corresponda, sean registradas ante el fabricante original a nombre del BCCR.

1.1.5.2.2    El Oferente deberá indicar el nombre de al menos dos (2) personas calificadas en la administración de la solución ofertada que se encuentren certificadas por el fabricante, para dar soporte.

1.2        Características Generales

1.2.1      El oferente debe proporcionar una solución basada en Virtual Appliance con el licenciamiento que permita gestionar al menos 250 dispositivos de red, seguridad y almacenamiento multi-vendor.

1.2.2      La solución debe estar disponible como Virtual Appliance compatible con VMWARE.

1.2.3      La solución debe incluir el licenciamiento en High-Availability con failover automático en caso de que el virtual appliance primario no esté disponible.

1.2.4      La solución, el virtual appliance, las licencias y los componentes de software deberán ser originales, de uso legítimo para el BCCR y corresponder a versiones vigentes y soportadas por el fabricante durante el período contractual.

1.2.5      La solución deberá incluir todas las licencias, módulos, conectores, imágenes de despliegue, archivos de instalación, documentación y demás componentes lógicos necesarios para su implementación, configuración, alta disponibilidad, operación, respaldo, recuperación, automatización, integración y soporte, sin costos adicionales no declarados en la oferta.

1.2.6      Cuando el Contratista proponga una versión o componente de software diferente del ofertado como mejora tecnológica, deberá demostrar que sus características son iguales o superiores y obtener aceptación previa y expresa del Administrador del Contrato.

1.3        Características de Capacidades y Rendimiento

1.3.1      Para soportar una red diversa, la solución debe ser capaz de gestionar dispositivos de red de múltiples fabricantes de forma nativa, considerando al menos los siguientes: F5 Big-IP, F5 Velos, Cisco ACI, Cisco Switches con IOS y NXOS, Cisco WLC, Cisco SDWAN Rotuers,Cisco ISE, Cisco Firepower, NetScout PFS, Arbor AED, OpenGear OM, OpenGearLighthouse.

1.3.2      Para garantizar una recuperación rápida ante una interrupción, la solución debe ser capaz de realizar backups completos de configuración conforme a las recomendaciones del fabricante soportado.

1.3.3      La solución debe ser capaz de realizar backups y analizar configuraciones que pueden incluir sistemas que generan grandes volúmenes de datos en formato de archivo estructurado de hasta 5GB.

1.3.4      La solución debe realizar operaciones de backup y recovery de las marcas mencionadas de forma nativa, sin que sea estrictamente necesario el desarrollo de scripts por parte del usuario para la funcionalidad base.

1.3.5      La solución debe almacenar todas las configuraciones y ajustes en formato cifrado.

1.3.6      La solución debe verificar el tamaño, la integridad y la seguridad de los backups durante la transferencia.

1.3.7      La solución debe permitir múltiples programaciones de backup para un mismo dispositivo.

1.3.8      La solución debe incluir la funcionalidad de reintentar automáticamente los backups cuando fallen.

1.3.9      La solución debe retener versiones únicas de configuración para reducir el uso de almacenamiento y proporcionar historial o comparación de configuraciones.

1.3.10   La solución debe ofrecer la recuperación de configuraciones para todos los tipos de fabricantes soportados.

1.3.11   La solución debe ser capaz de realizar descubrimiento de activos de red y programar automáticamente backups basados en parámetros debiendo soportar al menos los siguientes: ubicación, tipo de dispositivo o patrones de hostname.

1.3.12   La solución debe ser capaz de comparar configuraciones del dispositivo del cual fue tomada con la de otros dispositivos del mismo tipo.

1.4        Características de Seguridad

1.4.1      La solución debe proporcionar un motor de análisis de cumplimiento integrado, no un sistema de terceros.

1.4.2      La solución debe ser capaz de analizar automáticamente configuraciones de dispositivos y proporcionar un puntaje de cumplimiento contra políticas internas de seguridad de la institución.

1.4.3      La solución debe incluir una función de búsqueda rápida capaz de buscar en todos los datos de configuración, como direcciones IP, protocolos, usernames u otros parámetros.

1.4.4      La solución debe ser capaz de revisar configuraciones o ajustes de dispositivos sin necesidad de escanear la red.

1.4.5      La solución debe soportar verificaciones avanzadas de configuración utilizando condiciones y dependencias.

1.4.6      La solución debe ser capaz de enviar alertas vía Email, SNMP y Syslog.

1.4.7      La solución debe tener un sistema de reporteo que soporte filtros personalizados y capacidades de programación.

1.4.8      La solución debe proporcionar verificaciones de contraseñas para asegurar que no se utilicen passwords por defecto del fabricante o passwords débiles para gestionar dispositivos de red.

1.4.9      La solución debe soportar múltiples equipos y restringir el acceso al equipo o grupo correspondiente.

1.5        Características de Automatización

1.5.1      La solución debe ser capaz de automatizar cambios masivos en dispositivos mediante interfaces CLI o API.

1.5.2      La solución debe soportar cambios programados. Los resultados (output) de los comandos CLI deben almacenarse para fines de reporting.

1.5.3      Para simplificar cambios masivos, la solución debe permitir enviar cambios a dispositivos utilizando Variable Input por dispositivo cargado desde archivos CSV.

1.5.4      La solución debe ser capaz de realizar cambios utilizando condiciones (IF / THEN).

1.5.5      La solución debe registrar los cambios realizados por los administradores de los dispositivos de red a través de la plataforma.

1.5.6      Los cambios realizados deben ser sujetos de búsquedas.

1.5.7      La solución debe contar con una JSON API para integración con otras plataformas, permitiendo la configuración de dispositivos vía API o la integración con plataformas de monitoreo y alertamiento por medio de dicha API.

1.6        Especificaciones generales

1.6.1      Configuración

1.6.1.1     La configuración base de la solución deberá ser llevada a cabo por el contratista.  Entendiendo como configuración base:

1.6.1.2     Actualización de la solución

1.6.1.3     Configuración del servicio AAA hacia un servidor TACAS+.

1.6.1.4     Configuración del envío de logs.

1.6.1.5     Configuración del servicio de NTP.

1.6.1.6     Configuración del sistema de alta disponibilidad.

1.6.1.7     Configuración de respaldos de al menos un equipo de cada tipo de los mencionados en el punto 1.1.2.1

1.6.2      Otros Aspectos

1.6.2.1     El contratista deberá velar porque las licencias de la solución contratada, cuando corresponda, sean registradas ante el fabricante original a nombre del BCCR.

1.6.2.2     El Oferente deberá indicar el nombre de al menos dos (2) personas calificadas en la administración de la solución ofertada que se encuentren certificadas por el fabricante, para dar soporte.

1.7        Capacitación

1.7.1      El oferente deberá proporcionar capacitación al personal designado por el BCCR para la instalación, operación, administración básica y mantenimiento de la solución ofertada.

1.7.2      La capacitación deberá cubrir como mínimo:

• Descripción técnica.

• Instalación y puesta en operación

• Configuración básica

• Operación normal

• Mantenimiento preventivo

• Procedimientos de diagnóstico y solución de fallas comunes

1.7.3       La capacitación deberá impartirse en idioma español, en horario hábil del BCCR (lunes a viernes de 8:00 a.m. a 5:00 p.m.), en modalidad virtual.

1.7.4      El oferente deberá incluir al menos cuatro (4) cupos de capacitación, sin costo adicional.

 

4         CONDICIONES GENERALES

4.1        LUGAR Y PLAZO DE ENTREGA:

4.1.1      Lugar de entrega: Banco Central de Costa Rica, Avenida Central y Primera, Calles 2 y 4. El oferente debe indicar el plazo de entrega, el cual no podrá ser mayor de 15 días hábiles, contados a partir de la notificación del contrato en SICOP.

4.2        GARANTÍA SOBRE EL OBJETO CONTRACTUAL:

4.2.1      La garantía para todos los componentes de la solución debe ser la misma y no menor a un (1) año.

4.2.2      La garantía rige a partir de la fecha de Recepción Definitiva de la solución por parte del Administrador del Contrato en SICOP.

4.2.3      La garantía debe ser brindada directamente por el contratista.

4.2.4      El Contratista deberá aportar —al momento de la entrega de la solución— un documento oficial emitido por el fabricante, en la que conste que la solución entregada cuenta con la garantía extendida solicitada. Dicha certificación deberá indicar expresamente la fecha de inicio y la fecha de finalización del contrato de garantía adquirido con el fabricante. La fecha de inicio no puede ser anterior la fecha de recepción definitiva

4.2.5      Durante el periodo de vigencia de la garantía, el Contratista deberá proveer acceso a los canales oficiales del fabricante —como mínimo acceso a un sitio en Internet— de tal forma que el AC pueda obtener expeditamente actualizaciones de software e información técnica especializada.

4.2.6      Soporte

4.2.6.1     Reporte y atención de fallas:

4.2.6.1.1    El Contratista debe contar con un proceso que opere las 24 horas del día los 365 días del año para la recepción de reportes por fallas. Este proceso debe contar con los siguientes mecanismos para colocar casos de soporte: un número de teléfono y un correo electrónico o sitio web. Estos mecanismos de reporte deben ser suministrados por el Oferente en su oferta. Se dará por colocado un reporte de averías cuando el personal técnico del Banco envié una solicitud por alguno de los mecanismos antes indicados.

4.2.6.1.2    El Contratista deberá generar un número de caso interno, para poder darle seguimiento a la solicitud de soporte planteada. El número de caso debe ser notificado al administrador del contrato mediante correo o llamada telefónica.

4.2.6.1.3    Ante una falla o comportamiento anómalo de la solución, el personal técnico del Banco colocará una solicitud de soporte al contratista. Posteriormente, personal del Contratista (ingenieros calificados) deberá iniciar la atención de la solicitud y ponerse en contacto con el personal técnico del Banco en los plazos estipulados en la clasificación por Severidad y Tiempos de respuesta establecidos en este pliego de condiciones.

4.2.6.1.4    Clasificación por severidad y tiempos de respuesta: El Administrador del Contrato clasificará las solicitudes de servicio como “severidad 1”, “severidad 2” o “severidad 3”, según el impacto en la operación.

4.2.6.1.5    Severidad 1:

1. Si el personal técnico de BCCR lo solicita, personal calificado del Contratista deberá presentarse de forma presencial al sitio donde se encuentre el equipo con problemas en un plazo máximo de 4 (cuatro) horas naturales.

2. Contacto inicial: debe de darse máximo dos (2) horas naturales después de la apertura del caso con el contratista.

3. Diagnóstico: debe de tomar máximo dos (2) horas naturales desde el contacto inicial entre contratista y personal técnico del BCCR.

4. Escalamiento al TAC si no hay solución en un lapso máximo de 4 horas desde el contacto inicial.

5. Informes de avance: Por defecto, cada hora desde el contacto inicial, hasta resolver el incidente reportado. El personal técnico de Banco puede solicitar otra periodicidad (menor o mayor) dependiendo del impacto y necesidades del Banco.

4.2.6.1.6    Severidad 2:

1. Si el personal de BCCR lo solicita, personal calificado del Contratista deberá presentarse de forma presencial al sitio donde se encuentre el equipo con problemas en un plazo máximo de 4 (cuatro) horas naturales.

2. Contacto inicial: debe de darse máximo cuatro (4) horas naturales después de la apertura del caso con el contratista.

3. Diagnóstico: debe de tomar máximo ocho (8) horas naturales desde el contacto inicial entre contratista y personal del BCCR.

4. Escalamiento al TAC si no hay solución en un lapso máximo de 8 horas desde el contacto inicial.

5. Informes de avance: Por defecto, cada cuatro horas desde el contacto inicial, hasta resolver el incidente reportado. El personal técnico del Banco puede solicitar otra periodicidad (menor o mayor) dependiendo del impacto y necesidades del Banco.

4.2.6.1.7    Severidad 3:

1. Si el personal técnico de BCCR lo solicita, personal calificado del Contratista deberá presentarse de forma presencial al sitio donde se encuentre el equipo con problemas en un plazo máximo de 4 (cuatro) horas naturales.

2. Contacto inicial: debe de darse máximo ocho (8) horas hábiles después de la apertura del caso con el contratista.

3. Diagnóstico: debe de tomar máximo treinta y dos (32) horas hábiles desde el contacto inicial entre contratista y personal del BCCR.

4. Escalamiento al TAC si no hay solución en un lapso máximo de 32 horas hábiles desde el contacto inicial.

5. Informes de avance: Por defecto, cada dieciséis horas hábiles desde el contacto inicial, hasta resolver el incidente reportado. El personal técnico de Banco puede solicitar otra periodicidad (menor o mayor) dependiendo del impacto y necesidades del Banco.

4.2.6.2     Servicio de análisis y alertas de vulnerabilidades críticas

4.2.6.2.1    Durante el periodo de vigencia de la garantía, el contratista deberá proveer el servicio de alertas y análisis de vulnerabilidades críticas. Para lo que deberá cumplir con lo siguiente:

a. Deberá mantener un seguimiento de las alertas con severidad CVE 7.0 o superior publicadas por el fabricante de la solución.

b. Ante la publicación de una vulnerabilidad, deberá realizar un análisis y determinar si esta afecta la plataforma cubierta por el contrato de soporte.

c. Luego de realizado el análisis deberá enviar un informe con los resultados y las acciones recomendadas.

d. El periodo comprendido entre la publicación de la vulnerabilidad, por parte del fabricante, de la vulnerabilidad y el envío del informe no deberá ser mayor de 5 días hábiles.

4.2.7      Mantenimiento

4.2.7.1     Servicio de mantenimiento de la solución:

4.2.7.2     Durante el periodo de vigencia de la garantía, el contratista deberá proveer el servicio de análisis de la solución, al menos una vez por año.

4.2.7.3     Los análisis por ejecutar son los siguientes:

4.2.7.3.1    Servicio de análisis

1. Deberá realizar un análisis de los sistemas, sus bugs, y vulnerabilidades reportadas.

2. Para esto deberá tomar en cuenta los recursos de memoria, modelo de hardware, los features activos y cualquier recomendación adicional sugerida por el fabricante para asegurar el correcto funcionamiento de la solución durante su operación.

4.2.7.3.2    Servicio de análisis Hardening.

1. Deberá generar un documento de “hardening” de la solución, siguiendo las recomendaciones del fabricante.

4.2.7.3.3    Servicio de análisis de capacidad

1. Deberá realizar un análisis de capacidad que incluya al menos uso de memoria, cpu, carga de los enlaces, y cualquier otro parámetro relevante para el adecuado funcionamiento de la solución sugerido por el fabricante.

4.2.7.3.4    Servicio de análisis de Bitácoras

1. Deberá realizar un análisis de las bitácoras de errores y sugerir acciones correctivas para asegurar el correcto funcionamiento de la solución.

4.2.7.3.5    Luego del análisis el contratista deberá entregar, en un plazo no mayor a 10 días hábiles, un informe con recomendaciones y pasos a seguir.

4.2.7.3.6    De ser requerido por el AC, los trabajos técnicos que se deriven de los análisis de servicios solicitados en el punto anterior deberán ser ejecutados por parte del contratista, en coordinación con el personal técnico que se designe. Estas labores se estiman en un máximo de 12 horas anuales

4.2.7.3.7    Las personas que realicen estos análisis, así como los trabajos técnicos, deberán estar certificados por el fabricante de los equipos. Para cumplir con este punto, antes de iniciar cada servicio de análisis, el contratista deberá enviar un documento emitido por el fabricante de los equipos, en la se haga constar que la persona asignada cuenta con la certificación activa.

4.2.7.3.8    Las fechas del análisis serán comunicadas por el AC, con al menos 10 días hábiles de anticipación.

4.2.8      Escalamiento

4.2.8.1     Escalamiento jerárquico: En su oferta el oferente deberá entregar al Administrador del Contrato un organigrama que muestre los niveles jerárquicos entre los técnicos de soporte y la gerencia general del contratista. Para cada jefatura se deberá indicar nombre completo y número de teléfono disponible 24/7. En caso de incumplimiento de los tiempos de atención, el Banco se reserva el derecho de escalar dentro de los niveles jerárquicos del contratista hasta lograr una atención adecuada.

4.3        SUBCONTRATACIÓN:

4.3.1      Cuando resulte necesario, el oferente podrá subcontratar hasta un 50% del monto ofertado, únicamente para la ejecución de actividades especializadas. Esta subcontratación no exime al contratista de su responsabilidad frente a la Administración.

4.3.2      Para tal efecto, el oferente deberá adjuntar el detalle de las actividades que pretende subcontratar, indicando el monto, el porcentaje de participación dentro del costo total de la oferta y el nombre del subcontratista correspondiente. Asimismo, deberá aportar certificación de los titulares del capital social y de los representantes legales de la empresa o empresas subcontratistas, a fin de verificar el cumplimiento del régimen de prohibiciones.

4.3.3      Cada subcontratista solo podrá participar en una oferta dentro de este concurso. Si varios oferentes requieren subcontratar a una misma persona física o jurídica, deberá acreditarse que existe un número limitado de subcontratistas en el mercado para el objeto contractual correspondiente.

4.4        OFERTAS EN CONSORCIO:

4.4.1      Cuando se presenten ofertas en consorcio, las empresas integrantes deberán cumplir las condiciones de admisibilidad y los requisitos establecidos en el pliego de condiciones, como si actuaran como un solo oferente, y responderán solidariamente por la totalidad de la oferta.

4.4.2      Dado que el BCCR utiliza SICOP para sus procedimientos de contratación, las personas físicas o jurídicas que oferten en consorcio deberán constituirlo en dicha plataforma y obtener el número de consorcio correspondiente. De no hacerlo, la oferta no podrá considerarse consorcial, aunque se aporte como anexo un acuerdo consorcial.

4.4.3      La oferta deberá responder todos los requerimientos del pliego de condiciones e indicar con claridad la experiencia y demás requisitos aplicables, así como cuál integrante del consorcio acredita cada uno.

4.4.4      En todos los casos, deberá presentarse el acuerdo consorcial debidamente firmado por las partes, en el cual se identifiquen sus integrantes y las obligaciones que asumirá cada uno.

4.4.5      Todos los miembros del consorcio serán solidariamente responsables.

4.4.6      Para efectos de esta licitación, cuando no exista una figura jurídica que formalice el consorcio, quien presente la oferta en el Sistema Integrado de Compras Públicas (SICOP) actuará como enlace ante el BCCR para todo lo relacionado con esta contratación.