ESPHF-AD-010(5) Nombre de la compra: Plataforma … · Debe soportar sumarización de rutas (route...

ESPHF-AD-010(5)

Cartel para Contratación de Servicios

Nombre de la compra: Plataforma de Borde de servicios de conectividad, corta-

fuegos y balanceo de cargas para el proyecto de Compro-

bante Electrónico

Fecha: 30/8/2016

I. Objetivo de la Compra

Dentro de los servicios que se integran en el proyecto de Comprobantes Electrónicos, se

requiere una arquitectura que conforme una capa de borde que supla servicios de conectivi-

dad, corta-fuegos y balanceo de cargas. Por lo tanto, la presente contratación tiene como

objetivo la adquisición de los componentes necesarios, así como los servicios de instala-

ción, licencias, configuración, puesta en marcha y gestión de la plataforma durante el plazo

de la contratación.

II. Objetivo Específico de la Compra

Adquisición de una plataforma con componentes de Firewall -corta fuegos- Balanceadores-

y gestores de administración, con servicios de instalación, configuración, puesta en marcha,

soporte de fabricante, mantenimiento reactivo, mantenimiento preventivo, y gestión de la

plataforma por el plazo del contrato, se deben incluir los niveles de hardware, software, y

licenciamiento requeridos para el óptimo funcionamiento de la plataforma como se detalla

en la sección de especificaciones técnicas. A continuación, se detalla la lista de componen-

tes tecnológicos y los servicios requeridos para la presente contratación:

1. Firewall de Nueva Generación

a. Instalación y configuración

b. Garantía de fabricante

c. Licenciamiento

d. Entrenamiento

2. Balanceadores de Carga

a. Instalación y configuración

b. Garantía de fabricante

c. Licenciamiento

d. Entrenamiento

3. Mantenimiento correctivo y preventivo de la solución

4. Gestión de la plataforma de la solución

ESPHF-AD-010(5)


III. Requisitos de Admisibilidad

Por la importancia y el nivel de criticidad que este proyecto representa para ESPH y los

servicios que se brindarán a terceros con la infraestructura a adquirir, la ESPH y el oferente

deberán cumplir como mínimo con las siguientes especificaciones, la oferta que no cumpla

con los siguientes requisitos quedará declarada inadmisible:

1. No se admitirán ofertas en consorcio, en conjunto o subcontratación de ningún tipo,

tampoco se aceptarán ofertas parciales por líneas independientes, el oferente que

presente su oferta deberá incluir la totalidad del requerimiento descrito en cada pun-

to de este cartel.

2. Únicamente se aceptarán ofertas de oferentes que estén debidamente domiciliadas

en Costa Rica, además el oferente oferente deberá contar con el mayor nivel de cer-

tificación que exista en el país para las marcas que esté ofertando, para comprobarlo

deberá presentar el diagrama con los niveles disponibles para Costa Rica.

3. Cada oferente debe presentar la certificación respectiva de al menos 3 (tres) clien-

tes diferentes en el país a los que el oferente les haya brindado los servicios de im-

plementación y soporte de soluciones de seguridad. Cada carta debe cumplir como

mínimo con los siguientes requisitos:

Estar dirigida a ESPH indicando como referencia el número de contratación

Estar escritas en idioma español

En cada carta se debe incluir el nombre de la empresa o institución, persona

de contacto, teléfono, correo electrónico y toda información necesaria para

verificar la veracidad de la carta.

Se debe describir el proyecto realizado, la fecha de implementación y la can-

tidad de usuarios involucrados en el proyecto.

La fecha de emisión de las cartas no deberá tener más de 30 días naturales

de emitida, contados a partir de la fecha de apertura de esta contratación.

4. La solución a ofertar en la línea 1 (Firewall de Nueva Generación) debe aparecer

en el último estudio disponible de Gartner “Enterprise Network Firewall”, en la ca-

tegoría de líder (entiéndase por líder que se ubica en el cuadrante superior derecho),

y también en el último estudio de NSS Labs como Firewall de Próxima Generación

recomendado. Se deberá adjuntar la documentación respectiva que lo compruebe.

5. La solución a ofertar en la línea 2 (Balanceadores de Cargas) debe aparecer en el

último estudio disponible de Gartner “Application Delivery Controllers”, en la ca-

tegoría de líder (entiéndase por líder que se ubica en el cuadrante superior derecho).

6. El oferente deberá demostrar que posee al menos cinco (5) años de ser distribuidor

autorizado directo de las marcas que oferte. Para ello debe entregar una certificación

del Fabricante con los siguientes Requisitos:

Cantidad de años de representar la marca

Nivel de Certificación (solamente se aceptará el mayor grado de certifica-

ción en el país).

Cantidad de técnicos certificados y su nivel.

ESPHF-AD-010(5)


Autorización expresa del fabricante para participar en el presente proceso

cartulario. Dicha carta deberá indicar el número de la licitación y el nombre

de la misma.

La fecha de emisión de la nota no deberá tener más de 30 días naturales de emi-

tida, contados a partir de la fecha de apertura de esta contratación y dirigida a la

presente licitación.

7. Para la solución de Firewall de Nueva Generación, el oferente deberá contar con al

menos 4 (cuatro) profesionales con la certificación de experto en la solución de Fi-

rewall, para lo cual deberá adjuntar una copia de dicha certificación en la oferta.

8. El oferente debe tener al menos uno de los profesionales con la certificación de Se-

curity Master de la marca ofertada de firewall. Debe adjuntarse a la oferta una copia

de la certificación.

9. Para la solución de Balanceo, el oferente debe tener al menos dos profesionales con

la certificación de especialista en la solución de Balanceo ofertada. Dicha certifica-

ción deberá encontrarse vigente al momento de la publicación de la presente licita-

ción.

10. El oferente debe tener al menos uno de los profesionales con la certificación Certi-

fied Information Systems Security Profesional (CISSP).

11. Todo el personal aportado para los puntos 7, 8, 9 y 10 deberá ser parte de la planilla

de la empresa oferente por al menos un año consecutivo, para lo que se debe aportar

las planillas de la Caja Costarricense del Seguro Social (CCSS) del último año hasta

la fecha de apertura de la presente contratación, que así lo acrediten.

12. Se deberán adjuntar los curriculums y las copias de las certificaciones correspon-

dientes de cada ingeniero aportados para los puntos 7, 8, 9 y 10. Las certificaciones

deben estar vigentes al momento de presentación de la oferta y durante la ejecución

del contrato, en caso de resultar adjudicado.

13. La solución ofertada deberá entregarse bajo la modalidad “llave en mano”, y debe

incluir:

13.1. Los equipos solicitados en este cartel con las características, especificaciones

y funcionalidades, así como todos los accesorios necesarios para su correcto y

total funcionamiento de lo requerido en el cartel.

13.2. Instalación y configuración completa de la solución que se solicitan en este

cartel y a satisfacción de la ESPH.

13.3. Entrenamiento certificado incluyendo el examen de certificación, para las lí-

neas 1 y 2 de las Especificaciones de la Arquitectura.

Lo anterior deberá cumplirse según las especificaciones establecidas en los

puntos 4 y 7 de las líneas 1 y 2 respectivamente. Las capacitaciones han de ser

presenciales y deben incluir el material de estudio tanto para la teoría como pa-

ra las prácticas de laboratorio.

13.4. El oferente debe incluir en su oferta todos los patchcords (UTPs y F.O.) nece-

sarios para interconectar la solución ofertada contra una arquitectura conver-

gente que demandará servicios de la plataforma que es objeto de esta contrata-

ción y la cual dispone de puertos de 1Gbps y de 10Gbps. El oferente debe indi-

car si requiere que ESPH provea en los equipos de la arquitectura convergente

ESPHF-AD-010(5)


los Gbics necesarios para la interconexión, y especificar el tipo y cantidad re-

querido.

13.5. Se proveerá por parte de ESPH 8 puertos de 10Gb en el Switch Core, 4 en ca-

da uno. ESPH proveerá adicionalmente puertos de cobre para la conexión de

los puertos de Management de los equipos.

13.6. Contrato de soporte para la infraestructura especificada en el punto III de este

cartel.

IV. Especificaciones de la Arquitectura y Servicios de La Contratación

Se detallan a continuación, las características específicas de la solución y servicios a contra-

tar:

LINEA 1. FIREWALL DE NUEVA GENERACIÓN:

CANTIDAD DE SUMINISTROS REQUERIDOS

SUMINISTRO / ITEM O RENGLÓN CANTIDAD & TIPO

Dispositivos de Protección Perimetral Firewall de

Nueva Generación (Literal 1 y 2)

Dos (2) Dispositivos de tipo “Ap-

pliance” de Propósito Específico

operando en alta disponibilidad.

Licencia para Administración Centralizada, Corre-

lación de Eventos y Reportes

(Literal 3)

Una (1) Licencia para Servidor

(Servidor será suministrado por la

Entidad)

ESPECIFICACIONES DE LA SOLUCIÓN DE PROTECCIÓN PERIMETRAL FIRE-

WALL DE NUEVA GENERACIÓN EN ALTA DISPONIBILIDAD CON ADMINIS-

TRACIÓN CENTRALIZADA, CORRELACIÓN DE EVENTOS Y REPORTES.

1. REQUERIMIENTOS DE HARDWARE PARA LOS DISPOSITIVOS DE SEGU-

RIDAD.

Se requiere de dos (2) dispositivos operando en alta disponibilidad. Cada dispositivo

debe cumplir con los siguientes requerimientos de capacidad, rendimiento y funcio-

nalidades de seguridad:

1.1. Requerimientos de Capacidad y Rendimiento:

1.1.1. El dispositivo debe soportar al menos 58 Gbps de Throughput Firewall y

al menos 10 Gbps de throughput de Firewall con control de aplicaciones

e IPS activo simultáneamente.

ESPHF-AD-010(5)


1.1.2. Debe soportar al menos 30 Gbps de throughput de firewall en produc-

ción medido con tráfico real.

1.1.3. Debe soportar al menos 3 millones de conexiones concurrentes.

1.1.4. Debe soportar al menos 180,000 conexiones por segundo.

1.1.5. Debe soportar al menos 10 Gbps de tráfico VPN con cifrado AES-128 o

superior.

1.1.6. Debe soportar al menos 1000 vlans.

1.1.7. Debe soportar link aggregation (802.3ad)

1.1.8. Debe soportar implementación en modo transparente (capa 2) o en modo

Router (capa 3)

1.1.9. El equipo debe soportar Alta disponibilidad en modo activo/activo y ac-

tivo/pasivo. Debe soportar sincronización de sesiones para el tráfico ci-

frado y no cifrado. Contar con mecanismos de detección de fallas y de-

tección de pérdida de enlaces.

1.1.10. Debe incluir al menos 10 interfaces Ethernet RJ45 en cobre.

1.1.11. Debe incluir al menos 6 interfaces de fibra de 10 Gbps SFP+

1.1.12. Debe incluir doble fuente de poder redundante cambiable en caliente

(hot swap)

1.1.13. Debe incluir al menos 24GB RAM y disco redundante de al menos 1TB.

1.1.14. Debe incluir al menos una (1) tarjeta LOM (Lights Out Management)

1.1.15. Debe incluir al menos cuatro (4) Firewalls Virtuales por equipo.

2. REQUERIMIENTOS DE FUNCIONALIDADES DE SEGURIDAD

2.1. Requerimientos de manejo avanzado de tráfico

2.1.1. Debe soportar Bootp/DHCP Relay

2.1.2. Debe soportar sumarización de rutas (route aggregation) y redistribución

de rutas a otros protocolos (route redistribution).

2.1.3. Debe soportar ruteo dinámico con RIP versión 2, OSPFv2, y BGP ver-

sión 4. Estos 3 protocolos deben ser soportados también en IPv6

2.1.4. Debe poseer mecanismo de control de ancho de banda donde permita ga-

rantizar tráfico que aplique a grupos de conexiones o conexiones indivi-

duales.

2.1.5. Debe soportar control de ancho de banda basado en prioridades de pesos.

2.1.6. Debe poder realizar límites de ancho de banda para controlar tráfico no

crítico.

2.1.7. Debe soportar LLQ (Low Latency Queuing)

2.1.8. Debe poder realizar balanceo de carga para distribuir tráfico entre varios

servidores, ya sea en modo de balanceo o en modo de alta disponibili-

dad.

2.1.9. Debe soportar servicios diferenciados integrados (DiffServ)

ESPHF-AD-010(5)


2.1.10. Debe soportar redundancia de proveedores de internet, en modo balan-

ceo de carga o primary/backup

2.1.11. Debe tener capacidades de aceleración de conexiones.

2.1.12. El software de aceleración debe soportar los modos de alta disponibili-

dad del equipo, ya sea activo/activo o activo/pasivo.

2.1.13. El motor de alta disponibilidad debe tener sincronización de estado, y és-

te sea soportado con el protocolo de alta disponibilidad propietario por el

fabricante y por soluciones de terceros de alta disponibilidad.

2.1.14. La solución de alta disponibilidad debe soportar conexiones asíncronas.

2.1.15. Debe tener mecanismos de detección de engaños de IP, donde paquetes

externos a la red usan direcciones internas para saltarse los controles de

seguridad.

2.1.16. La consola de administración también debe permitir monitorear el estado

de la alta disponibilidad.

2.2. Requerimientos de funcionalidades básicas necesarias

2.2.1. Network Address Translation (NAT), automático y manual, y granular

para diferentes orígenes, destinos y servicios.

2.2.2. Capacidad de hacer Alta Disponibilidad de proveedor de servicio de In-

ternet.

2.2.3. Debe soportar exportar la configuración del sistema, ya sea de forma

manual o programada.

2.2.4. Debe soportar túneles VPN punto a punto

2.2.5. Debe soportar túneles de acceso remoto

2.2.6. Licencia incluida para crear VPN para el acceso remoto de usuarios tipo

móviles mediante IPSec.

2.2.7. Licencia incluida para crear VPN para el acceso remoto de usuarios tipo

móviles mediante SSL, sin necesidad de instalar un cliente previo.

2.2.8. Pueda validar VPN por medio de certificados digitales o llaves secretas.

2.2.9. Soportar VPN con IKEv1 y IKEv2

2.2.10. Posibilidad de cifrado por medio de DES, 3DES, AES-128 y AES-256.

Y revisión de integridad con MD5 y SHA-1.

2.2.11. Debe incluir soporte para topologías Sitio a Sitio todos contra todos (Full

Mesh), Oficinas remotas hacia oficina central (Topología Estrella), Hub

y Spoke (Sitio remoto a través del sitio central hacia otros sitios).

2.2.12. Capacidad de realizar SSL VPN a dispositivos móviles iPho-

nes/iPad/Android.

2.2.13. La solución debe soportar redundancia de proveedor de Internet, en mo-

dos activo/pasivo y activo/activo.

ESPHF-AD-010(5)


2.3. Requerimientos para Sistema de Prevención de Intrusos

2.3.1. La solución debe proveer un sistema de prevención de intrusos (IPS) in-

tegrado a la solución de seguridad.

2.3.2. Debe proveer miles de protecciones preventivas y proactivas out-of-the-

box.

2.3.3. Debe proveer cobertura de protecciones para amenazas de clientes, ser-

vidores, sistemas operativos, infecciones de malware y gusanos.

2.3.4. Debe soportar protección basada en ubicación geográfica.

2.3.5. Debe inspeccionar el tráfico SSL

2.3.6. Debe soportar aceleración de inspección IPS.

2.3.7. Debe soportar software configurable para realizar bypass en caso de alta

carga, para garantizar rendimiento de red.

2.3.8. Debe tener protección contra ataques DoS

2.3.9. Debe permitir creación de grupos de protecciones o perfiles.

2.3.10. Debe traer perfiles de protecciones predefinidos out-of-the-box.

2.3.11. La solución debe tener las siguientes características clave: resistencia a

evasiones, control granular, confianza y precisión en sus protecciones.

2.3.12. Debe soportar distribución de inspección de IPS para correr en paralelo

entre múltiples cores del procesador.

2.3.13. Debe tener tecnología de inspección del orden de llegada de los paque-

tes, de modo que ayude contra ataques relacionados al orden de los pa-

quetes.

2.3.14. Debe proteger contra ataques complejos y elusivos. Ésta inspección debe

soportar aceleración.

2.3.15. Debe soportar inspección de firmas en múltiples partes de los paquetes

como lo son URL, encabezados de HTTP; y análisis de protocolos de

múltiples conexiones como tráfico de voz sobre IP.

2.3.16. Contar con mecanismo de detección de amenazas de múltiples niveles o

métodos: detección por firmas en vulnerabilidades, validación de proto-

colos, detección de anomalías, detección basada en comportamiento y

correlación de múltiples elementos.

2.3.17. Debe poder aplicar nuevas protecciones al mismo tiempo que protege la

red de ataques. Con protección en tiempo real y actualizaciones de pro-

tecciones para: vulnerabilidades, malware, tunneling, control de aplica-

ciones y ataques genéricos.

2.3.18. Debe soportar creación de firmas personalizadas basado en lenguaje de

código abierto.

2.3.19. Debe soportar un ambiente de pruebas aislado -sandbox- para probar las

nuevas protecciones sin impactar la red.

2.3.20. Debe soportar activación de protecciones basado en su nivel de severi-

dad, confianza y nivel de impacto en rendimiento.

2.3.21. Debe poder realizar captura de tráfico para análisis forense.

ESPHF-AD-010(5)


2.3.22. Debe soportar marcar protecciones como seguimiento para análisis pos-

terior.

2.3.23. Debe proveer información detallada de cada protección, que incluya des-

cripción de la amenaza, severidad, nivel de impacto en rendimiento y

confianza de la protección.

2.3.24. Debe soportar realizar excepciones a las protecciones.

2.4. Requerimientos para compra futura de control de acceso remoto desde

dispositivos móvil

2.4.1. Solución de acceso remoto a aplicaciones corporativas para dispositivos

smartphones, tablets o PCs.

2.4.2. Debe soportar conexión segura mediante tecnología SSL VPN SSL, y

tecnología de conexión VPN de Capa 3

2.4.3. Verificación de usuarios con autenticación de dos (2) factores.

2.4.4. Proveer conectividad VPN basada en cliente y vía web.

2.4.5. Para dispositivos móviles debe proteger ante robo de dispositivo median-

te bloqueo de dispositivo o borrado remoto de datos corporativos (remo-

te-wipe)

2.4.6. Verificación de cumplimiento de requerimientos mínimo de portátiles.

2.4.7. El Portal VPN basado en web debe incluir capacidades de Prevención de

Intrusos Integrada que proteja de código malicioso y ataques como SQL

injection y Cross site scripting.

2.4.8. Portal web integrado para acceder a las aplicaciones web, archivos com-

partidos e email.

2.4.9. Portal web debe soportar múltiples lenguajes

2.4.10. Portal web debe ser personalizable.

2.5. Requerimientos de control de aplicaciones

2.5.1. Capacidad para identificar, permitir, bloquear o limitar el uso de las apli-

caciones por usuario o grupos limitando de esta forma la web 2.0, redes

sociales, independientemente del puerto o protocolo o técnica evasiva

para atravesar la red.

2.5.2. Le debe permitir a los administradores crear definiciones de políticas

muy granulares.

2.5.3. Contar con aplicación clasificadora de biblioteca la cual le permite esca-

neo y detección de más de 4,800 aplicaciones diferentes y más de

300.000 widgets web 2.0 como mensajería instantánea, redes sociales

video streaming, VoIP, jugos entre otros.

2.5.4. Debe contar con más de 150 categorías basadas en criterios como tipos

de aplicaciones, nivel de riesgo de seguridad, uso de recursos e implica-

ciones de productividad.

ESPHF-AD-010(5)


2.5.5. Debe contar con un identificador de usuario el cual le permite enviar

alertas a los empleados en tiempo real acerca de sus limitaciones de ac-

ceso a aplicaciones.

2.5.6. Debe prevenir infecciones de malware provenientes de aplicaciones y

widgets de redes sociales.

2.6. Requerimientos para compra futura de filtrado de navegación

2.6.1. Solución debe tener un motor integrado de control de navegación web

con categorización en la nube en tiempo real y con más de 200 Millones

de sitios categorizados.

2.6.2. Debe prevenir infecciones de malware y propagación luego de infección.

2.6.3. Debe aplicar seguridad SafeSearch a los motores de búsqueda.

2.6.4. Debe contar con un identificador de usuario el cual le permite enviar

alertas a los empleados en tiempo real acerca de sus limitaciones de ac-

ceso a sitios web.

2.6.5. Soportar mínimo de 50 categorías

2.6.6. Debe proteger a los usuarios contra explotaciones de vulnerabilidades de

los exploradores web.

2.6.7. Debe poder filtrar tráfico cifrado HTTPS sin realizar inspección SSL.

2.6.8. Debe prevenir que los usuarios se salten las políticas de seguridad me-

diante la utilización de proxies externos.

2.6.9. Debe filtrar páginas traducidas y en cache.

2.6.10. Debe permitir control granular para aceptar, bloquear o limitar acceso

basado en usuarios, grupos o máquinas para sitios específicos o catego-

rías completas.

2.6.11. Debe permitir configurar una política de NO inspección HTTPS/SSL pa-

ra URLs personalizados

2.6.12. Se debe poder crear reglas que apliquen a un URL específico definido

como una Expresión Regular de modo que filtre para un URL complejo.

2.7. Requerimientos para compra futura de protección antivirus

2.7.1. Solución integrada para prevención de virus y amenazas.

2.7.2. Prevenir infecciones de malwares a nivel de gateway.

2.7.3. Sistema de inspección debe contener más de 4 millones de firmas de vi-

rus y más de 250,000 sitios conocidos como fuentes de infección.

2.7.4. Protección en tiempo real en la nube.

2.7.5. Eliminar virus en los archivos descargados

2.7.6. Motor de inspección basado en firmas y análisis de comportamiento

2.7.7. Debe poder evitar que se visiten sitios conocidos con infecciones.

2.7.8. Brindar protección en los protocolos HTTP, HTTPS, FTP, POP3 y

SMTP

ESPHF-AD-010(5)


2.8. Requerimientos para compra futura de protección contra máquinas infec-

tadas de malwares

2.8.1. Detección de máquinas infectadas con malwares que convierten el equi-

po en tipo zombie enviando tráfico malicioso hacia otras máquinas en la

red y hacia internet. también conocidos como (bots informáticos)

2.8.2. Seguridad en tiempo real en la nube

2.8.3. Bloqueo de comunicaciones bot desde maquinas infectadas

2.8.4. Detección de ataques cibernéticos sofisticados como las Amenazas

Avanzadas Persistentes (APTs)

2.8.5. Prevenir daños de robo de información

2.8.6. Administración centralizada por una sola consola.

2.8.7. Base de datos con un mínimo de 4 millones de firmas de malware

2.8.8. Controles basados en reputación de IP, URL o dirección DNS.

3. REQUERIMIENTOS PARA LA LICENCIA DE ADMINISTRACIÓN CENTRA-

LIZADA, CORRELACIÓN DE EVENTOS Y REPORTES.

Cantidad: una (1) licencia para servidor. El servidor será suministrado por la enti-

dad.

3.1. Requerimientos generales

3.1.1. Se debe proveer una (1) Licencia de Administrador y Reporteo Centrali-

zado para un servidor de propósito general, el cual será suministrado por

la Entidad.

3.1.2. El proveedor debe suministrar en una nota formal las especificaciones

recomendadas del servidor para poder correr esta licencia de administra-

ción.

3.1.3. Esta licencia debe incluir las siguientes funcionalidades: Administración Centralizada y Gestión de Logs

Correlacionador de Eventos y Reporteo

3.1.4. Por crecimiento, esta licencia debe incluir capacidad para gestionar y

administrar las políticas de al menos diez (10) dispositivos de seguridad

firewalls (incluyendo firewalls virtuales).

3.2. Requerimientos de administración de la plataforma

3.2.1. Soportar Gestión de Políticas de forma centralizada para los productos

de seguridad.

3.2.2. Debe tener interfaz gráfica basada en objetos, donde la creación de re-

glas pueda ser creada mediante objetos.

3.2.3. La consola de administración debe hacer verificación de errores en las

políticas creadas antes de aplicarlas.

ESPHF-AD-010(5)


3.2.4. La solución debe permitir revertir la política de seguridad a una versión

anterior.

3.2.5. Debe soportar drag and drop de objetos y deben poder ser reutilizados

entre varias políticas.

3.2.6. Debe soportar administración basada en roles, donde a los administrado-

res se les otorgue perfiles personalizables de administración.

3.2.7. Debe poder auditar los cambios realizados por los administradores

3.2.8. Todos los productos de seguridad deben soportar ser configurados desde

una única consola gráfica.

3.2.9. Debe incluir una Autoridad Certificadora interna X.509, que genere cer-

tificados para los gateways y a los usuarios para fácil autenticación en

los VPNs.

3.2.10. Debe poder soportar una Autoridad emisora de Certificados Externa,

provista por un tercero

3.2.11. Debe soportar agrupación de reglas en secciones etiquetadas para una

administración intuitiva y ordenada.

3.2.12. Debe soportar definición de tiempo de expiración a las reglas de seguri-

dad, de modo que estén activas en intervalos específicos de tiempo.

3.2.13. La consola de administración debe soportar búsqueda de objetos y re-

glas.

3.2.14. Debe tener contador de utilización en las reglas de seguridad, para saber

que tanto se utilizan las reglas. Éste contador debe ser visible en la mis-

ma lista de reglas de seguridad.

3.2.15. La solución debe soportar creación de múltiples versiones de la política

de seguridad de modo que puedan ser consultadas en caso de necesitar

revertir algún cambio. Estas versiones deben poder ser creadas manual o

automáticamente.

3.2.16. La solución debe realizar una verificación de las políticas de seguridad

creadas de modo que no existan conflicto de reglas.

3.2.17. Debe soportar integración con terceros mediante algún lenguaje de códi-

go abierto.

3.2.18. Debe soportar autenticación por una base de datos local, LDAP, TA-

CACS, RADIUS o Secure ID

3.2.19. Debe soportar administración basada en roles.

3.2.20. Debe soportar IPv6

3.3. Requerimientos de gestión de logs

3.3.1. Deberá tener la capacidad a futuro de realizar análisis de auditoría en

tiempo real de los eventos de seguridad.

3.3.2. Búsqueda intuitiva, semejante al sistema de búsqueda de google.

3.3.3. Debe permitir realizar búsquedas granulares para cualquier comunica-

ción o de patrón de tráfico.

ESPHF-AD-010(5)


3.3.4. Debe ser una herramienta sin límite de registros, debe estar limitada solo

por el tamaño del espacio en disco.

3.3.5. Reducir el tiempo de troubleshooting al poder mostrar resultados en

tiempo real.

3.3.6. Debe tener filtros predefinidos de búsqueda y permitir crear y salvar fil-

tros personalizados.

3.4. Requerimientos de identificación de usuarios

3.4.1. Administración centralizada del acceso de usuarios a recursos de la em-

presa y aplicaciones de internet.

3.4.2. Visibilidad y control granular basada en usuarios, grupos de usuarios,

máquinas.

3.4.3. Debe permitir agregar usuarios, grupo de usuarios y maquinas a las de-

fensas de seguridad.

3.4.4. Identificación de usuario integrado a Microsoft Active Directory sin la

necesidad de instalar un agente en el controlador de dominio o en las

máquinas de los usuarios.

3.4.5. Identificación de usuarios y máquinas externas mediante portal captivo.

3.4.6. Identificación de usuarios mediante agentes tanto para estaciones de tra-

bajo como para servidores de aplicaciones como Citrix y Terminal Ser-

vices.

3.4.7. Identificación de los usuarios que se conectan por medio de VPN de ac-

ceso remoto, para clientes SSL VPN y IPSec VPN.

3.5. Visualizador de Eventos de Seguridad

3.5.1. La solución debe incluir un módulo integrado de correlación de eventos

que permita visibilidad de los productos de seguridad en tiempo real.

3.5.2. Debe incluir reportes predefinidos y personalizables.

3.5.3. Debe incluir un portal web para que otros administradores puedan visua-

lizar y monitorear los eventos.

3.5.4. Debe incluir vistas detalladas y análisis forense.

3.5.5. Debe incluir vistas personalizables por los administradores.

3.5.6. Debe correlacionar múltiples eventos en búsqueda de actividad sospe-

chosa.

3.5.7. Debe tener un mapa-m undi para visualización de eventos basados en re-

giones.

3.5.8. Debe permitir crear reglas de correlación personalizadas.

3.5.9. Debe tener un sistema de tiquetes para asignación de eventos a adminis-

tradores.

3.5.10. Debe incluir mecanismos de alertas automatizadas para eventos críticos

ESPHF-AD-010(5)


3.6. Módulo de Reportes

3.6.1. La solución debe incluir un módulo de reportes centralizado que conso-

lide los eventos de seguridad de la plataforma propuesta.

3.6.2. Debe incluir reporteo centralizado para eventos de seguridad, actividad

de red y de usuarios.

3.6.3. Debe permitir personalización de reportes.

3.6.4. Debe incluir reportes predefinidos

3.6.5. El módulo de reportes debe ser parte integral de la solución propuesta.

3.6.6. Debe realizar consolidación de eventos para aprovechar espacio en dis-

co.

3.6.7. Debe poder realizar entrega de reportes de forma automatizada utilizan-

do diversos métodos de entrega, como mínimo: web, email y ftp.

3.6.8. Reportes personalizables en periodo del reporte, fuentes de información,

filtros de contenido, estilo del reporte y calendarización.

4. REQUERIMIENTOS GENERALES

4.1.Instalación y configuración

Requisitos mínimos para la instalación y configuración de la solución ofertada

para la línea 1 (Firewall de Nueva generación). El proyecto debe entenderse

como un “proyecto llave en mano”, en donde la solución completa se instala, se

configura y se coloca en ambiente de producción todo el equipamiento y softwa-

re adquirido a entera satisfacción de ESPH, también se deben incluir los servi-

cios de gestión de la plataforma por el plazo de la contratación (36 meses, pro-

rrogable a 12 meses más).

4.1.1. Durante los primeros 3 días hábiles posteriores a la entrega de la orden

de compra, el adjudicatario debe coordinar una reunión de pre-

implementación con el personal de ESPH (Líder de Proyectos y profe-

sionales responsables de cada área). Con la presentación de la oferta

donde deberá presentar un cronograma y plan de trabajo indicando las

actividades a realizar, el plazo estimado y el personal asignado para cada

tarea.

4.1.2. El proveedor adjudicado deberá contabilizar e informar a ESPH de los

espacios necesarios en Rack para la instalación física de los equipos, la

alimentación eléctrica y los cables “Patch Cord” y puertos en los swit-

ches de Core y Management necesarios para la interconexión de los

equipos de la solución y cualquier otro aditamento necesario para que el

personal técnico dispuesto por el oferente realice el empotrado correcto

de los equipos en el rack indicado para cada equipo.

ESPHF-AD-010(5)


4.1.3. Deben incluirse en la propuesta todos los cables, conectores y dispositi-

vos necesarios para la correcta instalación y operación de los equipos

adquiridos, asimismo como el software, programas, licenciamiento y

cualquier otro componente para la correcta operación de los mismos.

4.1.4. El personal técnico dispuesto por el proveedor adjudicado deberá reali-

zar las tareas de instalación física bajo la supervisión del personal de

ESPH asignado directamente en el Centro de Datos, de acuerdo al plan

de trabajo revisado y aprobado entre las partes.

4.1.5. El proveedor adjudicado deberá colocar una etiqueta impresa con tinta

permanente adherida en la tapa superior de cada equipo en el que se in-

dique la siguiente información:

Nombre, teléfono y contacto del proveedor adjudicado.

Ultima fecha de garantía de cada equipo.

Modelo y Serie del equipo.

4.2. El proveedor adjudicado deberá configurar las interfaces de administra-

ción con los que cuentan los equipos para acceso remoto de conformidad

con las indicaciones del personal de ESPH.

4.2.1. La instalación y configuración deberá llevarse a cabo por el personal cer-

tificado del adjudicatario aportado en la oferta.

4.2.2. El contratista deberá dejar la solución instalada con al menos las siguien-

tes configuraciones:

Configuración en alta disponibilidad entre ambos equipos de ma-

nera que si el equipo principal falla el secundario pueda asumir

las tareas.

Configuración de reglas de firewall en conjunto con el personal

de ESPH

Implementación y activación del perfil “default” de IPS.

Configuración de reglas de NAT

Sesiones de afinamiento de la solución según la necesidad.

Configuración de Virtual System según el requerimiento de

ESPH

Configuración de usuarios Administradores tanto para Consolas

de Administración, CLI, Web.

Documentación de la solución implementada

4.3. Garantía de fabrica

En la oferta se debe considerar una garantía técnica brindada por directamente

por el fabricante con las siguientes especificaciones:

4.3.1. El periodo de cobertura de la garantía técnica no deberá ser menor a 36

meses (3 años) prorrogable a un año más, con la posibilidad de abrir ca-

sos a través del proveedor adjudicado con cobertura 24x7x365.

ESPHF-AD-010(5)


4.3.2. La garantía técnica de la solución requerida deberá comprender, como

mínimo, los defectos de fabricación, componentes y funcionamiento tan-

to en el hardware como en el software.

4.3.3. Se entiende que durante el período de garantía todos los costos de man-

tenimiento (mano de obra, repuestos y otros). De existir un costo durante

el periodo de garantía, el oferente deberá detallarlo claramente e incluir-

lo de una vez en su oferta.

4.3.4. Para brindar el servicio de mantenimiento correctivo, el proveedor adju-

dicado debe contar con un sistema de recepción de llamadas para aten-

ción de solicitudes debidamente constituido, donde el personal de ESPH

pueda hacer sus reportes y exista una persona que atienda y pueda crear

un caso en el portal del fabricante de ser necesario con disponibilidad

24x7. Los reportes de averías, daños o mal funcionamiento, categoriza-

dos como críticos o de emergencia deberán ser atendidos en un plazo no

mayor a una (1) hora hábil a partir de la hora en que ESPH haga el repor-

te.

4.3.5. En caso de presentarse fallas durante el periodo de cobertura de la garan-

tía el proveedor adjudicado deberá encargarse de la coordinación con el

fabricante para el reemplazo de las partes dañadas en un máximo de 2

días naturales a partir del momento que se determina la necesidad del

cambio, sin embargo, el adjudicatario deberá estar en la disposición de

aportar un equipo o parte con características similares al dañado en caso

de ser necesario mientras se recibe el equipo o la parte de reemplazo.

4.4. Licenciamiento

4.4.1. El oferente debe incluir en su oferta todo el software necesario para el

correcto funcionamiento de la solución como se requiere en las especifi-

caciones técnicas de este cartel.

4.4.2. Todas las licencias necesarias para cubrir el requerimiento de este cartel

deben tener una vigencia mínima de 3 años, prorrogable a 1 año más, de

manera que ESPH no tendrá que incurrir en el costo de renovación de

ningún tipo durante dicho.

4.5. Entrenamiento

4.5.1. El proveedor adjudicado debe comprometerse a dar capacitación para al

menos 3 (tres) funcionarios asignados por ESPH en la reunión de pre-

implementación, de tal manera que estén plenamente preparados para

instalar, configurar y dar mantenimiento local a los equipos ofertados.

Los mismos deberán estar constituidos de una parte teórica y otra prácti-

ca.

4.5.2. El entrenamiento debe ser certificado por el fabricante de la solución, de

manera que el certificado de participación debe ser emitido por éste.

ESPHF-AD-010(5)


Asimismo, debe brindarse el material didáctico correspondiente para ca-

da participante emitido por el fabricante.

4.5.3. La capacitación debe contemplar al menos 24 horas efectivas, dividida

en tres sesiones presenciales (no virtuales). Incluyendo la realización de

laboratorios y ambientes de pruebas, así como aprender y practicar cam-

bios de políticas, configuraciones y troubleshooting.

4.5.4. La capacitación se debe brindar en un centro de entrenamiento autoriza-

do por el fabricante, de tal manera que los participantes puedan enfocar-

se en capacitarse y así se evita posibles distracciones generadas por so-

porte técnico requerido por los usuarios. En el centro de entrenamiento

autorizado se pueden contar con los equipos necesarios para los laborato-

rios del curso. La fecha será coordinada en la reunión de pre-

implementación.

4.5.5. La capacitación debe ser brindada por personal certificado como instruc-

tor para capacitar personal en el uso de la solución, de tal manera que los

funcionarios participantes estarían capacitados para certificarse como

administradores de la solución después de su participación.

4.5.6. La empresa oferente debe tomar en cuenta en su oferta el costo del exa-

men de certificación para los tres funcionarios, de manera que al termi-

nar se entregará a cada estudiante un Boucher para la aplicación del

examen.

4.5.7. Se debe incluir en la oferta la información con respecto a los siguientes

aspectos sobre la capacitación:

Temario

Tipo de curso

Alcances, objetivos, descripción

Fecha y lugar donde se impartirá el curso

Condiciones de estadía, alimentación y transporte

Nombre, formación y experiencia de los instructores.

Material didáctico del curso.

4.5.8. Se debe incluir en la oferta el currículo de los instructores y los atestados

correspondientes que respalden el dominio pleno sobre los tópicos men-

cionados.

ESPHF-AD-010(5)


LINEA 2. BALANCEADORES DE CARGAS:

CANTIDAD DE SUMINISTROS REQUERIDOS

SUMINISTRO / ITEM O RENGLÓN CANTIDAD & TIPO

Dispositivos de Balanceo de Cargas

(Literal 1 y 2)

Dos (2) Dispositivos de tipo

“Appliance” de Propósito

Específico operando en alta

disponibilidad.

Licencia para Administración Centralizada, Reportes

(Literal 3)

Una (1) Licencia para Servi-

dor (Servidor será suministra-

do por la Entidad)

ESPECIFICACIONES DE LA SOLUCIÓN DE BALANCEO DE SERVIDORES EN AL-

TA DISPONIBILIDAD CON ADMINISTRACIÓN CENTRALIZADA Y REPORTES

5. REQUERIMIENTOS DE HARDWARE PARA LOS BALANCEADORES DE

CARGA.

5.1. Requerimientos Generales

5.1.1. Cantidad de equipos: 2 (dos), Configurados en HA

5.1.2. Cada equipo debe tener las siguientes interfaces físicas:

Capacidad para 24 interfaces que soporten SFP+ de fibra de 1 o

10

2 módulos SFP+ 10GBASESR

5.1.3. Throughput L4 Inicial 30 Gbps por equipo

5.1.4. Crecimiento de throughput por licencias hasta el doble de su capacidad

inicial, sin necesidad de cambiar el equipo.

5.1.5. Cantidad de soportar al menos 20 Millones de conexiones L4 concurren-

tes por equipo

5.1.6. Capacidad de soportar al menos 1.4 Millones de conexiones por segundo

CPS por equipo

5.1.7. Capacidad de soportar al menos 2.2 Millones de RPS L7 por equipo

5.1.8. Debe contar con aceleración de Hardware SSL

5.1.9. Capacidad de conexiones SSL por segundo con llave de 2048 bit de has-

ta 13000 por equipo

5.1.10. Capacidad de Throughput SSL de 16 Gbps con llaves de 2048 bits

5.1.11. Capacidad de soportar en el mismo equipo mediante upgrade de hardwa-

re hasta 68000CPS con llaves de 2048 bits

5.1.12. El sistema debe inicialmente tener cinco (5) instancias virtuales y debe

escalar por licencias hasta diez (10) instancias sin modificar el hardware

de la máquina por equipo o hasta treinta y dos (32) instancias mediante

upgrade de hardware en el mismo appliance.

ESPHF-AD-010(5)


5.1.13. La solución de Application Delivery Controller deberá estar ubicada en

el cuadrante Leaders del informe Gartner Magic Quadrant for Applica-

tion Delivery Controllers 2015.

5.1.14. El sistema debe incluir fuentes de poder redundantes

5.1.15. El sistema soporta balanceo de carga desde capa 4 a capa 7 tomando

como referencia el modelo OSI soportando IP, TCP y UDP

5.1.16. El sistema soporta servidores virtuales que escuchen en puertos TCP y

UDP

5.1.17. El sistema soporta servidores virtuales que escuchen en un rango de

puertos

5.1.18. El sistema soporta servidores virtuales que escuchen en un rango de di-

recciones IP destino

5.1.19. El sistema soporta switch de paquetes por contenido, con lo cual es posi-

ble enrutar tráfico a distintos grupos de servidores reales con base en el

contenido de capa 7


5.2.1. El sistema debe soportar de salud

ICMP

LDAP y LDAPS

FTP

SNMP

DNS

IMAP4

NNTP

POP3

Radius

RTSP

SSL Hello

UDP

SIP TCP y SIP UDP

Por Puerto físico

5.2.2. Soporta monitoreos de salud TCP / UDP configurables

5.2.3. Soporta monitoreos de salud HTTP / HTTPS, los cuales marcarán los

servicios como no disponibles con base en contenido específico de la

página

5.2.4. El sistema debe proveer monitoreos de salud de capa de aplicación pre-

definidos y configurables

5.2.5. El sistema soporta monitoreos de salud compuestos

5.2.6. El sistema soporta scripting en el monitoreo de salud

5.2.7. El sistema soporta configurar la frecuencia del monitoreo de salud

5.2.8. El sistema soporta configurar el intervalo de timeout para cada monito-

reo de salud

ESPHF-AD-010(5)


5.2.9. El sistema soporta la definición de múltiples reintentos antes de marcar

el servidor como caído.

5.3. Redirección de tráfico

5.3.1. Soporta balanceo de carga de L4 a L7 con base en la dirección IP origen

o la dirección IP destino

5.3.2. Soporta balanceo de carga de L4 a L7 con base en el contenido de la

aplicación

5.3.3. El sistema soporta balanceo de carga con base en el tiempo de respuesta

de la aplicación

5.3.4. El sistema soporta balanceo de carga con base en el ancho de banda

5.3.5. El sistema soporta balanceo de carga con base en los usuarios concurren-

tes

5.3.6. El sistema soporta balanceo de carga con base en pesos relativos asigna-

dos a servidores reales

5.3.7. El sistema soporta balanceo de carga con base en datos SNMP

5.3.8. El sistema soporta balanceo de carga round robin y algoritmos de

hashing

5.3.9. El sistema soporta balanceo de carga con base en el menor número de

conexiones

5.3.10. El sistema es capaz de tomar decisiones de tráfico con base en cookies

estáticas y dinámicas

5.4. Persistencia

5.4.1. El sistema soporta persistencia con base en:

Parámetros de capa 3 y capa 4

IP origen

Cookies estáticos y dinámicos

SSL Session ID

IP Hashing

Valores del header de HTTP

5.5. Modificaciones de paquetes

5.5.1. El sistema soporta inyección de cookies en relación a persistencia

5.5.2. El sistema soporta modificación de los datos del header en HTTP y

HTTPS Inyección, borrado, modificación Request y Reply

5.5.3. El sistema cuenta con la capacidad de scripting para tráfico HTTP y no

HTTP

5.6. TCP Multiplexing

5.6.1. El sistema soporta multiplexación de sesiones TCP

5.6.2. El sistema permite escoger si la multiplexación se realiza por conexión o

por request

ESPHF-AD-010(5)


5.7. Compresión

5.7.1. El sistema soporta compresión HTTP

5.7.2. El sistema soporta compresión selectiva para evitar problemas de com-

presión conocidos en browsers comunes

5.7.3. El sistema soporta compresión HTTP

5.8. Cache

5.8.1. El sistema soporta web caching en compliance con RFC 2616. También

tiene la habilidad de realizar override sobre el RFC

5.8.2. El sistema soporta técnicas de optimización de caching, como reescribir

atributos

5.8.3. El sistema debe optimizar los tiempos de cacheo del browser, a través de

la manipulación de objetos en el header

5.9. Virtualización

5.9.1. La solución debe soportar instancias virtuales de balanceo que corran

sobre un hypervisor de balanceo especializado

5.9.2. Aislamiento completo entre las instancias virtuales. Fallas en una instan-

cia, no debe afectar a las otras.

5.9.3. El sistema debe soportar el reset de instancias virtuales individualmente

5.9.4. El sistema soporta múltiples imágenes de software por cada balanceador

virtual. Cada balanceador podrá correr una imagen de software distinta.

5.9.5. Los recursos físicos son reservados para cada instancia virtual

5.9.6. Los recursos físicos asignados a las instancias virtuales de balanceo, no

son compartidos entre ellas.

5.10. Monitor de SLAs o rendimiento de las aplicaciones Web

5.10.1. La solución debe incluir todo el hardware necesario para realizar la fun-

cionalidad de monitor de niveles de servicio y/o rendimiento de las apli-

caciones Web

5.10.2. Se debe incluir el licenciamiento por 4 años

5.10.3. Debe habilitar el monitoreo end to end, desde el usuario final hasta la

aplicación Web

5.10.4. Debe dar información de tiempo de respuesta por aplicación, por

transacción y ubicación geográfica

5.10.5. Debe permitir el establecimiento de los SLA por aplicación y configurar

alarmas cuando dichos SLA no se cumplan

5.10.6. Debe permitir medir la calidad de experiencia de los usuarios mediante

la medición mínimo del tiempo de respuesta de los servidores, la red (in-

cluyendo la red del usuario final), y el tiempo de rendering de la aplica-

ción

5.10.7. La solución de monitoreo no debe requerir la instalación de agentes en

los equipos de los usuarios y debe correr de forma transparente en las

aplicaciones Web

ESPHF-AD-010(5)


5.10.8. Debe incluir un portal en la herramienta de gestión que permita visuali-

zar los niveles de servicios desde la perspectiva del datacenter y del

usuario.

5.11. Web Performance Optimization (Aceleración trafico Web)

5.11.1. La solución debe incluir todo el hardware y software necesario para rea-

lizar la funcionalidad de Web Performance Optimization o aceleración

de tráfico Web

5.11.2. Se debe incluir el licenciamiento por 4 años de servicio

5.11.3. Debe soportar la funcionalidad de Gateway de HTTP 1.1 a HTTP 2

5.11.4. Debe incluir técnicas de aceleración que permita crear templates para

cada browser con el fin de entregar los sitios web de la mejor forma de-

pendiendo del cliente

5.11.5. Debe incluir métodos que permitan hacer cache en el browser del cliente

5.11.6. Debe incluir mecanismos de optimización de los landing page, como los

links que aparecen en los buscadores de páginas web, mejorando la ex-

periencia del usuario

5.11.7. Debe incluir un método de aceleración de flujos que permita que cuando

se visite una página Web el sistema precargue las páginas que los usua-

rios visitan con frecuencia.

5.12. Web Application Firewall

5.12.1. La solución debe incluir todo el hardware necesario para realizar la fun-

cionalidad de Web Application Firewall

5.12.2. Se debe incluir el licenciamiento por los 4 años de soporte

5.12.3. El sistema debe proteger contra las siguientes amenazas:

SQL injection

Cross site scripting (XSS)

Stealth commanding

Backdoor and debug options

Brute force attacks

Data encoding

Unauthorized navigation

Gateway circumvention

Web server reconnaissance

5.12.4. El sistema debe soportar filtros de seguridad que bloqueen ataques de

fuerza bruta.

5.12.5. El sistema debe soportar filtros de seguridad que bloqueen ataques a la

base de datos.

5.12.6. El sistema debe soportar filtros de seguridad que bloqueen ataques de

métodos Http.

5.12.7. El sistema debe soportar filtros de seguridad para proteger las sesiones

de usuarios remotos.

5.12.8. El sistema debe soportar filtros de seguridad que protejan servicios web.

ESPHF-AD-010(5)


5.12.9. El sistema debe reconocer usuarios y debe ser capaz de permitir única-

mente tráfico legítimo.

5.12.10. El sistema debe soportar aprendizaje sin manipulación del adminis-

trador.

5.12.11. El dispositivo permitir la generación de reportes por: aplicaciones,

filtros de seguridad, etc.

5.12.12. Debe soportar los siguientes modos de operación:

Passive – Detección.

Active – Detección y prevención.

Políticas Positivas

Políticas Negativas

5.12.13. El dispositivo debe soportar integración con sistemas de gestión cen-

tralizados.

5.13. Alta disponibilidad

5.13.1. El sistema soporta VRRP para alta disponibilidad y redundancia

5.13.2. El sistema soporta HA activo y activo/pasivo

5.13.3. El sistema soporta agrupación de puertos para suavizar el failover al dis-

positivo de backup

5.13.4. El sistema soporta la replicación de las sesiones a la caja standby

5.14. Red

5.14.1. El sistema soporta agregación de puertos por protocolo IEEE 802.3 ad y

troncales utilizando 802.1q

5.14.2. El sistema soporta IP Forwarding

5.14.3. El sistema soporta RIP, OSPF y BGP

5.14.4. Se puede integrar a la red sin necesidad de realizar modificaciones sobre

la infraestructura IP existente

5.14.5. El sistema soporta auto negociación en los puertos 10/100/1000 de cobre

5.14.6. El sistema soporta SNAT, multiples SNAT para una vlan y Server NAT

5.14.7. El sistema soporta routed mode, transparent mode y despliegue de un so-

lo brazo

5.14.8. El sistema soporta ¨Direct server Return Mode¨

5.15. Administración

5.15.1. El sistema soporta administración centralizada y reportes para todos los

dispositivos desplegados

5.15.2. Administración OUT of BAND. Los puertos de administración están ais-

lados de los puertos de datos

5.15.3. El sistema debe tener puertos de administración redundantes

5.15.4. El sistema cuenta con puerto USB para actualización de software y di-

saster recovery

5.15.5. El sistema soporta Web User interface para toda la configuración del

dispositivo

5.15.6. El sistema soporta administración vía CLI, HTTPS y SSH

5.15.7. El sistema soporta el envío de eventos a través de un syslog

ESPHF-AD-010(5)


5.15.8. El sistema soporta la configuración del balanceador a través de scripts

5.15.9. El sistema soporta el envío de alertas a través de syslog y SNMP

5.15.10. El sistema soporta múltiples destinos para SNMP y SYSLOGS

5.15.11. El sistema soporta múltiples instancias del sistema operativo con la

posibilidad de habilitarlas y deshabilitarlas según se requiera

5.15.12. El sistema soporta múltiples administradores logueados al tiempo en

la interfaz GUI.

5.15.13. El sistema soporta NTP y SNTP

5.15.14. El sistema es capaz de enviar alarmas cuando se exceden ciertos lí-

mites como tráfico, espacio en disco, CPU, etc.

5.15.15. El sistema genera alarma por fallos en componentes de HW o proce-

sos de software.

5.15.16. El sistema genera una alarma por cada cambio administrativo hecho

en el dispositivo

5.15.17. El sistema provee los MIBS completos

6. CONSOLA DE ADMINISTRACIÓN CENTRALIZADA


6.1.1. El sistema debe administrar el sistema de AntiDDoS, balanceadores de

carga, protección SSL y WAF dentro de la misma consola como un úni-

co punto de control.

6.1.2. El sistema debe ser tipo virtual appliance que permita instalarse sobre

vmware en la infraestructura de la entidad.

6.1.3. Se debe incluir las licencias necesarias para poder tener capacidad com-

pleta de realizar cambios y configuraciones de los ADCs, AntiDDoS y

WAF

6.1.4. El sistema soporta administración centralizada para todos los dispositi-

vos que hacen parte de la solución incluyendo los módulos

6.1.5. El sistema soporta Web User interface para toda la configuración del

dispositivo

6.1.6. El sistema soporta un estándar API de la industria para integración con

aplicaciones inhouse

6.1.7. El API se ofrece libre de todo cargo

6.1.8. El API debe estar completamente documentado

6.1.9. El sistema soporta accesos seguros HTTPS, SSH

6.1.10. El sistema soporta el envío de eventos a través de un syslog

6.1.11. El sistema soporta la configuración del balanceador a través de scripts

6.1.12. El sistema provee un dashboard con todos los servicios configurados en

los ADCs de forma centralizada

6.1.13. El sistema soporta RBAC para los administradores de múltiples balan-

ceadores

6.1.14. El sistema soporta RADIUS, TACACS y autenticación local

6.1.15. El sistema soporta el envío de alertas a través de syslog y snmp

ESPHF-AD-010(5)


6.1.16. El sistema soporta múltiples destinos para SNMP y SYSLOGS

6.1.17. El sistema soporta guardar toda la configuración en un servidor remoto

6.1.18. El sistema soporta múltiples administradores logueados al tiempo en la

interfaz GUI.

6.1.19. El sistema soporta NTP

6.1.20. El sistema genera alarma por fallos en componentes de HW o procesos

de software.

6.1.21. El sistema genera una alarma por cada cambio administrativo hecho en

el dispositivo

6.1.22. El sistema provee los MIBS completos

6.1.23. El sistema soporta realización de backups por SCP, FTP, SFTP

6.1.24. El sistema soporta diagnostic tools como core dumps, archivos de confi-

guración, logs, etc

6.1.25. El sistema soporta REST sobre HTTPS

6.1.26. El sistema soporta Chrome, Internet Explorer y Firefox

6.1.27. El sistema soporta al menos 1000 dispositivos administrados

6.1.28. El sistema soporta la configuración de una característica una sola vez y

ser aplicada a múltiples dispositivos simplificando las tareas de opera-

ción

6.1.29. El sistema soporta la creación de scripts personalizados por la entidad

que pueden ejecutarse sobre múltiples dispositivos al mismo tiempo

6.2. Módulo de Monitoreo de Niveles de Servicio

6.2.1. Debe incluir el módulo que habilita el monitoreo end to end, desde el

usuario final hasta la aplicación Web

6.2.2. El capaz de dar información de tiempo de respuesta por aplicación, por

transacción y ubicación geográfica

6.2.3. Permite establecer los SLA por aplicación y configurar alarmas cuando

dichos SLA no se cumplan

6.2.4. Permite segmentar las mediciones de tiempo de respuesta en distintos

puntos de la red.

6.2.5. El sistema incluye un dashboard para visualizar los niveles de servicio

definidos de las aplicaciones WEB balanceadas

6.3. Módulo de Monitoreo y Reportes de Rendimiento de dispositivos de ADC

6.3.1. El sistema soporta la generación de reportes para todos los dispositivos

desplegados

6.3.2. El sistema debe soportar la generación de reportes históricos sobre la

CPU, memoria, utilización de las licencias, utilización de los recursos

del sistema, tráfico, conexiones, aplicaciones balanceadas, throughput y

servidores reales.

6.3.3. El sistema incluye un dashboard para monitorear en tiempo real los dife-

rentes dispositivos monitoreados

ESPHF-AD-010(5)


6.3.4. El sistema incluye un dashboard que permita ver todos los dispositivos

en una única vista que permita ver el estado completo de la solución, uti-

lización de throughput, CPU, sesiones, entro otros.

6.3.5. El sistema soporta reportes históricos en formatos HTML y PDF

6.4. Módulo de reportes históricos de seguridad

6.4.1. El sistema soporta reportes históricos en formatos HTML y PDF

6.4.2. El sistema soporta la generación de reportes de seguridad para todos los

dispositivos tipo WAF desplegados

6.5. Licenciamiento

6.5.1. Se deben incluir las licencias necesarias para los equipos de Balan-

ceo/WAF/AntiDDoS

7. REQUERIMEINTOS GENERALES

7.1. Instalación y configuración

Requisitos mínimos para la instalación y configuración de la solución ofertada

para la línea 2 (Balanceadores de carga). El proyecto debe entenderse como un

“proyecto llave en mano”, en donde la solución completa se instala, se configura

y se coloca en ambiente de producción todo el equipamiento y software adquiri-

do a entera satisfacción de ESPH:

7.1.1. Durante los primeros 3 días hábiles posteriores a la entrega de la orden

de compra, el adjudicatario debe coordinar una reunión de pre-

implementación con el personal de ESPH. Con la presentación de la

oferta deberá presentar un cronograma y plan de trabajo indicando las

actividades a realizar, el plazo estimado y el personal asignado para cada

tarea.

7.1.2. El proveedor adjudicado deberá contabilizar e informar a ESPH de los

espacios necesarios en Rack para la instalación física de los equipos, la

alimentación eléctrica y los cables “Patch Cord” y puertos en los swit-

ches de Core y Management necesarios para la interconexión de los

equipos de la solución y cualquier otro aditamento necesario para que el

personal técnico dispuesto por el oferente realice el empotrado correcto

de los equipos en el rack indicado para cada equipo.

7.1.3. Deben incluirse en la propuesta todos los cables, conectores y dispositi-

vos necesarios para la correcta instalación y operación de los equipos

adquiridos, asimismo como el software, programas, licenciamiento y

cualquier otro componente para la correcta operación de los mismos.

7.1.4. El personal técnico dispuesto por el proveedor adjudicado deberá reali-

zar las tareas de instalación física bajo la supervisión del personal de

ESPH asignado directamente en el Centro de Datos, de acuerdo al plan

de trabajo revisado y aprobado entre las partes.

ESPHF-AD-010(5)


7.1.5. El proveedor adjudicado deberá colocar una etiqueta impresa con tinta

permanente adherida en la tapa superior de cada equipo en el que se in-

dique la siguiente información:

Nombre, teléfono y contacto del proveedor adjudicado.

Ultima fecha de garantía de cada equipo.

Modelo y Serie del equipo.

7.1.6. El proveedor adjudicado deberá configurar las interfaces de administra-

ción con los que cuentan los equipos para acceso remoto de conformidad

con las indicaciones del personal de ESPH.

7.1.7. La instalación y configuración deberá llevarse a cabo por el personal cer-

tificado del adjudicatario aportado en la oferta.

7.1.8. El contratista deberá dejar la solución instalada con al menos las siguien-

tes configuraciones:

Configuración básica y de conectividad en los 3 diferentes am-

bientes que configurará ESPH en una solución de un solo brazo

(one Arm)

Configuración de al menos 2 servicios virtuales por instancia vir-

tual cada uno con 2 servidores reales balanceados

Pruebas de disponibilidad de los servicios balanceados en caso de

falla de uno de los appliances de ADC

Verificación que la solución funcione en caso de fallos de los

servidores reales

Configuración de los usuarios de administración de cada una de

las instancias virtuales y protocolos de gestión

Configuración de la consola de administración monitoreando los

servicios balanceados, y generación de reportes históricos

Configuración de persistencia, algoritmos de balanceo, estado de

salud de los equipos según se requiera para cada uno de los servi-

cios balanceados solicitados.

Documentación de la solución implementada

7.2. Garantía de fabrica

En la oferta se debe considerar una garantía técnica brindada directamente por el

fabricante con las siguientes especificaciones:

7.2.1. El periodo de cobertura de la garantía técnica no deberá ser menor a 36

meses (3 años con opción a prorroga a un año más), con la posibilidad de

abrir casos a través del proveedor adjudicado con cobertura 24x7x365.

7.2.2. La garantía técnica de la solución requerida deberá comprender, como

mínimo, los defectos de fabricación, componentes y funcionamiento tan-

to en el hardware como en el software.

7.2.3. Se entiende que durante el período de garantía todos los costos de man-

tenimiento (mano de obra, repuestos y otros). De existir un costo durante

ESPHF-AD-010(5)


el periodo de garantía, el oferente deberá detallarlo claramente e incluir-

lo de una vez en su oferta.

7.2.4. Para brindar el servicio de mantenimiento correctivo, el proveedor adju-

dicado debe contar con un sistema de recepción de llamadas para aten-

ción de solicitudes debidamente constituido, donde el personal de ESPH

pueda hacer sus reportes y exista una persona que atienda y pueda crear

un caso en el portal del fabricante de ser necesario con disponibilidad

24x7. Los reportes de averías, daños o mal funcionamiento, categoriza-

dos como críticos o de emergencia deberán ser atendidos en un plazo no

mayor a una (1) hora natural a partir de la hora en que ESPH haga el re-

porte.

7.2.5. En caso de presentarse fallas durante el periodo de cobertura de la garan-

tía el proveedor adjudicado deberá encargarse de la coordinación con el

fabricante para el reemplazo de las partes dañadas en un máximo de 2

días hábiles a partir del momento que se determina la necesidad del

cambio, sin embargo, el adjudicatario deberá estar en la disposición de

aportar un equipo o parte con características similares al dañado en caso

de ser necesario mientras se recibe el equipo o la parte de reemplazo.

7.3. Licenciamiento

7.3.1. El oferente debe incluir en su oferta todo el software necesario para el

correcto funcionamiento de la solución como se requiere en las especifi-

caciones técnicas de este cartel.

7.3.2. Todas las licencias necesarias para cubrir el requerimiento de este cartel

deben tener una vigencia mínima de 3 años, de manera que ESPH no

tendrá que incurrir en el costo de renovación de ningún tipo durante los

próximos 3 años a la adjudicación. Este rubro podrá renovarse a un año

más.

7.4. Entrenamiento

7.4.1. El proveedor adjudicado debe comprometerse a dar capacitación para al

menos 3 (TRES) funcionarios la UEN TIC asignados por ESPH en la

reunión de pre-implementación, de tal manera que estén plenamente pre-

parados para instalar, configurar y dar mantenimiento local a los equipos

ofertados.

7.4.2. El entrenamiento debe ser certificado por el fabricante de la solución, de

manera que el certificado de participación debe ser emitido por éste.

Asimismo, debe brindarse el material didáctico correspondiente para ca-

ESPHF-AD-010(5)


da participante emitido por el fabricante, el mismo se deberá aportar en

idioma español o inglés.

7.4.3. La capacitación debe contemplar al menos 24 horas efectivas, dividida

en tres sesiones presenciales (no virtuales). Incluyendo la realización de

laboratorios y ambientes de pruebas, así como aprender y practicar cam-

bios de políticas, configuraciones y troubleshooting.

7.4.4. La capacitación se puede impartir de manera remota o presencial en un

centro de entrenamiento autorizado por el fabricante. La misma se debe-

rá impartir en idioma español o inglés. La fecha será coordinada en la

reunión de pre-implementación.

7.4.5. La capacitación debe ser brindada por personal del fabricante de la solu-

ción que esté certificado como instructor para capacitar personal en el

uso de la solución, de tal manera que los funcionarios participantes esta-

rían capacitados para certificarse como administradores de la solución

después de su participación.

7.4.6. La empresa oferente debe tomar en cuenta en su oferta el costo del exa-

men de certificación para los tres funcionarios, de manera que al termi-

nar se entregará a cada estudiante un Boucher para la aplicación del

examen si es necesario.

7.4.7. Esta capacitación deberá completar temas relacionados con la operación,

administración, atención de averías y mantenimiento de los equipos ofer-

tados. Dentro de la oferta se deberán incluir los temarios correspondien-

tes.

7.4.8. Se debe emitir un título a los participantes que indique el nombre de la

persona que recibió el curso, la cantidad de horas del curso e indicar si es

de aprovechamiento (si hay evaluación) o de participación (no hay eva-

luación).

ESPHF-AD-010(5)


LINEA 3. MANTENIMIENTO CORRECTIVO Y PREVENTIVO DE LA SOLU-

CIÓN

El oferente deberá incluir en la oferta indicando el costo mensual, un contrato de sopor-

te local preventivo y correctivo por la vigencia de 3 años que podría prorrogarse por 1

año más a convenir por las partes, se deberá incluir el monto mensual correspondiente a

este soporte para el año prorrogable. Dicho monto se podrá contratar automáticamente

en los periodos siguientes en las mismas o diferentes condiciones según el acuerdo en-

tre las partes, dicho contrato deberá asegurar al menos los siguientes rubros:

Instalación de Parches y Hotfixes

Actualización a Nuevas Versiones

Soporte por correo electrónico o Telefónico, ilimitado

Soporte Remoto, ilimitado

Al menos 5 soportes en Sitio al mes

Horario de Atención 24x7 de Lunes a Domingo

Soporte preventivo de la solución

Atención en caso de fallo de 1 hora después de reportado el incidente.

En las ofertas se debe resaltar el costo mensual del contrato de soporte con la vigencia de

tres años y además se debe indicar el costo del contrato por otro año posterior al primer

contrato.

Requerimientos para la atención de incidentes y/o solicitudes

Debe facilitar una herramienta oficial para el registro y reporte de los incidentes

y solicitudes que puedan presentarse. ESPH reportará por medio de dicha he-

rramienta, cualquier evento que sea detectado y que forme parte del alcance de

esta contratación. El caso incluido debe ser enviado automáticamente a las per-

sonas encargados para que se inicie el proceso de atención y solución del mismo

según los tiempos establecidos.

Debe facilitarse acceso a la herramienta del personal que ESPH designe para

que puedan abrir casos de reportes de incidentes, así como para consultar el

avance de alguno incluido, sacar estadísticas de atención, entre otros.

La atención de los incidentes reportados debe ser realizada 24x7x365

La información oficial del tiempo de atención y solución de los incidentes o

problemas reportados será generada de dicha herramienta y será el insumo ofi-

cial para determinar cualquier incumplimiento contractual. Por esta razón, en

todo momento debe mantener una bitácora de lo sucedido en cada caso.

Deberá indicar los números de teléfono, correo electrónico y dirección Web para

que la ESPH pueda contactar a los encargados de resolver los incidentes repor-

tados.

ESPHF-AD-010(5)


En el informe que se debe entregar mensualmente se debe incorporar la infor-

mación de los incidentes, problemas y/o solicitudes suscitados durante el mes.

LINEA 4. GESTIÓN DE LA PLATAFORMA DE LA SOLUCIÓN

1. El contratista deberá gestionar la plataforma durante el plazo de la contratación.

2. Durante el plazo el contratista debe administrar la plataforma para garantizar

tiempos continuos de servicio 24x7x365 y disponer de un nivel de operación de

99,98%

3. Se debe cumplir con los niveles de servicio señalados en el presente documento

4. Se deben atender y resolver niveles de incidentes, realizar monitoreo proactivo y

preventivo 24x7x365, para lo cual debe contar con herramientas tecnológicas

que permitan llevar a cabo el monitoreo de la infraestructura.

5. Presentar reportes y gráficas necesarias para detallar el comportamiento de la

infraestructura tecnológica.

6. Niveles de disponibilidad del servicio:

La atención y solución de estos niveles de disponibilidad deben estar

bajo la modalidad de trabajo 24x7x365

Nivel de disponibilidad 1: En este nivel la solución debe estar disponible

mínimo 99,98% del tiempo

Nivel de disponibilidad 2: En este nivel la solución debe estar disponible

mínimo un 98,8% del tiempo

Niveles de Servicio:

ESPHF-AD-010(5)


TIPO DE NIVEL DE

SERVICIO

DESCRIPCIÓN DEL TIPO

DE ATENCIÓN

TIEMPO MÁ-

XIMO DE

ATENCIÓN

TIEMPO MÁXIMO

DE RESOLUCIÓN

Averías Críticas

Corresponden a incidentes o

problemas que interrumpen el

servicio tales como:

- El servicio no está disponi-

ble

-No cumple con el nivel 1

solicitado

- Los tiempos de respuesta

en el envío de los mensajes

no es el solicitado

15 minutos natura-

les después del

reporte de la avería

50 minutos naturales

después de reportada

la avería

Averías No Críticas

Corresponden a incidentes o

problemas que no interrum-

pen el servicio, tales como:

- El servicio está disponible y

la falla presentada no afecta

el servicio.

- No cumple con el nivel de

disponibilidad 2 solicitado.

1 hora natural

después de repor-

tada la avería

1 hora 50 minutos

naturales después de

reportada la avería

Trabajos de imple-

mentación de mejoras

correctivas o preventi-

vas

Corresponde a actividades

programadas o no programa-

das a fin de realizar la im-

plementación de mejoras,

mantenimientos correctivos

y/o preventivos sobre el ser-

vicio.

8 horas hábiles

después de solici-

tado el mismo

Según lo

establecido en el plan

de trabajo respectivo

Si el proveedor manifiesta que requiere de un mayor tiempo de respuesta, debe brindar la

justificación formal correspondiente, la cual será valorada por el responsable contractual, quién

determina si es válida

V. Plazo de la Contratación

El plazo del contrato es por 36 meses prorrogables a 12 meses más a partir de la

instalación y puesta en marcha de la solución y el oferente debe elaborar un

cronograma de ejecución. ESPH está en su derecho de modificar el cronograma si lo

considera pertinente.

VI. Garantía

El oferente debe entregar una garantía que legitime que los bienes sean nuevos, de

última tecnología, de calidad sobre: diseños, materiales empleados, operación,

capacidades y eficiencias asignadas al fabricante.

1. Garantía de participación

Los oferentes que deseen presentar oferta deberán presentar una garantía de par-

ticipación del 5% sobre el monto ofertado, la cual será devuelta una vez que se

realice el análisis de las ofertas y se realice la respectiva adjudicación.

ESPHF-AD-010(5)


2. Garantía de cumplimiento:

El oferente adjudicado, previo a la emisión de la orden de compra, deberá apor-

tar una garantía de cumplimiento equivalente a un 5% del monto total adjudica-

do, la cual será devuelta 30 días hábiles después de que se realice el recibido a

satisfacción por parte de la ESPH.

3. Garantía de buen funcionamiento:

El oferente adjudicado, con la aceptación del servicio, deberá aportar una garan-

tía de funcionamiento equivalente a un 5 % del monto total adjudicado, la cual

será devuelta al término del servicio de soporte y mantenimiento.

VII. Condiciones de Almacenamiento

Todos los componentes deben entregarse en el lugar que ESPH indique para la im-

plementación.

El oferente debe indicar las condiciones en cómo debe almacenarse el producto.

VIII. Multas

Cuando exista atraso en la entrega total o parcial del bien y/o servicio adjudicado,

conforme a las condiciones contratadas el adjudicatario deberá pagar a la ESPH,

S.A. por concepto de multa el equivalente a un 2% sobre el valor total adjudicado,

por cada día hábil que se mantenga dicha condición, hasta un máximo de 25% del

monto total adjudicado, todo de conformidad a las Condiciones Generales.

Con respecto al servicio de soporte y mantenimiento se indican los tiempos de res-

puesta requeridos, así como las multas respectivas según cada servicio.

ESPHF-AD-010(5)


*Se excluye de este periodo el tiempo requerido por el contratista para la sustitución de

partes y/o equipos.

En caso de que el incidente se origine por un problema en el software atribuible al fabri-

cante, el contratista informara el tiempo de resolución de acuerdo a la documentación téc-

nica a proveer por parte del fabricante y el tiempo de resolución del incidente se extenderá,

a criterio de la ESPH.

IX. Firma de contrato

El adjudicatario debe firmar un contrato con la ESPH S.A. para lo cual tendrá un

plazo de 5 días hábiles posterior a la recepción de la adjudicación para firmar dicho

contrato, aportando las especies fiscales correspondientes, según el monto de

contratación de los servicios de instalación y soporte.

Matriz de SLA para el servicio de soporte y mantenimiento

Descripción del Servicio

Tiempo SLA (en tiempo natu-

ral)

Tiempo Pena-lidad (en tiempo

natural)

Multa

Primer Contac-to Soporte por incidente

30 Minutos > 30 Minutos Por cada 5 minutos de retraso, un 2% del total del monto total adjudicado del rubro de soporte y mantenimiento hasta un 25%.

Tiempo de Re-solución Ave-rías*

1 Hora > 1 Hora Por cada media hora de retraso, un 5 % del total del monto total adjudicado del rubro de soporte y mantenimiento hasta un 25%.

Remplazo de partes en Sitio

2 Días > 2 Días Por cada día de retraso, 10 % del total del monto total adjudicado del rubro de soporte y mante-nimiento hasta un 25%.

ESPHF-AD-010(5)


X. Modalidad de Pago

El pago de los equipos y la instalación se realizará 60 días después de que la

instalación y puesta en marcha de la Infraestructura tecnológica con la aprobación

de la unidad administrativa y con la previa presentación de la factura. La instalación

de la infraestructura se realizará en el centro de datos que defina ESPH.

Los servicios de soporte, mantenimiento preventivo y correctivo, se pagarán

mensualmente, luego de la presentación de un informe mensual en el que se indique

las condiciones de prestación del servicio, la ESPH deberá dar el visto bueno a este

informe para proceder al pago correspondiente, así como los tiempos de

interrupción de los servicios y procedimientos de resolución del contratista.

XI. Cesión del Contrato

El contratista no podrá ceder ni parcial ni totalmente el contrato salvo autorización

expresa y por escrito de ESPH, S.A.

XII. Responsabilidad Social del Contratista

El contratista deberá apegarse a lo estipulado en la legislación vigente, y no podrán

emitir mecanismos de discriminación en sus contrataciones por género, credo o

raza. Así como los requerimientos de las autoridades competentes:

Estar al día en materia de pago de impuestos

Estar al día en materia de pago de obligaciones obrero-patronales con CCSS

Estar al día en materia de pago del Fondo de Desarrollo Social y Asignaciones

Familiares (FODESAF)

El contratista estará obligado a conocer y cumplir lo establecido en el documento

Reglas de Calidad, Saludo y Seguridad y Ambiente para Contratistas de la ESPH

S.A. (el documento se encuentra en la página de la empresa: www.esph-sa.com en

la pestaña proveedores) y también debe someterse a las inspecciones periódicas que

la ESPH S.A. realice para verificar el cumplimiento del mismo.

Las consecuencias de orden laboral y de accidentes de trabajo, serán de entera

responsabilidad del contratista, al igual que las derivadas de daños a las personas o

bienes a terceros, en consecuencia, el contratista, para todos los efectos, será

reputado como patrón único y expresamente deja exonerada a la Empresa de

cualquier responsabilidad de orden civil y laboral, con motivo en razón o

consecuencia de los servicios contratados. En caso de producirse una situación de

emergencia o accidente laboral se debe notificar al administrador del contrato por

parte de la Unidad Interesada (responsable de la contratación) para que este informe

al departamento de Salud Ocupacional de la ESPH S.A.

http://www.esph-sa.com/

ESPHF-AD-010(5)


XIII. Tabla de Valoración para Calificación y Adjudicación

Para efectos de valoración de las ofertas, se evaluarán únicamente las ofertas que

cumplan con todos los requisitos de admisibilidad del punto III.

A las ofertas que cumplan con los requisitos de admisibilidad serán evaluadas de

acuerdo a los criterios de la siguiente tabla de puntaje, resultando adjudicado el

oferente que obtenga mayor calificación:

CRITERIO VALOR

%

Precio:

Se otorgará un 80% de la calificación a la oferta que presente el menor

precio.

Las otras ofertas recibirán una calificación proporcional aplicando la si-

guiente fórmula:

P= 80*(Pb/Po)

Dónde:

P= Puntaje obtenido por la oferta en estudio

Pb= Precio de la oferta de menor precio

Po= Precio de la oferta en estudio

80%

Experiencia del proveedor:

Se otorgará hasta un 20% de la calificación a los oferentes que demues-

tren tener más experiencia de la requerida como admisibilidad, y para ello

se utilizará la siguiente tabla;

4 proyectos implementados 10 %

5 o más proyectos implementados 20 %

Para demostrar esta experiencia el oferente deberá incluir cartas de los

clientes cumpliendo con todos los aspectos solicitados en el punto 3 (tres)

de los requisitos de admisibilidad, estas cartas debes ser de clientes dife-

rentes a los aportados en punto antes mencionado.

20%

Total, Puntos a obtener 100%

ESPHF-AD-010(5)


Las ofertas admitidas se compararán y adjudicarán de acuerdo al sistema de puntajes, sien-

do la(s) oferta(s) seleccionada(s) para su adjudicación la que logre el mayor puntaje y cum-

pla con lo requerido por la Unidades Interesada y que a la vez favorezca los intereses de la

ESPH, S.A.

Nota: Esta contratación será adjudicada a un solo proveedor, dada la integración necesaria

de los requisitos del cartel

XIV. Consideraciones en Salud - Seguridad Ocupacional y Ambiente

En cuanto a seguridad y salud ocupacional, el oferente debe apegarse a lo establecido en El

Procedimiento ESPHP-SGI-013 Relación con Proveedores y Contratistas.

ESPH dispondrá de un administrador del contrato quien validará el cumplimiento de las

normas establecidas para los Proveedores.

Especificar que antes de iniciar la prestación del servicio, el contratista deberá recibir la

Inducción del SGI y portar siempre el carnet de contratista; esto durante el periodo que

presta el servicio.

El proveedor debe indicar los procedimientos a llevar a cabo para el manejo de residuos

producto del servicio y según se establece en la Ley de Gestión Integral de Residuos Nº

8839 y su Reglamento

El oferente adjudicado deberá reducir la cantidad de embalaje que contiene el bien o pro-

ducto e eliminar el uso de estereofón, sustituyéndolo por material reciclable. Los oferentes

tendrán la obligación de presentar un Plan de Gestión de Residuos según lo establece el

artículo 42 de la Ley de Gestión Integral de Residuos No. 8839 y retirar los residuos que

se generen producto del bien adquirido.

Para todo producto químico deberán suministrar junto con la oferta las hojas de seguridad

correspondientes. Además, indicar cuando aplique el ingreso de productos peligrosos (mer-

curio, asbesto, plomo, PCB).

Aquellas empresas contratadas con más de 10 trabajadores deben contar con su propia Co-

misión de Salud Ocupacional, así mismo si la empresa cuenta con más de 50 colaboradores,

adicionalmente deben contar con una Oficina o Departamento de Salud Ocupacional.

XV. CLÁUSULA ARBITRAL.

Las controversias, diferencias, disputas o reclamos que pudieran derivarse con el

Adjudicatario en la ejecución de la Contratación, o el negocio y la materia a la que

este se refiere concernientes a controversias de orden patrimonial que sean fundadas

en derechos respecto de los cuales las partes tengan plena disposición y sea posible

excluir la jurisdicción de tribunales comunes al tenor del artículo 18 de la Ley

No.7727 “Ley sobre Resolución Alterna de conflictos y Promoción de la Paz Social”

serán sometidas a Arbitraje. El arbitraje será de derecho. El arbitraje será

ESPHF-AD-010(5)


administrado por el Centro de Conciliación y Arbitraje de la Cámara de Comercio de

Costa Rica (CCACC), a cuyos reglamentos las partes se someten. EI lugar del

arbitraje será el CCACC. EI conflicto se dilucidará de acuerdo con la ley sustantiva

de Costa Rica. EI arbitraje será resuelto por un Tribunal Arbitral compuesto por tres

árbitros. Los árbitros serán designados uno por cada parte y el tercero lo designarán

los dos nombrados por las partes, en caso de negativa de una de las partes o la falta de

acuerdo para el nombramiento del presidente, la designación la realizará el (CCACC).

EI laudo arbitral se dictará por escrito, será definitivo, vinculante para las partes e

inapelable, el recurso de nulidad, que deberá presentarse dentro del décimo día

natural de notificado el laudo o la adición o aclaración si la hubiere; mientras que el

recurso de revisión deberá presentarse dentro de los tres meses de notificado el laudo

o la adición o aclaración si la hubiere. Una vez que el laudo se haya dictado y

adquirido firmeza, producirá los efectos de cosa juzgada material y las partes deberán

cumplirlo sin demora. Los procesos y su contenido serán absolutamente

confidenciales. Los gastos relacionados con el proceso de arbitraje, incluyendo los

honorarios de los árbitros, los asumirá la parte perdedora total o parcial del arbitraje.

Cada una de las partes cubrirá los honorarios de sus abogados y asesores. Todo esto

sin perjuicio de la obligación de rembolso de cualquier gasto que le corresponda a la

parte perdedora a favor de la parte ganadora. Para estos efectos, el laudo deberá

condenar a la parte perdedora al de esos gastos, incluidos los honorarios profesionales

de los asesores legales. Las partes expresamente reconocen que son admisibles

medidas cautelares, bien por parte del Tribunal Arbitral o que se soliciten a un juez

ordinario en cuyo caso, que alguna de dichas autoridades acceda a una medida

cautelar, deberá rendirse una caución, en la forma y porcentaje establecido en el

artículo 273 del Código Procesal Civil, garantía calculada sobre la estimación

económica de proceso arbitral. A esa garantía o caución se la aplicarán las

consecuencias previstas en el artículo 276 de dicha ley. En caso de que el Centro de

Conciliación y Arbitraje de la Cámara de Comercio de Costa Rica (CCACC), dejare

de existir, lo será como segunda opción el Centro de Justicia Alternativa del Colegio

de Abogados de Costa Rica a cuyas normas y Reglamentos las partes desde ya se

someten en forma voluntaria e incondicional afectos de que éste administre el proceso

arbitral bajo ese supuesto.

ESPHF-AD-010(5) Nombre de la compra: Plataforma … · Debe soportar sumarización de rutas (route...

Documents

Transcript of ESPHF-AD-010(5) Nombre de la compra: Plataforma … · Debe soportar sumarización de rutas (route...