ESPECIFICACION PARA EL SISTEMA DE DETECCIÓN Y PREVENCIÓN DE INTRUSOS - IPS

Transcripción

1 ESPECIFICACION PARA EL SISTEMA DE DETECCIÓN Y PREVENCIÓN DE INTRUSOS - IPS CANTIDAD: (01) 1. Generalidades del diseño 1.1 El dispositivo debe estar basado en software y hardware dedicados, es decir, que el Hardware y software (de base y aplicativo) deben ser desarrollados integralmente por el mismo suministrador. 1.2 La plataforma debe incluir un sistema de gestión y administración. 1.3 Montaje físico en rack Alimentación 220V. 1.5 La solución de IPS debe contemplar un servidor dedicado donde se instalará el software de gestión además se almacenaran los Logs para la obtención de reportes. 2. Especificaciones de Red 2.1 Debe operar en capa 2 del modelo OSI 2.2 Debe soportar monitoreo de VLAN, 802.1q (especificar cantidad) 2.3 Contar con 8 Puertos Ethernet 10/100/1000 Mbps para monitoreo 2.4 Contar con monitoreo de 4 segmentos físicos de red. 2.5 Proporcionar un throughput total mínimo de 300 Mbps. 2.6 Proporcionar un mínimo de 70,000 sesiones concurrentes 2.7 Proporcionar uno (1) puerto Ethernet 10/100/1000 Mbps dedicado para comunicación de administración. 2.8 Proporcionar uno (1) puerto Ethernet 10/100/1000 Mbps dedicado para implementación de alta disponibilidad. 2.9 El equipo debe poder ser configurado en diferentes modos: Bridge, Router, Transparente y Sniffer (Pasivo) El dispositivo deberá permitir el marcado de Diffserv de diferentes tipos de tráfico a los efectos de priorizar una aplicación sobre otra. Este marcado deberá ser configurado por política. 3. Especificaciones de alta disponibilidad 3.1 Posibilidad de alta disponibilidad activo-pasivo. 3.2 Posibilidad de alta disponibilidad activo-activo. 3.3 En alta disponibilidad el equipo backup debe mantener el sincronismo de sesiones con el equipo primario (state-sync). 3.4 En caso de falla eléctrica o de software (coredump) el dispositivo debe permitir la opción de by-pass físico de los segmentos monitoreados, de esta forma no interrumpirá el trafico. 3.5 Tendrá la función de activar la condición de By-Pass entre los puertos para permitir el paso de tráfico en caso que el administrador lo solicite. 3.6 La opción de acción de bypass configurable (activar / desactivar). 3.7 Fuentes de alimentación redundantes. 4. Especificaciones de detección 4.1 En esquema general de detección debe ser bi-direccional. El equipo debe poder analizar el tráfico en ambas direcciones (cliente hacia Servidor y Servidor hacia cliente). 4.2 Detección con utilización de firmas con patrones de tráfico basada en campos específicos del protocolo o aplicación utilizados. Esto se conoce normalmente como Statefull Signaturas, e implica que el patrón a detectar es buscado dentro de un contexto específico (aplicación, campo, protocolo, etc). 4.3 Las firmas deben contemplar el análisis de los siguientes TCP, IP, UDP, ICMP, ARP 4.4 Las firmas deben cubrir al menos 60 protocolos de aplicación incluyendo: Aplicativos: http, SMTP, FTP, RPC, POP3, TELNET, RSH, REXEC, RLOGIN, DNS, IMAP, FINGER, DHCP, TFTP, MIME, NNTP, BOOTP, CHARGEN, ECHO, DISCARD, RTSP, SNMP, SNMP trap v1, SYSLOG, SSH, SMB (NetBIOS),

2 MS-RPC, VNC, IDENT, Gopher, NNTP, RUSERS, IRC, Gnutella, NTP, WHOIS, LDAP, NBNAME, SSL, NBDS, RADIUS Mensajeria Instantanea: AOL-IM, Yahoo-IM, MSN-Messenger Aplicaciones P2P: BearShare, Gnucleus, Morpheus, Swapper, XoloX, Gnewtellium, Gnutella, Mutella, emule, edonkey, ernet, Qtella, LimeWire, Phex, Kazaa, Napster, WinMX Protocolos de Voz Video Sobre IP: H.323, H.225, MGCP, SIP 4.5 Con el objeto de lograr una cobertura eficiente la cantidad de firmas debe superar las 6, Las firmas deben ser abiertas, excepto que existan acuerdos de confidencialidad con fabricantes de aplicaciones específicos (detallar). Se entiende por firmas abiertas donde el administrador puede ver el patrón que la firma analiza, el contexto en donde aplica y eventualmente puede modificarlo con facilidad. 4.7 El sistema debe permitir la detección con utilización de firmas definidas por el usuario. 4.8 El sistema debe permitir la detección de anomalías de protocolos. Esto se conoce como Detección y verificación de compatibilidad con RFC para determinar variaciones en los protocolos y aplicaciones. 4.9 El sistema debe realizar la detección por análisis de comportamiento, aplicando un análisis heurístico sobre el tráfico para detectar variaciones al tráfico normal que puedan indicar la existencia de un dispositivo infectado con programas del tipo Backdoor El sistema debe analizar intentos de conexión sobre puertos TCP de servicios no existentes en los servidores reales. Esto es conocido normalmente como Network Honeypot Método de detección basado en el análisis de los flujos del tráfico para identificar los ataques sobre múltiples conexiones. Este método estará diseñado para detectar scaneos y otro tipo de ataques distribuidos (Traffic Anomaly). El método solicitado debe inspeccionar los patrones que indiquen una actividad del tráfico de red anormal como ports scans, ping swept etc Detección de protocolo por asignación de puerto Detección de protocolo en forma independiente del puerto utilizado Detección de protocolos en forma encapsulada Detección de protocolos a nivel capa 2 del modelo OSI. (Detallar) Detección de protocolos a nivel capa 7 del modelo OSI. (Detallar) Detección de anomalías de protocolos con reensamblados de paquetes fragmentados (TCP Reassembly) Detección de anomalías de protocolos con reensamblado de sesiones fragmentadas (Flow Reassembly) Detección de shell code en técnicas de ataque de Buffer Overflow El sistema debe posee reglas para proteger a la red de ataques de SYN-flood. El sensor debe detectar y prevenir SYN-Floods asegurando que el hand-shake de TCP se realice correctamente. En el caso que el cliente no envié el paquete de ACK (tal es el caso en un ataque de SYN-FLOOD), el sensor luego de un lapso de tiempo configurable, debe tomar la acción correctiva especificada por el administrador Protección contra Gusanos y Troyanos Protección contra Spyware, Adware y Keyloggers El Protección para sistemas de Voz sobre IP (VoIP). 5. Actualización de Firmas 5.1 El proceso de actualización de firmas debe poder realizarse en forma manual o automática. 5.2 El archivo conteniendo las nuevas firmas podrá descargarse a un servidor local y desde este a la consola de administración. 5.3 Al momento de actualizar una firma o política, las conexiones existentes no deben interrumpirse 5.4 El servicio de actualización de firmas debe ser diaria.

