esphf-ad-010(5) nombre de la compra: plataforma … · debe soportar sumarización de rutas (route...
TRANSCRIPT
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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. Requerimientos Generales
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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. Requerimientos Generales
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
*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)
Cartel para Contratación de Servicios
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.
ESPHF-AD-010(5)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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)
Cartel para Contratación de Servicios
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.