SUMINISTRO Y PUESTA EN MARCHA DE UNA SOLUCIÓN PROXY Y NAVEGACIÓN WEB EN OSAKIDETZA. Pliego de Bases Técnicas

Transcripción

1 SUMINISTRO Y PUESTA EN MARCHA DE UNA SOLUCIÓN PROXY Y NAVEGACIÓN WEB EN OSAKIDETZA Pliego de Bases Técnicas 1

2 INDICE 1. Introducción Objeto del contrato Características generales de solución requerida Arquitectura de la nueva solución Requisitos Técnicos Requerimientos técnicos de diseño Características técnicas de la solución Requisitos Generales Gestión de proyecto Planificación, dirección y seguimiento de los trabajos Formato y contenido de la propuesta Oferta Técnica Oferta Económica Consultas al pliego Plazos y lugar de entrega, instalación y configuración Garantía Presupuesto económico y forma de pago Presupuesto económico Forma de Pago Duración del Expediente Confidencialidad PROPIEDAD DE LOS PRODUCTOS ENTREGADOS ANEXO I. Valoración de propuestas ANEXO II. Tabla de requisitos técnicos

3 1. INTRODUCCIÓN Internet es hoy en día el canal de comunicación más utilizado por cualquier empresa u organización. Cada vez más habitual compartir la información a través del canal web, mediante la utilización de foros, blogs, redes sociales, etc. y la tecnología ha permitido que Internet se haya convertido en un sitio de colaboración que permite a las empresas y sus trabajadores compartir sus conocimientos y aprender de un modo cada vez más eficaz. El empleado actualmente vive en un mundo colaborativo, dinámico, y en el que el acceso a la información es cada vez más fluido y necesario. Sin embargo, este uso de Internet por parte de los usuarios requiere de sistemas de control más exigentes y adaptados a la realidad de las necesidades actuales, donde. la información debe estar a salvo y donde el uso de las nuevas herramientas permita hacer un uso coherente de Internet acorde a las necesidades laborales de los usuarios. De este modo, cualquier organización debe disponer como mínimo de la capacidad de controlar el uso de Internet, evitar la mala utilización del ancho de banda y establecer mecanismos de protección frente a posibles problemas legales derivados del uso de la red corporativa. Por otro lado, las amenazas web constituyen uno de los grandes problemas de la seguridad informática hoy en día. La navegación, el acceso a los contenidos e información on-line y la disponibilidad de nuestros sistemas informáticos constituyen hoy en día un aspecto crítico para los actuales procesos de negocio. La información debe estar disponible en todo momento y los usuarios de la red deben estar completamente protegidos en la gestión de la información en la web. Las amenazas que residen en la web han evolucionado a un ritmo vertiginoso, y siguen haciéndolo cada día, diferenciándose cada vez más de las amenazas clásicas. Así, han ido apareciendo formas de ataque cada vez más sofisticados como botnets, ataques encubiertos en rootkits, phishing, ataques basados en aplicaciones IM/P2P, ataques a dispositivos móviles, y un largo etc. Los enfoques tradicionales de análisis de los contenidos en línea, basados en la utilización de tecnologías de antivirus combinados con IPS no aportan ya el grado de seguridad suficiente para combatir con efectividad este tipo de amenazas. Y además, aplicando los mecanismos tradicionales de detección y protección frente amenazas el impacto sobre el rendimiento de los sistemas es muy elevado, exigiendo un gran sobredimensionamiento del equipamiento dedicado a la protección de los sistemas. 3

4 2. OBJETO DEL CONTRATO El objeto del presente pliego es la evolución de la actual Plataforma de Seguridad web de forma que permita garantizar el uso apropiado de los recursos que ofrece la Web 2.0 y proteger a la organización de las nuevas amenazas actuales tanto internas como externas basadas en la Web siendo administrada de forma unificada y sencilla, y ofreciendo una completa visibilidad a Osakidetza de la protección y control aportado. Incluirá: Suministro de la plataforma Hardware y Software (licencias). Implantación de la solución. Servicios de mantenimiento y soporte de toda la solución implantada. 3. CARACTERÍSTICAS GENERALES DE SOLUCIÓN REQUERIDA Se solicita una plataforma hardware y software que conforme una solución integral de seguridad proxy y sistemas de navegación que deberán contemplar sin excepción los siguientes requisitos: Control del acceso de los usuarios a Internet. Autenticación, Autorización y sistema de logging e informes. Optimización y aceleración de aplicaciones y contenido Deberá integrar funcionalidades avanzadas de proxy con servicios de seguridad tales como: - filtrado de contenido - control granular de mensajería instantánea, políticas de uso y contenido - Prevención ante Spyware, malware, P2P, etc Gestión multiprotocolo incluyendo al menos: HTTP, HTTPS, FTP, CIFS, Streaming Media (MMS, RTSP, RTMP), TCP Tunnel, SOCKS Deberá poseer funcionalidades de aceleración y cifrado/descifrado de tráfico SSL. Deberá contar con herramientas propias de reporting e integración con software de terceros La solución debe ofrecer la posibilidad de publicar contenidos funcionando en modo Proxy Inverso 4