3 5.5 La actualización de firmas debe contemplar casos de emergencia con tiempo de respuesta tendiente a cero (0). 5.6 El suministrador debe enviar, via , reportes semanales de las firmas incorporadas al sistema. 5.7 Las firmas deben estar agrupadas en forma dinámica basado en parámetros como criticidad, protocolo, aplicación etc. Las nuevas firmas se deben unir al grupo correspondiente en forma automática. 6. Especificaciones para la configuración de políticas 6.1 La configuración de las políticas de inspección debe estar compuestas por objetos. Se entiende por objetos a una representación de los componentes de la red como routers, estaciones de trabajo, switches, servidores o cualquier otro dispositivo conectado a la red. 6.2 Los objetos deben almacenarse en un repositorio desde donde se podrán seleccionar y descargar (drag & drop) sobre la regla para luego especificar origen o destino del trafico a inspeccionar. 6.3 Debe existir además un repositorio para los objetos que representen los ataques, estos objetos deberán poder ser agrupados para facilitar la configuración de las políticas. Los nuevos ataques que se agreguen a la base de datos en forma automática y/o manual deben formar parte de estos grupos. 6.4 El sistema debe permitir la creación de reglas basadas en segmento monitoreado 6.5 El sistema debe permitir la creación de reglas basadas en dirección IP origen e IP destino 6.6 El sistema debe permitir la creación de reglas basadas en puerto de origen y/o puerto de destino 6.7 El sistema debe Permitir que las reglas de detección de ataques tomen la acción de capturar el tráfico relativo a la sesión donde se encuentra dicho ataque. Especificando la cantidad máxima de paquetes a capturar antes y después de detectada la firma correspondiente. 6.8 El sistema debe permitir la vista de los paquetes capturados que produjeron la alarma desde la interface de administración o asociando una aplicación externa (Ethereal, wireshark etc) 6.9 El sistema debe permitir la creación de reglas de filtrado de protocolos TCP, UDP, ICMP 6.10 El sistema debe permitir la creación de grupos de firmas estáticas y dinámicas con firmas provenientes de las actualizaciones del proveedor y firmas realizadas por los administradores El sistema debe permitir la creación de Reglas de excepción del tipo whitelist con listas de direcciones de IP confiables 7. Especificaciones sobre las acciones que toma el sensor 7.1 Soporte de funcionamiento en modo simulación IPS, es decir, que el equipo detecta los ataques pero no se fija ninguna acción sobre el tráfico. 7.2 Frente a una detección deberá soportar las siguientes respuestas: Close: Cortar la comunicación y enviar un Reset al servidor y al cliente Close: Cortar la comunicación y enviar un Reset al servidor Close: Cortar la comunicación y enviar un Reset al cliente Drop: Cortar la comunicación sin Reset Drop Packet: Descartar un paquete Ignore: Luego de detector una anomalía, se hace una entrada en el log y se ignora el resto None: Ninguna acción Mark: marcado de la prioridad del paquete para el descarte o encolamiento en caso de congestión en la red. 7.3 Cuarentena por un tiempo determinado basada en dirección del sistema víctima. 7.4 Cuarentena por un tiempo determinado basada en puerto del sistema víctima. 7.5 Cuarentena por un tiempo determinado basada en dirección del intruso. 7.6 Cuarentena por tiempo determinado basado en red origen del ataque

4 7.7 Cuarentena por un tiempo determinado basados en puerto del intruso 7.8 Cuarentena basada en las condiciones anteriores en forma simultánea, dirección origen / destino/ puerto destino. 8. Métodos de Análisis de tráfico 8.1 El sistema debe proveer una herramienta de análisis de tráfico no intrusivo (sin usar aplicaciones de scaneo de red) que permita elevar el conocimiento sobre el trafico de red para crea políticas de seguridad efectivas minimizando los falsos positivos y cantidad de logs. 8.2 Esta herramienta integrada al sensor debe aprender en forma automática sobre la composición de la red interna basado en el tráfico que circula por el dispositivo, de esta forma detectara hosts, puertos, programas RPC y toda la información de capa 7 que identifica en forma univoca a los usuarios, sistemas operativos, aplicaciones, comandos y nombres de archivos accedidos. 8.3 El sistema debe contar con una aplicación que tome la información de análisis durante un periodo de tiempo y a intervalos regulares y se almacene en un archivo para su posterior análisis interno o con herramientas de análisis de logs (Aplication Volume Tracking) 9. Métodos de Notificación Los métodos de notificación deben ser configurables por regla, cada regla tendra su propio sistema de notificación configurable. Deben soportarse al menos: 9.1 Notificación mediante envíos de SNMP trap. 9.2 Notificación mediante envíos de Notificación por envió de logs a Syslog Server, distinto de la consola de administración. 9.4 Posibilidad de respuestas al ataque de acciones definidas por el usuario donde cada regla puede invocar la ejecución de un script o programa asociado con las acciones indicadas por el administrador. 9.5 Se deberá proveer un mecanismo para colectar la información del sensor sobre el estado de las siguientes variables : Utilización de CPU Espacio de disco utilizado Numero de sesiones activas 9.6 Cuando una de las variables mencionadas en el punto anterior alcance el 90% se deberá generar un log hacia la consola de administración. ESPECIFICACIONES DE REQUISITOS PARA FIREWALL / VPN CANTIDAD:(02) DOS 1 GLOSARIO 1.1 Mbps: Mega bits por Segundo 1.2 DHCP: Dynamic Host Configuration Protocol. 1.3 FTP: File Transfer Protocol. 1.4 IEEE: Institute of Electrical and Electronics Engineers. 1.5 IETF: Internet Engineering Task Force. 1.6 IPSEC: Protocolo desarrollado por el IETF para implementar VPNs. 1.7 IRAM: Instituto de Racionalización Argentino de Materiales. 1.8 LAN: Red de Área Local. 1.9 RFC: Requests for Comments SNMP: Simple Network Management Protocol VPN: Virtual Private Network WAN: Red de alcance nacional DOS: Denial of Service

5 1.14 SNAT: Source Nat 1.15 DNAT: Destination Nat 1.16 PAT: Port Address Translation 1.17 IMIX : Tráfico Mixto de Internet compuesto por : 58.33% de los paquetes de 64 byte + d33.33% de los paquetes de 570 byte % de los paquetes de 1518 byte en UDP 1.18 TOS : Type of Service 1.19 QOS : Quality of Service (Calidad de Servicio) 2 Cláusulas Especiales 2.1 Todos los sistemas ofrecidos deberán cumplir con las especificaciones en materia de regulación de seguridad eléctrica, emisión de radiofrecuencia, emisión electromagnética y emisión de radiación, emitidas por los organismos competentes de los Estados Unidos, Canadá, la Comunidad Europea, Japón o equivalentes. 3 Requisitos de Red Cada firewall deberá soportar la configuración de al menos: 3.1 Tener integradas 12 interfaces Fast Ethernet físicas independientes 10/100/ Soportar crecimiento mínimo de 24 interfaces 10/100/ Tener como mínimo 3 slots libres para garantizar el crecimiento en interfaces de Red. 3.4 Soportar crecimiento mínimo de 6 interfaces SFP. 3.5 Todas las interfaces se podrán utilizar independientemente en modo L3 o L2, es decir se podrán agrupar para formar un dominio de Broadcast (L2) representadas por una interface L3 virtual o cada interface física o lógica podrá configurarse con una dirección IP independiente (L3). 3.6 La totalidad de las VLANS deberán poder ser configuradas en un único puerto físico destinado a conexiones internas. 3.7 Se debe garantizar un throughput de 1 Gbps para el tráfico de tipo IMIX (entre redes internas aplicando políticas de filtrado de paquetes con funciones de firewall-statefull) y superior a 1 Gbps con paquetes grandes (Cleartext o similar en la misma condición). 3.8 Se deberán garantizar 256,000 sesiones concurrentes. 3.9 El equipo debe soportar al menos 4,000 políticas de seguridad Cada firewall no deberá tener un límite de concurrencia de usuarios impuesto por el hardware ni por el software o licencias Soporte de múltiples zonas de seguridad. Se entiende zona de seguridad a la agrupación de una o más interfaces (físicas o lógicas) sobre las que se aplicaran políticas de seguridad. 4 Redes privadas virtuales (IPSec VPN) 4.1 Deberá soportar VPNs mediante IPSec soportando, como mínimo, 500 Mbps. de tráfico encriptado con 3DES de 168-bits, hash MD5 y SHA Permitir la generación VPN de tipo Site to Site y Client to Site. 4.3 Permitir 1000 VPN de cualquier tipo, activas simultáneamente, mediante IPSec. 4.4 Mecanismo de intercambio de llaves para VPN de tipo Diffie Hellman Grupo 1,2 y Mecanismos de autenticación de VPN mediante certificados digitales y clave pre compartida (pre-shared). 4.6 La solución deberá soportar la generación de VPNs desde todos los firewalls hacia uno o más concentradores terminador de VPN utilizando protocolo IPSEC estándar. 4.7 La solución deberá soportar la generación de políticas de enrutamiento basada tanto en VLAN origen como así también en IP origen de los paquetes. Permitiendo de esta manera encapsular sobre IPSEC todas las conexiones provenientes únicamente de una o mas VLAN/IP determinada desde las políticas definidas, a través de una VPN (Site to Site) establecida automáticamente por el propio firewall sin importar el destino de las conexiones de dicha VLAN/IP.

6 4.8 Enrutamiento dinámico de VPN: deberá soportar la configuración de protocolos de enrutamiento sobre los túneles IPSEC. 5 Funcionalidades adicionales 5.1 Debe soportar SNAT, DNAT y PAT. 5.2 Aplicación de SNAT y DNAT y PAT en forma simultánea sobre una misma conexión. 5.3 Deberá soportar NAT estático y dinámico. 5.4 Aplicación de PAT sobre cualquier tipo de conexión. 5.5 Deberá soportar la configuración de NAT estático sobre todas las interfaces físicas y lógicas utilizando direcciones IP virtuales que no sean las propias IP declaradas en las interfaces del firewall. 5.6 Soporte de IPSec NAT Traversal. 5.7 Soporte de protocolo H323 soportando Nat Traversal. 5.8 El equipo deberá poder configurarse en modo L3 o en modo L2 (también conocido como Modo Transparente) que permita integrarse a una topología existente sin cambiar el direccionamiento IP de los equipos instalados previamente. 5.9 Deberá proveer funcionalidad de Servidor y relay de DHCP en todas las interfaces físicas y lógicas Deberá permitir monitoreo remoto mediante SNMP v2 permitiendo los queries de SNMP a través de la definición de direcciones IP autorizadas para realizar las consultas Proveer de logeo remoto utilizando syslog Soporte de Alta disponibilidad en modo Activo-Pasivo Soporte de WINS Autenticación de usuarios en forma local, por RADIUS, LDAP, Firmas digitales Soporte de protocolo de enrutamiento RIP Soporte de protocolo de enrutamiento OSPF Soporte de protocolo de enrutamiento BGPv Soporte de Policy Based Routing basados en IP-Source/Puerto(TCP o UDP) IP- Destino/Puerto (TCP o UDP) y TOS La solución deberá permitir el uso de objetos dinámicos aplicables a todo tipo de regla, definiendo las propiedades de los mismos sobre cada firewall en particular. Los objetos deben poder referenciar servidores y redes como mínimo. Por ejemplo, permitir la definición de un único objeto (visto desde la administración central) llamado Servidor y que dicho objeto sea instanciado en cada firewall con un valor particular definido en el propio firewall de manera individual Las reglas deben permanecer en medio físico, no volátil Los componentes de la solución deberán poseer las configuraciones localmente, no dependiendo su funcionamiento de las consolas de administración, una falla en la consola no debe dejar fuera de servicio a los equipos remotos La configuración de equipos de la solución deberá almacenarse además de centralmente, localmente de manera redundante Deberá soportar la configuración de administradores locales (mínimo 20) Los administradores que accedan a los firewalls deberán autenticarse mediante Radius, LDAP o SECURID Las redes de los administradores serán controladas y se configurara el equipo para que solo equipos pertenecientes a dichas redes puedan acceder para configurarlo. Cantidad mínima de redes de administradores : El equipo permitirá la vuelta atrás (roll-back) a la ultima configuración estable aplicada, luego de realizada una modificación en la misma El mecanismo de control de filtrado utilizado por el engine del equipo deberá estar basado en técnicas statefull inspection que crean conexiones virtuales, incluso para los protocolos connection-less como UDP y RPC La solución deberá soportar la funcionalidad de Proxy de protocolo ARP sobre todas sus interfaces. Entendiéndose dicha funcionalidad como la capacidad de responder a