5 La solución debe soportar mecanismos de autenticación avanzada tales como: Integración con Directorio Activo (Kerberos, NTLM), LDAP, autenticación basada en certificados, usuarios invitados, autenticación secuencial, y otros. La solución debe ofrecer la posibilidad de extender estas políticas a usuarios que se encuentren fuera de la organización con dispositivos corporativos mediante la instalación de agentes software. Dicho agente debe ser gratuito. Las licencias suministradas pasarán a ser propiedad de Osakidetza, teniendo en todo caso un mantenimiento anual. No se aceptarán soluciones basadas en sistemas de subscripción que obliguen a la renovación completa de las licencias una vez expirado el plazo temporal del contrato Arquitectura de la nueva solución La arquitectura de la solución deberá proveer los siguientes beneficios: 1) Servicios Proxy: La solución debe soportar los siguientes servicios de Proxy, para atender a las peticiones realizadas por los usuarios: HTTP, HTTPS, FTP, DNS, SOCKS (v4/v5), RTSP, MMS, RTMP, IM (AIM, MSN, Yahoo Messenger), TCP- Tunnel 2) Arquitectura de Políticas Flexible: La solución deberá ser capaz de implementarse siguiendo las líneas generales y estándares de seguridad de la organización, proveyendo flexibilidad, control granular de protección de contenidos, control y aceleración basado en múltiples atributos tales como usuarios, grupos, sitio de usuarios, hora del día, tipo de contenido, tipo de archivo, tipo de URL, agentes, etc. 3) Gestión de Autorización: La solución deberá poder integrarse con varios sistemas de autenticación, tanto para la autenticación de usuarios, como la autorización de los mismos y grupos de usuarios. Requerimiento Indispensable es la autenticación con los siguientes métodos: Active Directory (NTLM y Kerberos), LDAP, Radius, tokens y certificados. La solución permitirá autenticación simultánea contra varios sistemas de directorio, incluso en el caso de que sean diferentes métodos (MS AD y Base de Datos Local, por ejemplo) y con varios métodos en secuencia, permitiendo así que usuarios que no estén en el dominio puedan autenticarse de otro modo. 4) Filtrado de Contenido: La solución debe incluir herramientas y soluciones de categorización del tráfico Web en base su reputación y clasificación dinámica en tiempo real, especificando el intervalo de actualización (preferible inferiores a 15 minutos). Esta clasificación en tiempo real se realizará mediante un sistema colaborativo en nube alimentado en tiempo real por los usuarios de las soluciones del fabricante. La solución debe ofrecer multicategorización, de modo que una misma URL pueda estar categorizada dentro de varias categorías (al menos hasta 4 categorías diferentes); así, un blog de medicina podrá estar categorizado 5

6 simultáneamente como Blog y como Salud. La solución debe permitir mostrar páginas de bloqueo personalizadas, con la posibilidad de que sean diferentes en función de la categoría, grupo de usuarios, hora del día/día de la semana, etc. 5) Control de Aplicaciones Web: La solución debe permitir el control de operaciones sobre aplicaciones Web de uso frecuente. Así se podrá permitir el acceso a dichas aplicaciones (sitios de correo personal, redes sociales, almacenamiento on-line, etc.) pero con la posibilidad de bloquear operaciones específicas tales como subida o descarga de ficheros, envío de correos, chat, etc. La solución debe controlar el mayor número posible de estas aplicaciones, considerándose un mínimo de 200 aplicaciones, y estas aplicaciones deben actualizarse de forma automática y transparente para el administrador. 6) SSL Proxy: La solución deberá ofrecer funcionalidad de proxy HTTPS. No solo es necesario que pueda interceptar el tráfico y enviarlo al destino, sino que sea capaz de validar el origen y destino de la conexión, validar el certificado del servidor e incluso que sea capaz de cifrar/descifrar el tráfico de forma transparente y segura, para ofrecer un mayor control del contenido. Esta intercepción podrá realizarse de forma selectiva, en función de parámetros tales como la categoría destino, usuario/grupo, aplicación, etc. 7) Escaneo de Virus, Spyware, Troyanos: La solución debe incorporar en su filtrado categorías referentes a sitios relacionados con la difusión de malware, spyware, virus, troyanos, botnets, etc. Este filtrado servirá como primer nivel de seguridad. Además, como segundo nivel de seguridad que podrá implantarse en un futuro, la solución debe poder integrarse con soluciones de Antivirus líderes del mercado sobre plataformas del mismo fabricante, integrable a través de protocolo ICAP o protocolo propietario, compatible con la funcionalidad de Caching, sin añadir retardos significativos en la entrega de contenido. Debe tener capacidad de excluir el escaneo de contenido basándose en URL, categoría, contenido, usuario, grupo de usuarios, etc. 8) Protección Contra Fuga de Información: La solución deberá contar con la posibilidad de integración con soluciones de protección de fuga de información mediante palabras claves, archivos adjuntos, y otros aplicables a protocolos como HTTP, HTTPS, Mensajería Instantánea, WebMail, etc. Dicha solución no es objeto del presente proyecto, y se valorará que la solución permita flexibilidad a la hora de emplear en un futuro la solución del mismo fabricante o de otros. 9) Protección de la Red: La solución deberá proteger el uso del ancho de banda de la red restringiendo, asignando prioridades y controlando el consumo de ancho de banda por grupos de usuarios, usuario, aplicaciones, hora del día. 10) Beneficios para el Usuario: La solución deberá proveer funcionalidades de Caching y de Compresión que reduzcan el tiempo de espera para contenidos permitidos. 6