7 pedidos de ARP que no son dirigidos directamente hacia direcciones IP declaradas en sus propias interfaces Deberá poseer capacidad de manejo de apertura de puertos dinámicos en base a protocolos de uso común (FTP, H323, SIP, SCCP, MGCP) y posibilidad de crear sesiones personalizadas que manejen dicho comportamiento El lenguaje de programación utilizado para la definición de las reglas, debe estar documentado en su totalidad y las reglas deben poder ser modificadas por personal del Comprador utilizando este lenguaje La solución deberá soportar la configuración de parámetros referidos a timeout en la tabla de estados de conexiones sobre cualquier servicio TCP en forma individual y global La solución deberá soportar la activación y desactivación de técnicas de detección y evasión de ataques de DOS (Denegación de servicio) La solución deberá soportar la activación y desactivación de técnicas de protección de ataques de generación masiva de conexiones (SYN attack) permitiendo su configuración para una dirección IP en particular La solución deberá soportar la activación y desactivación de técnicas de anti-spoofing sobre cada zona de seguridad La solución deberá soportar técnicas de mitigación de spoofing en todas las interfaces Las reglas deberán poder definirse, diferenciando protocolo, IP destino / IP origen, puerto destino / puerto origen, zona de seguridad y horario. 6 Calidad de Servicio El equipo deberá permitir la configuración por políticas de Calidad de Servicio bajo todas a cada una de las siguientes: 6.1 Configuración por protocolo y por regla. 6.2 Configuración de Ancho de banda garantizado. 6.3 Configuración de Ancho de banda mínimo. 6.4 Priorización en la utilización de Ancho de banda. 6.5 DiffServ. 6.6 Aplicación de QOS a túneles IPSEC. 7 Funcionalidad de Antivirus (Licencia Activada) Los equipos deberán tener la funcionalidad de Antivirus integrada, mediante la activación de la licencia correspondiente, no se aceptarán soluciones en las que se tengan que añadir módulos o tarjetas adicionales para tener esta funcionalidad. 7.1 La funcionalidad de Antivirus debe contemplar los siguientes protocolos SMTP, POP3, Webmail, FTP, IMAP, http. 7.2 Se debe inspeccionar el tráfico entrante y saliente. 7.3 La actualización de la base debe ser configurable y se debe asegurar una actualización cada hora. 7.4 El tiempo de respuesta frente a la propagación de nuevos virus debe ser en promedio de 90 minutos. 7.5 La cantidad de firmas de virus debe ser superior a los La configuración de la funcionalidad debe realizarse por política / regla, pudiendo existir múltiples políticas de Antivirus en la configuración total del equipo. 7.7 La configuración debe permitir la generación de perfiles. Se entiende por perfil a la restricción de protocolos / extensiones / tipos de archivos / acción a tomar. 7.8 La funcionalidad debe informar al usuario (dentro del correo original) que el mismo contenía un adjunto infectado. 7.9 Todos los eventos deben ser logeados.

8 7.10 La funcionalidad debe permitir enviar un mail al administrador del equipo informando sobre el descubrimiento de un virus La funcionalidad debe inspeccionar archivos comprimidos bajo los siguientes formatos: ACE, ARJ, Alloy, Astrum, BZIP2, BestCrypt, CAB, CABSFX, CHM, Catapult, CaveSFX, CaveSetup, ClickTeam, ClickTeamPro, Commodore, CompiledHLP, CreateInstall, DiskDupe, DiskImage, EGDial, Effect Office, Embedded, Embedded Class, Embedded EXE, Embedded MS Expand, Embedded PowerPoint, Embedded RTF, FlyStudio, GEA, GKWare Setup, GZIP, Gentee, Glue, HA, HXS, HotSoup, Inno, InstFact, Instyler, IntroAdder, LHA, MS Expand, MSO, Momma, MultiBinder, NSIS, NeoBook, PCAcme, PCCrypt, PCInstall, PIMP, PLCreator, PaquetBuilder, Perl2Exe, PerlApp, Presto, ProCarry, RARv 1.4 and above, SEA, SbookBuilder, SetupFactory, SetupSpecialist, SilverKey, SmartGlue, StarDust Installer, Stream 1C, StubbieMan, Sydex, TSE, Tar, TeleDisk, Thinstall, ViseMan, WinBackup, WiseSFX, ZIP La funcionalidad debe inspeccionar archivos semi ejecutables bajo los siguientes formatos: pif, lnk, reg, ini (Script.Ini, etc), cla (Java Class), vbs (Visual Basic Script), vbe (Visual Basic Script Encrypted), js (Java Script), jse (Java Script Encrypted), htm, html, htt (HTTP pages), hta HTA (HTML applications), asp (Active Server Pages), chm CHM (compressed HTML), pht PHTML, php PHP, wsh, wsf, the (.theme) La funcionalidad debe inspeccionar archivos bajo los siguientes formatos de MS Office: doc, dot, fpm, rtf, xl*, pp*, md*, shs, dwg (Acad2000), msi (MS Installer), otm (Outlook macro), pdf (AcrobatReader), swf (Shockwave-Flash), prj (MapInfo project), jpg, jpeg, emf (Enhanced Windows Metafile), elf 7.14 La funcionalidad debe inspeccionar archivos ejecutables bajo las siguientes extensiones de DOS: com, exe, sys, prg, bin, bat, cmd, dpl(borland s Delphi files), ov* 7.15 La funcionalidad debe inspeccionar archivos ejecutables bajo las siguientes extensiones de WINDOWS: dll, scr, cpl, ocx, tsp, drv, vxd, fon La funcionalidad debe inspeccionar archivos de como: Eml, nws, msg, plg, mbx (Eudora database) La funcionalidad debe inspeccionar archivos de Ayuda: hlp La funcionalidad debe inspeccionar archivos de otras extensiones como: sh, pl, xml, itsf, reg, wsf, mime, rar, pk, lha, arj, ace. 8 Procesamiento de Contenidos (Funcionalidad General) 8.1 El equipo deberá tener la potencialidad y capacidad adicional de incorporación de las siguientes funcionalidades de procesamiento de contenidos mediante la futura adquisición de la(s) licencias adicionales por parte de la Caja Municipal de Ahorro y Crédito Trujillo: 8.2 Detección y prevención de intrusos para los siguientes protocolos: SMTP, POP3, Webmail, FTP, IMAP, http tanto en tráfico entrante como saliente. 8.3 ANTI-SPAM basado en base de datos de direcciones IP que permiten el acceso, marcado o eliminación de según la procedencia del correo. 8.4 Filtro de contenidos para trafico Web con creación de perfiles y políticas 9 Funcionalidad de Detección de prevención de intrusos 9.1 Deberá soportar al menos dos métodos de detección: 9.2 Firmas basadas en estados. 9.3 Anomalía de protocolo. 9.4 Deberá proteger contra Gusanos, Troyanos y Malware. 9.5 Deberá inspeccionar el tráfico entrante y saliente. 9.6 Deberá detener ataques de reconocimiento. 9.7 Deberá soportar la creación de firmas especiales. 9.8 Deberá soportar al menos 90+ contextos de aplicaciones. 9.9 Deberá soportar firmas tipo Stream para Gusanos de Red Frente a una detección deberá soportar las siguientes respuestas:

9 Close: Cortar la comunicación y enviar un Reset al servidor y al cliente Close: Cortar la comunicación y enviar un Reset al servidor Close: Cortar la comunicación y enviar un Reset al cliente Drop: Cortar la comunicación sin Reset Drop Packet: Descartar un paquete Ignore: Luego de detector una anomalía, se hace una entrada en el log y se ignora el resto None: Ninguna acción Deberá soportar las siguientes notificaciones frente a ataques Session Packet Log Session Summary SNMP Syslog Webtrends Deberá permitir la creación y aplicación de políticas de uso para aplicaciones de mensajería y/o peer to peer La funcionalidad deberá soportar actualizarse en forma mensual y en emergencia. 10 Funcionalidad de Anti-Spam (esta opción deberá ser soportada cuando se active la licencia de AntiSpam) 10.1 La funcionalidad de Anti-Span debe permitir, marcar o bloquear entrantes hacia la red dependiendo del origen del correo La configuración de la misma debe ser por política protegiendo los servicios de correo de la red La lista de orígenes maliciosos debe actualizarse al menos 2 veces cada hora La lista debe obtenerse a nivel mundial explorando múltiples países (al menos 20) y más de 2 millones de Honeypots. 11 Funcionalidad de Filtrado de contenidos (esta opción deberá ser soportada cuando se active la licencia de Filtro de Contenidos) 11.1 La funcionalidad de filtrado de contenidos debe permitir/ bloquear el acceso de los usuarios a diferentes sitios web no/considerados maliciosos El comportamiento esperado de esta funcionalidad es que el Firewall permita/bloquee la pagina solicitada por cualquier usuario basado en la categoría en la que pertenece dicha pagina y en función del perfil del usuario Esta funcionalidad debe poder configurarse, por política, desde la interfaz grafico (GUI) del equipo Esta funcionalidad debe permitir la creación de perfiles de usuarios con diferentes permisos de acceso a las diferentes categorías Deberá soportar al menos 50 categorizaciones incluyendo: Phising y Fraude, Spyware, Sitios adultos y Sexo explicito, Juego, Hacking, drogas ilegales, Violencia, Armas, Sitios ofensivos a la moral, Actividades criminales, Alcohol y Tabaco, entre otras El servicio deberá incluir al menos 10 millones de URLs clasificadas El servicio deberá incluir la incorporación y categorización de al menos páginas semanales La categorización de páginas deberá considerar al menos 70 idiomas. 12 Alta Disponibilidad 12.1 Los Firewalls serán configurados en Alta Disponibilidad, lo que garantizara la continuidad de las operaciones y servicios Los Firewalls deberán soportar Alta Disponibilidad en modo Activo-Activo en Capa 3 (mode L3).