7 11) Uso de la Web, Monitorización y Reporte: La solución deberá soportar diferentes métodos y formatos de fichero de registro de actividad de los usuarios, atendiendo al usuario, grupo, o servicio, además deberá disponer de métodos de consulta de actividad en tiempo real y diversos mecanismos de extracción con formatos personados, que provean reportes gráficos sobre accesos a la web con vistas por usuarios, por grupos, categoría de contenido, consumo de ancho de banda, uso de mensajería instantánea e integración con herramientas y software de terceros. 12) Sistema Operativo Robusto y Seguro: La solución deberá contar con un sistema operativo propietario y no multipropósito (no LINUX, Unix o Microsoft OS o derivados de éstos), que no contenga códigos de propósitos generales, y no reutilice códigos de otros sistemas operativos. Se valorará la certificación de seguridad del sistema operativo bajo estándares internacionales (valorable certificaciones FIPS y EAL), así como su estabilidad y longevidad en el mercado. 13) Definición de Reglas Flexible y Simple: La solución deberá ser capaz de definir reglas y políticas de forma simple a través de un interfaz web o a través de línea de comandos. Además se debe soportar la utilización de lenguaje de programación para la configuración de políticas en línea de comandos. 14) Salida con Diferentes IP s: la solución permitirá definir múltiples direcciones IP por cada interfaz, y utilizar estas IPs como IPs de salida para diferentes flujos de tráfico, mediante el uso de reglas de este modo que permita, por ejemplo, establecer la conexión con una IP externa para las conexiones enviadas a sitios de socios de negocio, utilizar otra IP de salida concreta para determinado grupo de usuarios con objeto de aplicar políticas de QoS después, etc. 15) Bloqueo de descarga de ficheros: La solución permitirá el control de la descarga de ficheros, siendo posible definir reglas que impidan la descarga de ficheros en función del usuario/grupo, la categoría del sitio, etc. Debe ser capaz de identificar el tipo de fichero a bloquear mediante la extensión, el MIME Type publicado por el servidor o identificando ejecutables mediante Apparent Data Type (deben soportarse los tres métodos). 16) Publicación de Servicios de Red Interna: La solución debe tener capacidad de funcionamiento como Proxy Inverso (de forma simultánea a su utilización como proxy directo) de modo que permita la conexión de los usuarios a diversos contenidos publicados en la red interna. Para ello empleará funcionalidades de Reverse Proxy con reenvío de peticiones a los servidores internos, balanceo entre múltiples servidores, reenvío de credenciales de usuarios y control sobre grupos de usuarios, path accedido, rescritura de URL, rescritura inversa, etc. 17) Tráfico Vídeo - Streaming media: La solución debe gestionar de forma nativa el tráfico de streaming media de los protocolos Windows Media, RealPlayer, QuickTime y Adobe Flash (MMS, RTSP y RTMP/RTMPT). Dentro de este tipo de 7

8 tráfico cabe señalar dos tratamientos claramente diferenciados y necesarios en la organización: - Streaming en Tiempo Real: sobre este tipo de tráfico se debe realizar un splitting del tráfico, de modo que permita compartir a todos los usuarios una única conexión entre el Proxy y el servidor origen del vídeo. De este modo, se reduce la carga sobre el servidor y se reduce el consumo de ancho de banda. - Vídeo bajo Demanda (VoD): la solución debe ser capaz de cachear este tipo de objetos de vídeo (incluidos objetos flash video) permitiendo que una vez que un usuario a accedido a este contenido, el resto de accesos son servidos directamente desde la caché. También sobre este tipo de tráfico, mientras se realiza el cacheo en el primer acceso, la plataforma realizará splitting en el mismo modo que se explicó en el apartado anterior para vídeo en tiempo real. 18) Cliente de Usuario remoto: la solución dispondrá de cliente software que permita extender las funcionalidades de filtrado a los puestos de usuario remotos, y además realizará labores de optimización de ancho de banda entre estos usuarios remotos y la comunicación con sede central. La instalación de dicho agente debe poder hacerse de forma desatendida, silenciosa, etc. El despliegue de dicho agente no debe suponer un coste adicional para el presente proyecto. 19) Proxy SOCKS, otras aplicaciones: Como método para proveer un servicio de proxy para aquellos aplicativos que no soportan la configuración de dicho servicio la solución debe permitir utilizar un servicio de proxy SOCKS que, mediante la utilización de un cliente SOCKS o bien mediante la configuración en modo transparente del proxy, capture el tráfico de estas aplicaciones y lo gestione creando de este modo lo que se podía llamar un proxy de aplicación. 20) Youtube: Se necesitan gestionar canales de youtube e incluso utilizar la categorización de youtube. 21) Usuarios comodín: conocer si un mismo usuario se está logeando desde diferentes IPs y automatizar una acción concreta para evitar el uso de usuarios comodín. 22) Caché avanzado: Podra realizar caché de servicios como Youtube, actualizaciones de Windows, etc. Cuando un elemento no es cacheable, debe identificarse el motivo y debe poder decidirse qué hacer al respecto, orientado sobre todo de cara a servicios en la nube. 23) Gestión: Se precisa una gestión sencilla de excepciones para todo tipo de casos (IPs, Usuarios, etc.) y no requiera un mantenimiento posterior que suponga horas de gestión. 24) Actualizaciones de producto de forma rápida y sencilla con procedimientos de downgrade rápidos y sencillos. 8

9 25) Capacidades avanzadas en apertura de Túneles VPN: La solución debe ser capaz de ofrecer la posibilidad de apertura de cifrado de tráfico cifrado SSL, con las siguientes características: o o o o o o Disponer de acceleración HW dentro de los appliance para tráfico cifrado. Apertura selectiva de tráfico SSL en base a IPs origen, usuarios, aplicaciones, etc. Detección automática del certificado de cliente para automatizar las acciones en estos casos (Acceso sin abrir, No acceso). Capacidad para validar certificado de servidor en proxy o trasladar decisión hasta el usuario final. Posibilidad de mostrar un aviso al usuario para que sepa que accede a una página segura (HTTPS) cuyo contenido va a ser interceptado. Deseable que el usuario tenga que aprobar el acceso a esa página en esas condiciones. Posibilidad de reenviar el tráfico abierto a un elemento externo tipo IDS/IPS, herramientas de análisis forense, etc. 26) Detección y bloqueo de descarga: Por motivos de seguridad (virus, etc.), por aplicaciones, por tipos de ficheros (identificados mediante análisis de la extensión, análisis del MIME TYPE publicado por el servidor y análisis del propio objeto para detección del True File Data Type, Apparent Data Type o Magic Byte. La solución debe también permitir la posibilidad de creación de reglas complejas que detecten intentos de File Type Spoofing mediante la detección de incoherencias entre el MIME TYPE publicado y el True File Type detectado), por usuarios, IPs, cabeceras, etc. 27) Integración con plataformas externas: Antivirus perimetrales, DLPs, etc. 28) Logs de Acceso: Opción de crear logs personalizados, generando múltiples logs simultáneamente. 4. REQUISITOS TÉCNICOS 4.1. Requerimientos técnicos de diseño Se solicita de forma expresa el cumplimiento de todos y cada uno de los siguientes requisitos: Los dispositivos ofertados en la solución proxy deberán poseer un sistema operativo propietario, no multipropósito, preferiblemente que no disponga de Sistema de Ficheros y orientado al procesamiento de objetos. 9