10 12.3 Los Firewalls deberán soportar Alta Disponibilidad en modo Activo-Pasivo en Capa 3 (mode L3) y Capa 2 (mode L2) La configuración debe ser sincronizada entre los dos Firewalls en forma automática Cada Firewall deberá tener la capacidad de soportar una segunda fuente redundante. ESPECIFICACION DEL SISTEMA DE GESTION CANTIDAD: (01) 1. Generalidades 1.1 Todos los componentes que conformen la solución, deben poder ser configurados y monitoreados en su totalidad, a través de un software de administración a ser provisto, instalado y configurado por el contratista. 1.2 Se solicita una solución de administración de los dispositivos compuesta por una consola de administración y software cliente (estaciones de trabajo de administración y monitoreo) que se utilizara para la conexión de los administradores a la consola. 1.3 El Postor deberá presentar el Servidor donde será instalado el Sistema de gestión, no se aceptarán maquinas o Pcs compatibles de escritorio para tal fin. 1.4 La consola de administración será utilizada como repositorio primario de las configuraciones, sistemas operativos de los dispositivos a administrar en forma centralizada, logs, reportes etc. 1.5 La actualización del sistema operativo (firmware) de los dispositivos se deberá actualizar desde la consola de administración centralizada 1.6 El software de la consola debe instalarse en una plataforma genérica del tipo Solaris o Linux (que debe ser suministrada por el contratista). 1.7 La consola de administración deberá ser accedida utilizando un browser genérico (WEBUI) para permitir una visualización y configuración básica. Del portal provisto por la consola para acceso básico se podrá descargar el cliente de administración general de los dispositivos. La configuración básica constara como mínimo de : Manejo y actualización de licencias Configuración y visualización de dirección IP / mask, Default Gateway, DNS y rutas estáticas System security updates. 1.8 El acceso WEBUI permitirá la visualización de : Status/Uptime del servidor de administración Errores o mensajes críticos Utilización de memoria y CPU Espacio libre en disco Tasa de recepción de logs en la consola de administración Configuración y ejecución de las tareas de Backup y Restore Herramientas de red como Ping Traceroute etc Core files. 1.9 El sistema debe soportar la autenticación de usuarios administrativos por medio de RADIUS y Base de Datos Local Este software de administración deberá poder ser operado en forma simultánea desde un mínimo de veinte (20) estaciones de trabajo de administración y monitoreo con el uso del cliente específico (software cliente), debiéndose entregar las licencias correspondientes para tal cantidad de clientes La comunicación entre los software clientes y el servidor de administración debe establecerse a través de un protocolo seguro con encripción y autenticación (sin necesidad de establecer una VPN por medio de usuarios locales, certificados digitales, tokens, LDAP versión 3 y Radius)

11 1.12 Los usuarios del software cliente accederán al mismo a través de PC con sistema operativo Windows 2003, Windows XP y Linux. Si se requiriera software específico para estas PC, el mismo deberá ser provisto y licenciado por el oferente El software de administración permitirá la actualización centralizada del software y/o firmware de todos los equipos que componen la solución ante updates/upgrades que pudieran ser liberados por el fabricante del software. 2. Redundancia y Escalabilidad 2.1 El software de administración debe tener la capacidad de configurarlo en alta disponibilidad soportando sincronización y conmutación automática entre servidores. 2.2 Será posible instalar 2 servidores, primario y secundario, donde el equipo secundario estará en sincronismo con el primario y tomara la administración de los dispositivos en caso de falla del primario. 2.3 La capacidad máxima de gestión del sistema debe soportar como mínimo los 5 dispositivos de red entre Firewalls e IPS. 2.4 El servidor de administración deberá realizar Backup diario en forma automática de toda la información almacenada en el mismo incluyendo configuraciones y reglas de todos los módulos administrados y transferirlos automáticamente a un servidor remoto utilizando protocolo SSH. 3. Configuración 3.1 El software de administración permitirá, como mínimo, lo siguiente: Será completamente orientado a objetos donde los objetos serán utilizados como parámetros para crear las reglas de los distintos dispositivos de red Crear, borrar o actualizar objetos que referencien a los dispositivos de red (hosts), redes, zonas o ataques Los objetos podrán agruparse a criterio del administrador y adicionalmente existirán agrupaciones dinámicas de objetos con características comunes Los objetos serán utilizado para crear en un entorno grafico las reglas o políticas de tráfico Se podrán asignar configuraciones totales o parciales por grupos de equipos Los objetos se asociaran a las reglas en forma sencilla, seleccionando el objeto correspondiente y descargando el mismo dentro de la regla (drag and drop) Será posible agregar, eliminar o modificar las reglas en un entorno gráfico Modificar las reglas de los diferentes equipos en forma conjunta o individual Crear modelos de configuración parcial y/o generales que podrán ser aplicados a cualquiera de los equipos de la red (ejemplo templates, modelos, plantillas etc) Actualizar las políticas de seguridad de los componentes de la solución en forma central Aplicar centralmente actualizaciones o correcciones de software y/o firmeware a los componentes de la solución Realizar filtrados de políticas según diversos criterios. 3.2 La consola de administración deberá ser capaz de desactivar en forma remota las reglas de cualquier dispositivo de manera individual e independiente sin importar las reglas previamente configuradas en dicho equipo. 3.3 Los objetos como redes, host, etc. deben poder asignarse a cualquier equipo activo en la consola de administración. 3.4 Poder generar reportes sobre diferencias entre configuraciones de diferentes equipos. 3.5 Permitirá tomar control de equipos existentes importando la actual configuración. 3.6 Los equipos monitoreados por la consola podrán ser accedidos por otros métodos en forma directa (SSH, Telnet, WEB, HTTPs etc) según lo permita el administrador.

12 3.7 Deberá existir mecanismos de sincronización de las configuraciones existentes en la consola y en el equipo real. 4. Roles de Administración 4.1 Será posible crear roles para los distintos perfiles de administrador con un mínimo de 30 perfiles. Los roles reflejaran la estructura de administración de la empresa. 4.2 La creación de roles debe poder definir que administrador puede realizar las distintas tareas y configuraciones especificas. 4.3 Cada perfil de administrador tendrá distintos privilegios en el acceso a la información o configuración de objetos o dispositivos desde la consola. 4.4 Podrán restringirse el acceso de administradores a la vista configuración o generación de reportes de sobre dispositivos específicos. 4.5 Se podrán configurar perfiles que permitan visualizar el contenido de los reportes exclusivamente. 4.6 Se podrá configurar perfiles que permitan visualizar el contenido de los logs y realizar seguimiento de los mismos. 4.7 Los perfiles o roles de administrador contemplaran el siguiente esquema como mínimo: Administrador Nivel 1 con permiso sobre las vistas de eventos y auditoria Administrador Nivel 2 con permiso sobre vistas de eventos y auditoría de las configuraciones y con permiso para configuración y modificación de parámetros de red exclusivamente Administrador Nivel 3 permiso de acceso sin restricciones para modificar configuraciones y políticas Administrador de Reportes tendrá acceso a vista y generación de reportes. 5. Monitoreo El software de administración permitirá: 5.1 Visualizar en tiempo real de los logs de actividad de los equipos de la solución y las modificaciones de configuración que los administradores pudieran efectuar. 5.2 Ingresar a cada equipo de la solución en forma individual para la realización de tareas de mantenimiento (Booteo, Reinicialización, Verificación de estado) mediante protocolo SSH y HTTPS. 5.3 Controlar la disponibilidad. Se deberá ofrecer visualización de disponibilidad para todos los equipos gestionados, con la posibilidad de armar diferentes grupos. 5.4 El sistema debe permitir la representación grafica e interactiva de la relación, dentro de la red, entre hosts, networks, servicios y ataques. Se entiende por interactiva a la funcionalidad de ampliar, reducir o cambiar la representación grafica desde el mismo grafico informativo y/o los datos que lo componen. 5.5 Debe soportar la Correlación y agregación de eventos centralizado. 6. Logging 6.1 El servidor de administración deberá tener la capacidad de almacenamiento suficiente para preservar los logs de los diferentes equipos de la solución por dos meses. Deberá mantener un log permanente de las conexiones aceptadas y rechazadas. 6.2 El log debe incluir la información detallada del paquete que lo genera como información de accounting (como ser la duración de la conexión, bytes y frames transferidos, etc.). 6.3 Debe ser posible configurar a cada uno de los equipos administrados para enviar logs a syslogs servers o mail servers. 6.4 Será condición que como mínimo los siguientes eventos generen una entrada en el repositorio de logs: Ataque o Alarma correspondiente a la acción configurada en la política Evento de VPN-IPSEC