10 Solución basada en appliances HW; no se admitirán soluciones SW o virtual appliances. Capacidad para contemplar un mínimo de usuarios de internet que podrá ir creciendo en los próximos años. Capacidad de soportar hasta conexiones simultáneas y un mínimo de transacciones por segundo. Gestionar un caudal de hasta 500 Mbps, con posibilidad de crecimiento futuro de al menos un 100% Proponer un modelo de alta disponibilidad activo-activo, es decir, los elementos de la solución deben poder ser utilizados para el reparto de la carga entre ellos, pero en caso de caída de un equipo el resto deben asumir el total de tráfico especificado en los puntos anteriores Simplicidad de diseño: se valorará que el número de equipos a gestionar sea el mínimo posible en un entorno de alta disponibilidad, es decir, 2 equipos. Posibilidad de ser desplegada físicamente en línea (modo bridge), en modo transparente fuera de línea (WCCP o PBR), como proxy explicito, o con cualquier combinación de las anteriores. Permitir crecimiento sobre ella, es decir, ofrecer la posibilidad de ampliar el equipo mediante la inserción de memoria, disco y CPU para disponer de mayor capacidad en un futuro si fuera necesario. Dicha ampliación no está contemplada en el presente proyecto. El diseño de la solución deberá estar avalado por el fabricante mediante carta expresa de validación de la solución propuesta Características técnicas de la solución Se solicita de forma expresa el cumplimiento de todos y cada uno de los siguientes requisitos: a) Autenticación/Autorización: compatibilidad con al menos la autenticación de los usuarios en las siguientes tecnologías, permitiendo emplear varias de ellas simultáneamente: - LDAP (Lightweight Directory Access Protocol), Versión 2, Versión 3 y LDAP sobre SSL. - NTLM (Single Sign On) and Active Directory (Single Sign On) - Radius - X509 Certificate - Base de datos Interna 10

11 - Substitution REALM - Sequence REALM La solución deberá permitir autenticación transparente mediante cookies o IP. b) Permitir la definición de filtrado de contenido basado en los siguientes parámetros: - Usuario, Grupo de usuarios, IP, Subred, Protocolo, Puerto Destino, Alias de IM, Adjunto (True Type File), Palabras Claves, Dominios, URL, Expresiones Regulares, HTTP Method, Franja Horaria, User Agent, MIME Type. c) Filtrado de Contenido - Funcionar con una base de datos de categorías de URLs actualizable diariamente. - El filtrado web por categorías deberá permitir el análisis del contenido de URLs no categorizadas en tiempo real (en la nube). - La solución permitirá caching de las clasificaciones de URLs. - Las políticas de filtrado de contenido aceptarán: Mensajes de error definidos por el usuario Caching de Navegación Redirección de URL/Contenido MIME Types Speed-bump Operadores Lógicos del tipo: IF, AND, NOT, NOR - Permitirá el uso de múltiples páginas de bloqueo personalizables, pudiendo mostrar diferentes páginas en función de la categoría, usuario o grupo de usuario, hora del día, día de la semana, etc. d) Proveerá la capacidad de definir reglas/políticas que restrinjan el acceso de los usuarios por origen, destino, protocolo, aplicación, franjas horarias, y otros., que garanticen la flexibilidad en el control de accesos. e) Soportará la funcionalidad de Apparent Data Type, permitiendo el reconocimiento en los archivos del verdadero tipo de fichero, independientemente de la extensión. f) Ofrecerá soporte para FTP Explicito, permitiendo que las aplicaciones basadas en FTP se conecten en Modo Proxy a servidores FTP. g) No limitará bajo ningún concepto el funcionamiento del protocolo FTP, de modo que si el servidor destino requiere autenticación la solución de proxy debe ser capaz de gestionar dicha autenticación del usuario. 11

12 h) Podrá añadir un control al tráfico FTP, de modo que pueda aplicar controles adicionales como por ejemplo evitar el upload de ficheros por parte de los usuarios al servidor ftp, aun cuando el servidor lo permitiera. i) Soportará la función de Servidor SOCKS Proxy/Server, de forma nativa, para las versiones v4 y v5. Esta funcionalidad de SOCKS permitirá finalizar la sesión iniciada por el cliente y redirigir la conexión contra el servidor destino de la aplicación. j) Ofrecerá control sobre tráfico SSL, permitiendo identificar y aplicar políticas al tráfico que es transportado a través de túneles SSL. Y debe cumplir con las siguientes funcionalidades: - Funcionar como entidad certificante o como entidad subrogada a otra entidad certificadora - Realizar terminación de SSL. - Capacidad de escanear contenido cifrado. - Realizar caching selectivo de contenido cifrado. k) Administración de Ancho de Banda l) Caching - Aportará herramientas que posibiliten el control del ancho de banda utilizado. Esta herramienta deberá contar con controles basados en: Protocolo/Aplicación Origen/Destino Usuarios/Grupo de Usuarios Categoría de URL Franja Horaria - Será capaz de permitir la definición de un mínimo de ancho de banda garantizado, un máximo de ancho de banda, y establecer prioridades, controlando toda la sesión y no únicamente su establecimiento. - Permitirá el control del ancho de banda tanto del lado cliente como del lado servidor, y en sentido entrante y saliente. - Podrá ser configurada para determinar qué contenido será cacheado y cuál no. - Incorporará un mecanismo que permita cargar el contenido de una página y/o objetos en la Cache de la solución, previamente a que se realice la primera consulta a las mismas. - Será capaz de modificar los tiempos por defecto en los cuales los objetos son almacenados en la cache de la solución, independientemente de su valor original. 12

13 m) Análisis de Código Malicioso - Contará con un sistema de detección temprana de ataques maliciosos, sobre el protocolo HTTP y HTTPS. - Aportará un sistema de protección que incluya categorías específicas referidas a contenido malicioso que permitan bloquear el acceso de los usuarios a estos contenidos - Permitirá la integración con plataformas complementarias de seguridad tales como antivirus, sistemas DLP, analizadores fuera de línea, etc. La integración debe poder realizarse mediante protocolo ICAP, ICAP-S o protocolo propietario. n) Streaming Media - La solución debe identificar de forma clara los siguientes protocolos de vídeo: RTMP, MS Smooth Streaming, Apple HLS y Adobe HDS. Soportará los siguientes protocolos de streaming: Real Networks, Windows Media Player, QuickTime y Adobe Flash Player. Se valorará la capacidad de cachear este tipo de soluciones de streaming. - Incluirá los siguientes modos en tráfico streaming: Splitting, para contenido en vivo. Caching, para contenido bajo demanda. Precarga de Contenido Multicast o) Además debe soportar Windows Media y Real Time Player/Quick Time. Soportará los siguientes estándares - HTTP 1.0/1.1 (RFC2616) - SSLv2 / SSLv3 - TLSv1 - ICPv2 (RFC2186) - RTP (RFC1889) - RTSP (RFC2326) - WCCPv1 / WCCPv2 p) Brindará los siguientes modos operacionales: modo Proxy Explicito y modo Transparente. En modo Transparente la solución ofertada deberá soportar el método de enlace transparente o conexión en línea, así como también el redireccionamiento transparente mediante el protocolo WCCP. 13

14 - Para su despliegue en modo transparente en línea la solución contará con interfaces bridge fail-safe, de modo que la caída del equipo no suponga una pérdida de la comunicación. El equipo debe permitir su desactivación. q) Aportará herramientas que permitan realizar reportes de actividad. r) Incorporará herramientas que permitan realizar reportes personalizables por el usuario en base a: - Usuarios - Protocolos - Destinos - Tipo de Tráfico s) Incluirá herramientas que permitan realizar reportes específicos sobre detecciones de código malicioso, identificando posibles máquinas infectadas. t) Contará con un mecanismo de alertas para eventos relacionados con fallos en CPU, memoria, discos, temperatura crítica, etc. u) Proveerá la capacidad de notificar a los usuarios, administradores, cuando se reporte una alerta mediante la utilización de SNMPv3, SMTP, Syslog, etc. v) Será compatible con el protocolo SNMPv3, para la interacción con SNMPv3. Debiendo tener la compatibilidad con el RFC2594 MIB para la recuperación de estadísticas especificas proxy/cache. Igualmente deberá ser capaz de enviar mensaje de logs mediante syslog. Esta capacidad deberá ser configurable por el administrador sin requerir asistencia del fabricante. w) Los logs de la solución deben ser fácilmente accesibles en tiempo real, sin necesidad de equipamiento adicional. La solución deberá proveer la capacidad de analizar dichos logs en tiempo real sobre la propia plataforma. Estos logs deberán recoger toda la información relativa a la conexión, incluyendo usuario, URL, categoría, acción tomada, etc. y con la posibilidad de modificar los campos de dichos logs para incluir otra información de interés. Estos logs a su vez deberán poder ser enviados a una máquina externa o un servidor ftp para su archivado sin que sean manipulados. x) Suministrará un agente de puesto de usuario que extienda las funcionalidades expuestas a los usuarios remotos que se encuentren fuera de la red corporativa. - Dicho agente debe aplicar las políticas definidas por los administradores, identificando al usuario y siendo capaz de aplicarle su política concreta. - El filtrado debe tener capacidad de análisis en tiempo real también para los usuarios remotos - No se admitirán soluciones que obliguen a los usuarios remotos a pasar su tráfico a través de Datacenters externos o servicios en modo hosting. 14

15 - Se valorará positivamente que dicho agente ofrezca funcionalidades de aceleración de tráfico cuando el usuario se conecte con la red corporativa vía VPN, permitiendo aplicar técnicas de compresión y aceleración sobre tráfico pesado (correo, intercambio de ficheros, ftp, etc.) - La utilización de dicho agente de usuario remoto no debe implicar aumento de costes sobre el presente proyecto. 5. REQUISITOS GENERALES 5.1. Gestión de proyecto Osakidetza pondrá los medios personales que, junto con el coordinador del proyecto que se establezca, realizarán labores de seguimiento y control del proyecto. Los objetivos de dichas acciones son por un lado el aseguramiento de la calidad del proceso de gestión y la detección temprana de desviaciones, así como su conformidad con respecto a la metodología de trabajo establecida. Para ello el adjudicatario deberá en todo momento colaborar con los miembros de Osakidetza que realicen estas actividades, obligándose a informar y responder a los requerimientos de los mismos. Durante la ejecución de los trabajos objeto del contrato el adjudicatario se compromete, en todo momento, a facilitar a los responsables designados por Osakidetza la información y documentación que éstos soliciten para disponer de un pleno conocimiento de las circunstancias en que se desarrollan los trabajos, así como de los eventuales problemas que puedan plantearse y de las tecnologías, métodos y herramientas utilizados para resolverlos. Asimismo, el adjudicatario se compromete, en todo momento, a cumplir los procedimientos establecidos por Osakidetza. Como parte de las tareas objeto del contrato, el adjudicatario se compromete a generar la documentación de los trabajos realizados, de acuerdo con los criterios que establezca la Organización. Toda la documentación generada por el adjudicatario en ejecución del contrato será propiedad exclusiva de Osakidetza sin que el contratista pueda conservarla, ni obtener copia de la misma o facilitarla a terceros sin la expresa autorización por escrito de Osakidetza, que la concederá, en su caso, previa petición formal del contratista con expresión del fin Planificación, dirección y seguimiento de los trabajos Corresponde a Osakidetza la supervisión y planificación generales de los trabajos, proponer las modificaciones convenientes o, en su caso, proponer la suspensión de los mismos si existiese causa suficientemente motivada. 15