13 6.4.3 Configuraciones, tráfico especificado en las políticas etc. 6.5 La severidad de los logs deberá ser definible en base a la configuración de la política correspondiente y la categoría del log (ejemplo información, ataque, alarma trafico etc.) 6.6 La consola de administración deberá tener integradas herramientas que permitan la visualización de los logs en forma sintética o en detalle sobre tráfico y modificaciones realizadas por los administradores (log audit) 6.7 Los logs de los equipos deben cumplir con las siguientes características: Poder ser transferidos, utilizando un método seguro (sin necesidad de establecer una VPN), hacia el servidor de administración Poder ser transferidos al servidor de administración en el mismo momento que son generados, sin que el inicio de la transferencia sea demorada Poder ser exportados desde el servidor de administración a un formato de texto bien definido (XML, CSV), para poder utilizar herramientas de análisis de terceros Los equipos deben poder almacenar en forma local los logs, para aquellos casos que existan inconvenientes en la comunicación con el servidor central. 7. Administración 7.1 El software de administración debe mantener una base de datos con la configuración actual de todos los equipos de red. 7.2 El software deberá ofrecer una herramienta de seguimiento de cambios (hardware, software o configuración) que permita detectar cambios en configuración, versión de software o cambios en el hardware. Se deberá conocer qué es lo que cambió, quien efectuó el cambio y en qué momento. 7.3 El sistema debe contar con Logs de Auditoria de la utilización y control de cambios de reglas y políticas uso en general. 7.4 Acceso a una vista gráfica con posibilidad de controlar y/o cambiar la configuración de cada equipo. Debe permitir una vista gráfica del equipo, distinguiendo el estado de sus interfaces/puertos con un color diferente para cada tipo de estado, accediendo desde allí a estadísticas del tráfico, errores. 7.5 El sistema debe permitir la visualización de información de tráfico en la red referido a usuarios, protocolos, versiones de software y aplicaciones utilizadas. 7.6 El sistema debe permitir la configuración de alertas cuando se incorporar a la red nuevos servidores, nuevos clientes y nuevas aplicaciones. 7.7 Soporte de correlación de patrones de ataques como un único grupo de eventos. 7.8 El sistema deben incluir herramientas para el mantenimiento y el backup de la solución. 8. Reportes 8.1 La consola de administrador tendrá integrada una aplicación que permitirá generar reportes en base a los logs recibidos por los diferentes dispositivos administrados. 8.2 Los reportes se presentaran en un formato grafico exportable a HTML que permitirá la visualización de distribución de protocolos y tendencias. 8.3 Los reportes se generaran por eventos ocurridos en un periodo de tiempo o por cantidad total de eventos. 8.4 Los reportes podrán agruparse por tipo de log o dispositivo que lo genera. 8.5 El sistema debe soportar reportes pre-configurados y la opción de reportes configurables por usuarios. 8.6 El sistema debe soportar la programación de generación de reportes automáticos. 8.7 Desde cada reporte se debe poder acceder en forma directa a los logs que lo originan 8.8 Los reportes pre-configurados deben contemplar, como mínimo, los siguientes: Ataques más frecuentes para IDP o FW ( Top 100 Atacks/Alarms) Ataques prevenidos en periodo de tiempo Mayor cantidad de ataques en ultimas 24hs

14 8.8.4 Ataques más frecuentes por origen (Top Sources) Trafico más frecuente ( Top Traffic Alarms) Cambios de configuración mas frecuentes ( Top Configuration Logs) Escaneos de puertos realizados en periodo de tiempo Orígenes y Destinos mas escaneados en periodo de tiempo Reglas más ejecutadas Direcciones IP mas atacadas Muestra de ataques mas frecuentes ordenados por severidad Cantidad de paquetes aceptados (total consolidado y de cada uno de los equipos) Cantidad de paquetes denegados (total consolidado y de cada uno de los equipos). 9. Características mínimas del Servidor donde será instalado el Sistema de Gestión Tamaño: 1RU (1 unidad de Rack). Dos discos duros SATA de 300 Gb c/u. 3 Gb de Ram. Tarjeta de Red 100/1000. Procesador Intel Xeon o Dual Core de 1.80 Mhz. PROCESO DE IMPLEMENTACIÓN Y CAPACITACIÓN 1. Instalación, configuración y puesta en producción del Firewall /VPN en un Esquema de ALTA DISPONIBILIDAD. 2. Instalación, configuración y puesta en producción del SISTEMA DE DETECCION Y PREVENCION DE INTRUSOS IPS. 3. Instalación, configuración y puesta en producción del SISTEMA DE GESTION para el monitoreo y gestión de la solución a instalarse. 4. Pruebas de funcionalidad de la nueva infraestructura de almacenamiento y respaldo de datos. Estas pruebas se llevarán a cabo de acuerdo a un plan aprobado por el postor y Caja Trujillo que comprenderán como mínimo las siguientes fases: 3.1 Planeamiento y Diseño. 3.2 Implementación. 3.3 Pruebas de Esfuerzo. 3.4 Pruebas de Alta Disponibilidad para los Firewalls. 3.5 Puesta en Producción. 3.6 Afinamiento. 5. Se debe incluir Workshop de capacitación práctica para mínimo 3 personas, con una duración mínima de 12 horas la cual será dictada en las instalaciones de la Caja Trujillo, el workshop deberá contemplar los siguientes temas: 5.1 Administración del Firewall /VPN ofertado