16 Es responsabilidad del adjudicatario la ejecución, la dirección y la coordinación directa de los medios personales que realicen las actuaciones. A tal efecto, el adjudicatario designará a un Jefe de Proyecto cuyas funciones en relación con el presente pliego serán: Dirigir a los medios personales que realicen las Actuaciones impartiendo al efecto las órdenes e instrucciones necesarias para la ejecución de las mismas. Realizar las funciones de contacto directo de los medios personales que realicen las Actuaciones. 6. FORMATO Y CONTENIDO DE LA PROPUESTA Con carácter general, la información presentada en la oferta técnica debe estar estructurada de forma clara y concisa. El adjudicatario proporcionará una copia en soporte impreso y otra copia en soporte informático con toda la documentación técnica (Memoria, Resumen ejecutivo y ANEXO II) de la propuesta presentada. Con independencia de que el licitador pueda adjuntar a la Oferta Técnica cuanta información complementaria considere de interés, ésta deberá estar obligatoriamente estructurada con el formato normalizado que se detalla en el apartado siguiente. Osakidetza se reserva el derecho a exigir a los licitadores que presenten documentación que acredite la veracidad de la información presentada en la oferta, o bien información adicional sobre el contenido de la misma, estando el licitador obligado a ello. Osakidetza podrá requerir a los licitadores que formulen por escrito las aclaraciones necesarias para la comprensión de algún aspecto de las ofertas. En ningún caso se admitirá que en proceso de aclaraciones el licitador varíe los términos expresados en su oferta. Sólo se admitirá la información que facilite el análisis de la solución propuesta inicialmente. La presentación de propuestas deberá cumplir las prescripciones del Pliego de Cláusulas Jurídicas Generales Oferta Técnica El licitador sólo podrá presentar su propuesta contemplando una única alternativa. En ningún caso se deberá incluir información económica en el Documento de Propuesta Técnica. El soporte físico de las propuestas deberá presentarse tanto en papel como en formato electrónico. Además de la oferta detallada, se entregará obligatoriamente un resumen ejecutivo de la propuesta encuadernado de forma separada, con una extensión máxima de 14 hojas y tamaño de letra Arial 11 incluyendo el resumen de todos los puntos del detalle de la oferta. 16

17 El incumplimiento de cualquiera de estos requisitos será motivo de exclusión. La propuesta que se presente por el licitador deberá aportar la información que se requiere en todos sus apartados y estar obligatoriamente estructurada de la siguiente forma: 1. INTRODUCCIÓN 2. SOLUCIÓN PROPUESTA Concreción de la solución planteada por el licitador detallando: a) Descripción detallada de todos los componentes de la solución propuesta, así como de las funcionalidades soportadas. Descripción del cumplimiento del apartado 2.1 Arquitectura de la nueva solución del presente pliego de bases técnicas, estructurado de la misma forma (punto por punto). Descripción del cumplimiento del apartado 3.2 Características técnicas de la solución del presente pliego de bases técnicas, estructurado de la misma forma (punto por punto). Cuanta información quiera aportar el licitante sobre la solución propuesta. b) Tabla de concordancia (según ANEXO II a cumplimentar) entre los requisitos mínimos exigidos en el presente Pliego de Bases Técnicas y los correspondientes a la solución propuesta por el licitador. 3. IMPLANTACIÓN Se describirán todas las tareas necesarias para una correcta migración desde la solución actual a la ofertada por el licitador, garantizando la integridad de los datos e indicando el período de tiempo requerido. Asimismo, se describirán las tareas de instalación, configuración y puesta a punto requeridas detallando las características de las mismas de forma que se indique el cumplimiento de los requisitos, SLA s y cualquier aspecto adicional propuesto que supere los mismos. 4. ORGANIZACIÓN Y GESTIÓN DEL PROYECTO Descripción de las tareas a realizar, una planificación detallada en formato diagrama de Gantt de las mismas, el inventario de componentes que componen la solución, el esquema de documentación propuesto así como el plan de pruebas Propuesto. 17

18 Se incluirá en este apartado la descripción de las medidas dispuestas por el oferente para asegurar la calidad de los trabajos; metodologías, medios materiales, aseguramiento de la calidad, seguridad y confidencialidad. 5. EQUIPO DE TRABAJO Se identificará y detallará la estructura organizativa del proyecto, interacciones entre el equipo de trabajo y jefatura técnica del proyecto, se indicarán los perfiles que forman parte del equipo de trabajo, las tareas que realizarán, el número de recursos de cada perfil y la dedicación prevista. Asimismo, en este bloque se describirá el grado de disponibilidad de personal técnico adicional que pudiera ser requerido para ampliar el equipo de trabajo. Se expondrá detalladamente el contenido y planificación de las Jornadas Profesionales incluidas en la propuesta Oferta Económica Cada licitador presentará una única oferta para todos los bienes y los servicios solicitados siguiendo el modelo de proposición económica establecido. Esta deberá ser única, sin alternativas ni variantes, y deberá diferenciar claramente los siguientes apartados: Suministros e implantación de la solución Soporte y Mantenimiento Todos los precios unitarios se deben proporcionar en Euros, calculados y presentados con DOS decimales y SIN IVA. La valoración económica deberá ir obligatoriamente en el sobre B: "Oferta económica y criterios evaluables de forma automática mediante la aplicación de fórmulas Consultas al pliego Durante el periodo de licitación y ante cualquier necesidad de aclaración sobre cuestiones referidas a las especificaciones recogidas en el presente Pliego de Bases Técnicas, los licitadores deberán remitir por correo electrónico las preguntas e información que consideren necesarias para elaborar la Propuesta Técnica. Los licitadores podrán dirigir sus consultas o aclaraciones a la dirección de correo electrónico de la Subdirección de Informática y Sistemas de Información: EXPEDIENTES.INFORMATICASSCC@osakidetza.net 18

19 Los licitadores deberán identificar, a un único responsable de la oferta, que será durante al periodo de licitación, el interlocutor único con Osakidetza para cualquier tipo de consulta o aclaración sobre los términos expuestos en el presente Pliego, no admitiéndose ninguna consulta o aclaración de persona distinta a la señalada. Así mismo los licitadores para formular sus consultas o aclaraciones deberán cumplimentar la siguiente información: Nº. Pregunta Capítulo/Apartado Página Párrafo Descripción de la Consulta 7. PLAZOS Y LUGAR DE ENTREGA, INSTALACIÓN Y CONFIGURACIÓN El plazo de presentación del análisis, diseño detallado, planificación y documentación propuesta, previos a la implantación (que deberá ser aprobado antes de comenzar la instalación) no podrá ser superior a 1 semana a contar desde la fecha de formalización del contrato. Plazo de entrega del material, instalación, configuración y puesta en marcha no podrá ser superior a las 3 semanas a contar desde la fecha de aceptación, por parte de Osakidetza, de la fase anteriormente descrita. En cualquier caso, el plazo total de entrega del proyecto no podrá ser superior a las 4 semanas. Incluirá 30 horas de formación presencial en Servicios Centrales de Osakidetza y oficial de fabricante, sobre el producto ofertado. Estará dirigido a los administradores del sistema, con lo que el temario deberá ser de complejidad técnica acorde a los asistentes. La formación podrá tener lugar dentro de los 4 primeros meses después de formalizar el contrato. El Lugar de entrega para cualquier suministro serán los Servicios Centrales de Osakidetza, o aquellos lugares que Osakidetza pueda establecer en cada momento próximos a su sede central (distancia máxima de 10 kilómetros). Todos los plazos y unidades de tiempo propuestos por el licitador se reflejarán en días hábiles. 19

20 8. GARANTÍA Se incluirá una garantía de fabricante de 3 años: Reposición de material en 8x5xNBD. Soporte software 24x7x365 Se acreditará con la documentación del fabricante durante todo el periodo de vigencia de la misma. 9. PRESUPUESTO ECONÓMICO Y FORMA DE PAGO 9.1. Presupuesto económico El presupuesto máximo de licitación del expediente es de sin IVA y de con IVA (21%). Dicho importe se distribuirá de la siguiente manera: Concepto Presupuesto sin IVA Presupuesto con IVA 21% Suministros e implantación de la solución Soporte y Mantenimiento TOTAL La valoración económica deberá ir obligatoriamente en el sobre B: "Oferta económica y criterios evaluables de forma automática mediante la aplicación de fórmulas Forma de Pago Los suministros (hardware y licencias) se abonarán tras el acta de recepción con el VºBº del responsable de Osakidetza. Los servicios de Soporte y Mantenimiento se abonarán de forma mensual tras el VºBº del responsable de Osakidetza. 20

21 9.3. Duración del Expediente El plazo de ejecución será de 3 años contados desde fecha de formalización del contrato, sin posibilidad de prórroga. Los servicios de mantenimiento comenzarán una vez realizada la recepción del suministro objeto del contrato. 10. CONFIDENCIALIDAD En consideración al tipo de información procesada, el adjudicatario está obligado a mantener la más absoluta confidencialidad sobre todos aquellos datos y documentos a que tenga acceso con motivo de la adjudicación. A ellos accederán exclusivamente las personas estrictamente imprescindibles para el desarrollo de las tareas inherentes a la misma. Todas ellas serán advertidas del carácter confidencial y reservado de la información a la que tendrán acceso. Todos los ficheros que se pongan a disposición del adjudicatario para la ejecución del contrato son propiedad de Osakidetza y están registrados y sometidos a la salvaguarda que establece la legislación vigente, en especial la relativa a la protección de datos personales. Toda cesión a terceros será perseguida en los tribunales. Osakidetza se reserva el derecho de establecer cualquier tipo de marcaje de los ficheros que se dejarán al adjudicatario, de manera que sus características puedan constituirse como prueba que posibilite localizar el origen y los responsables de las eventuales cesiones. Bajo ningún caso ni circunstancia el adjudicatario podrá suministrar a terceros ni utilizar para sí mismo ni para otros los datos facilitados por Osakidetza para fines distintos a los contemplados en el objeto del presente contrato. El adjudicatario estará obligado a poner en conocimiento de Osakidetza, inmediatamente después de ser detectada, cualquier sospecha de eventuales errores que se puedan producir en el sistema de seguridad de la información. El adjudicatario faculta a Osakidetza para que, al terminar el proyecto, pueda responsabilizarlo y/o repercutirle los costes derivados de posibles reclamaciones ocasionadas por negligencia y/o falta de confidencialidad del mismo. 11. PROPIEDAD DE LOS PRODUCTOS ENTREGADOS Todos los estudios y documentos, así como los productos y subproductos elaborados por el suministrador como consecuencia de la ejecución del contrato serán propiedad de Osakidetza, quien podrá reproducirlos, publicarlos y divulgarlos, total o parcialmente, sin que pueda oponerse a ello el suministrador autor material de los trabajos. 21

22 El suministrador renuncia expresamente a cualquier derecho que sobre los trabajos realizados como consecuencia de la ejecución del contrato pudieran corresponderle, y no podrá hacer ningún uso o divulgación de los estudios y documentos utilizados o elaborados en base a este pliego de condiciones, bien sea en forma total o parcial, directa o extractada, original o reproducida, sin autorización expresa de Osakidetza. Todos los productos que desarrolle el adjudicatario quedarán en propiedad exclusiva de Osakidetza, así como su propiedad intelectual, quedando el adjudicatario obligado a renunciar a cualquier derecho sobre estos conceptos. Esta condición afecta de la misma forma a los productos software incluidos en la propuesta, en cuanto a la propiedad de licencias de uso y explotación de los productos hardware en régimen de propiedad. 22