15 5.2 Administración del Sistema de Detección y Prevención de Intrusos IPS ofertado CURSOS TALLER ADICIONALES 1. Se ofrecerá puntuación adicional al postor que ofrezca al menos uno de los Cursos-Taller, que se detallan a continuación: a. Diseño de un Sistema de Gestión de Seguridad de la Información SGSI (ISO 7001) b. Diseño de un Plan de Recuperación de Desastres c. Análisis y Gestión de Riesgos de Seguridad 2. La duración de cada curso-taller no deberá ser menor a 16 horas. 3. El número máximo de participantes será de 04 personas. 4. El dictado del curso estará a cargo de un Profesional, con experiencia no menor de 03 años en Seguridad de la Información, deberá estar en la planilla del postor con no menos de 1 año de antigüedad y contar con certificación Internacional vigente en la especialidad (CISA, CISM o Auditor Líder ISO 27001), se deberán adjuntar las constancias de certificación y declaración jurada del postor en la que se indique la antigüedad del profesional en la empresa. 5. El postor deberá entregar materiales del curso (un juego por participante), además del certificado de participación a cada asistente. 6. El curso taller será dictado en las instalaciones del Postor dentro del territorio Peruano, CMAC Trujillo asumirá los gastos de traslados, alojamientos y viáticos del personal que asistirá al curso. SERVICIOS ADICIONALES 1. Se ofrecerá puntación adicional al postor que ofrezca un servicio de Ethical Hacking en modalidad externo para 4 Ips públicas. 2. El servicio de Ethical Hacking deberá ser realizado por un profesional con no menor de 4 años de experiencia en Comunicaciones y Seguridad, el cual deberá estar en la planilla del postor con no menos de 2 años de antigüedad. Se deben acreditar las constancias y certificados que demuestren la experiencia. 3. El profesional que realizará el servicio de Ethical Hacking deberá haber llevado un curso oficial de Ethical Hacking en un centro autorizado EC Council, se deberá adjuntar el certificado del curso. 4. Deberá presentar y entregar un informe detallado del servicio de Ethical Hacking. GARANTÍA Y SOPORTE 1. La solución deberá tener una garantía de un (01) año por fallas físicas en todos los componentes de la solución. 2. Se debe considerar que en caso de falla de cualquiera de los componentes este debe ser reemplazado en su totalidad en un plazo no mayor a 72 horas entregado en la ciudad de Trujillo.

16 3. La solución deberá contemplar la descarga de actualizaciones (software de administración, firmwares, parches, firmas, etc.) de la solución por un período no menor a un (01) año, 4. Los servicios de soporte deben contemplar una atención 24x7x4 por un año en modalidad Telefónico, y Remoto con un tiempo de respuesta máximo de 4 horas ante incidentes graves. REQUISITOS DEL POSTOR: (Para agregarlo en los requisitos de los participantes) El Postor que proveerá los equipos deberá ser un Canal autorizado por el fabricante y deberá presentar una carta otorgada por el fabricante en la que se indique que el Postor está autorizado a ofertar los equipos para este proceso de selección, en la carta se deberá consignar que el Postor está autorizado a ofertar los equipos para la Adjudicación Directa Selectiva Nº CMAC-T. TIEMPO DE ENTREGA DE LOS EQUIPOS: - El tiempo de entrega de estos equipos de seguridad es de 40 días - Tiempo de implementación: 7 días Tiempo de entrega servicio: Sumando el servicio de Ethical Hacking externo y el curso taller adicional podemos estimar en 60 días el tiempo total por todo el servicio (Entrega de equipos más implementación, capacitación y servicios adicionales)criterios DE EVALUACION FACTORES DE EVALUACIÓN TÉCNICA (a) FACTOR REFERIDO AL POSTOR Monto Facturado acumulado, de bienes de la adquisición materia de la convocatoria y/o similar. Se sustentarán con copias de no más de diez (10) contratos culminados acompañados de su respectiva constancia de conformidad de la prestación de servicios, ó copias de facturas debidamente canceladas, con un periodo no mayor a cinco (05) años de la presentación de las propuestas hasta por un máximo acumulado equivalente a cinco (5) veces el valor referencial. Se calificará de acuerdo al siguiente rango: De 3 a más 40 puntos Mayor 2 y Menor o Igual a 3 Veces 30 puntos Mayor 1 y Menor o Igual a 2 Veces 15 puntos Menor o Igual a 1 vez 05 puntos (b) PLAZO DE ENTREGA DE LOS BIENES E IMPLEMENTACION DE LA SOLUCION El plazo de entrega e implementación de los bienes se acreditará a través de una declaración jurada por parte del postor, y se calificará de acuerdo al siguiente rango: Menor o igual a 45 días calendarios 30 puntos Mayor a 45 días calendarios pero Menor o igual a 60 días 20 puntos calendarios Mayor a 60 días calendarios pero Menor o igual a 75 días 10 puntos calendarios Mayor a 75 días calendarios 05 puntos (c) CAPACITACION Se requiere entrenamiento en la solución ofertada para un mínimo de 3 personas, en un Centro de Entrenamiento del fabricante, de la subsidiaria del fabricante y/o local de Caja Trujillo por el postor, fabricante o subsidiaria: PUNTAJE 40 puntos 30 puntos 10 puntos

17 La capacitación de la solución se acreditará a través de una declaración jurada por parte del postor. Se calificará la capacitación referida que oferte el postor al personal de la entidad de acuerdo al siguiente rango: Mayor o igual a 40 horas 10 puntos Mayor a 20 horas y menor a 40 horas 05 puntos Menor a 20 horas 02 puntos (d) MANTENIMIENTO PREVENTIVO El mantenimiento preventivo en el local de Caja Trujillo (On Site) durante el periodo de vigencia de la garantía y se acreditará a través de una declaración jurada por parte del postor. Se evaluará por el número de veces que el proveedor oferte de acuerdo al siguiente rango. Mayor o igual a 2 veces al año 10 puntos 1 vez al año 05 puntos 20 puntos