23 ANEXO I. VALORACIÓN DE PROPUESTAS Criterios de Juicio de Valor Para la los elección de criterios de valoración y su ponderación se han tenido en consideración los aspectos más significativos recogidos en el Pliego de Bases Técnicas que se acompaña a este expediente, a fin de garantizar que las ofertas de los licitadores se ajusten a lo exigido para los servicios objeto de este expediente. De acuerdo con lo antedicho, los criterios que servirán de base para la adjudicación del presente contrato serán los siguientes: Juicio de Valor Solución Técnica. Cumplimiento de requisitos. Descripción detallada de la solución ofertada. Funcionalidades técnicas requeridas (ANEXO II).. Solución Funcional. Propuesta de ejecución de proyecto. Propuesta de migración, instalación, configuración y puesta en producción, cronogramas de actuación y sincronización de tareas Puntos 40 puntos 10 puntos Umbral mínimo de la suma de los criterios de Juicio de Valor: 25 puntos (50%). Se valorarán con carácter previo los criterios de adjudicación en los que se haya establecido un umbral mínimo de puntuación. Las ofertas deberán superar ese umbral para continuar en el proceso selectivo y ser valoradas conforme al resto de los criterios de adjudicación. Fórmulas 50 Puntos Precio puntos La oferta cuyo importe sea igual al importe de licitación se valorará con 0 Puntos. La puntuación se calculará aplicando la siguiente fórmula: Precio Mínimo x 40 puntos Precio ofertado Plazo de entrega. 10 puntos Se concederá 1 punto por cada día hábil de adelanto respecto al plazo máximo exigido, hasta un máximo de 10 puntos. Cualquier oferta inferior a 10 días hábiles de plazo de entrega del proyecto se considerará inviable por las características del suministro objeto del contrato. 23

24 ANEXO II. TABLA DE REQUISITOS TÉCNICOS 24

25 Nombre del licitador Cumple (Sí/No) Págs. Arquitectura Los dispositivos ofertados en la solución proxy deberán poseer un sistema operativo propietario, no multipropósito, preferiblemente que no disponga de Sistema de Ficheros y orientado al procesamiento de objetos. Solución basada en appliances HW; no se admitirán soluciones SW o virtual appliances. Capacidad para contemplar un mínimo de usuarios de internet que podrá ir creciendo en los próximos años. Capacidad de soportar hasta conexiones simultáneas y un mínimo de transacciones por segundo. Gestionar un caudal de hasta 500 Mbps, con posibilidad de crecimiento futuro de al menos un 100% Proponer un modelo de alta disponibilidad activo-activo, es decir, los elementos de la solución deben poderserutilizados parael repartode lacargaentreellos, peroen casode caídade unequipo elresto deben asumir el total de tráfico especificado en los puntos anteriores Simplicidad de diseño: se valorará que el número de equipos agestionarseael mínimoposible enun entorno de alta disponibilidad, es decir, 2 equipos. Posibilidad de ser desplegada físicamente en línea (modo bridge), en modo transparente fuera de línea (WCCP o PBR), como proxy explicito, o con cualquier combinación de las anteriores. Permitir crecimiento sobre ella, es decir, ofrecer la posibilidad de ampliar el equipo mediante la inserción de memoria, disco y CPU para disponer de mayor capacidad en un futuro si fuera necesario. Dicha ampliación no está contemplada en el presente proyecto. El diseño de la solución deberá estar avalado por el fabricante mediante carta expresa de validación de la solución propuesta. Funcionalidad Control del acceso de los usuarios a Internet. Autenticación, Autorización y sistema de logging e informes. Optimización y aceleración de aplicaciones y contenido Deberá integrar funcionalidades avanzadas de proxy con servicios de seguridad tales como: filtrado de contenido - control granular de mensajería instantánea, políticas de uso y contenido - Prevención ante Spyware, malware, P2P, etc Gestión multiprotocolo incluyendo al menos: HTTP, HTTPS, FTP, CIFS, Streaming Media (MMS, RTSP, RTMP), TCP Tunnel, SOCKS Deberá poseer funcionalidades de aceleración y cifrado/descifrado de tráfico SSL. Deberá contar con herramientas propias de reporting e integración con software de terceros La solución debe ofrecer la posibilidad de publicar contenidos funcionando en modo Proxy Inverso La solución debe soportar mecanismos de auteticación avanzada tales como: Integración con Directorio Activo (Kerberos, NTLM), LDAP, autenticación basada en certificados, usuarios invitados, autenticación secuencial, y otros. La solución debe ofrecer la posibilidad de extender estas políticas a usuarios que se encuentren fuera de la organización con dispositivos corporativos mediante la instalación de agentes software. Dicho agente debe ser gratuito. El sistema de licenciamiento de la solución debe consistir en licencia y mantenimiento anual. No se aceptarán soluciones basadas en sistemas de subscripción que obliguen a la renovación completa de las licencias una vez expirado el plazo temporal del contrato. Funcionalidades adicionales Generación de informes de uso incluyendo: categorías más visitadas, usuarioas más activos, páginas más visitadas, categorías, páginas y usuarios con mayor ancho de banda. Control de aplicaciones WEB 2.0.: limitarno sólo el acceso aun sitio sino las operaciones quepueden realizarse sobre él. Agente de puesto de usuario gratuito que extienda las políticas de navegación a los usuarios fuera de la red. Capacidades de Optimización de tráfico incluyendo: Cache de bytes, compresión, gestión de ancho de banda y optimización de protocolos HTTP y CIFS Agente de puesto de usuario gratuito que permita aplicas estas técnicas de acelración cuando los usuairos se conecten vía VPN 25