IPS Fecha Limite de entrega

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 19”
1.4 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).
2.10
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:
4.4.1
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),
MS-RPC, VNC, IDENT, Gopher, NNTP, RUSERS, IRC, Gnutella, NTP, WHOIS,
LDAP, NBNAME, SSL, NBDS, RADIUS.
4.4.2
Mensajeria Instantanea: AOL-IM, Yahoo-IM, MSN-Messenger
4.4.3
Aplicaciones P2P: BearShare, Gnucleus, Morpheus, Swapper, XoloX,
Gnewtellium, Gnutella, Mutella, eMule, eDonkey, ernet, Qtella, LimeWire, Phex,
Kazaa, Napster, WinMX.
4.4.4
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,000.
4.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.
4.10
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.
4.11
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.
4.12 Detección de protocolo por asignación de puerto.
4.13 Detección de protocolo en forma independiente del puerto utilizado.
4.14 Detección de protocolos en forma encapsulada.
4.15 Detección de protocolos a nivel capa 2 del modelo OSI. (Detallar).
4.16 Detección de protocolos a nivel capa 7 del modelo OSI. (Detallar).
4.17 Detección de anomalías de protocolos con reensamblados de paquetes fragmentados
(TCP Reassembly).
4.18
Detección de anomalías de protocolos con reensamblado de sesiones
fragmentadas (Flow Reassembly).
4.19
Detección de shell code en técnicas de ataque de Buffer Overflow.
4.20
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.
4.21
Protección contra Gusanos y Troyanos.
4.22
Protección contra Spyware, Adware y Keyloggers.
4.23
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.
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 e-mail, 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.
6.11
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:
7.2.1 Close: Cortar la comunicación y enviar un Reset al servidor y al cliente
7.2.2 Close: Cortar la comunicación y enviar un Reset al servidor
7.2.3 Close: Cortar la comunicación y enviar un Reset al cliente
7.2.4 Drop: Cortar la comunicación sin Reset
7.2.5 Drop Packet: Descartar un paquete
7.2.6 Ignore: Luego de detector una anomalía, se hace una entrada en el log y se
ignora el resto.
7.2.7 None: Ninguna acción
7.2.8 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
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 email.
9.3 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 :
9.5.1
Utilización de CPU
9.5.2
Espacio de disco utilizado
9.5.3
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.
1.10 SNMP: Simple Network Management Protocol.
1.11 VPN: Virtual Private Network.
1.12 WAN: Red de alcance nacional.
1.13 DOS: Denial of Service
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 + 8.33% de los paquetes de 1518
byte en UDP
1.18 TOS : Type of Service
1.19 QOS : Quality of Service (Calidad de Servicio)
2
3
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.
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/1000.
3.2 Soportar crecimiento mínimo de 24 interfaces 10/100/1000.
3.3 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.
3.10
Cada firewall no deberá tener un límite de concurrencia de usuarios impuesto
por el hardware ni por el software o licencias.
3.11
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-1.
4.2 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 5.
4.5 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.
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.
5.10 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.
5.11 Proveer de logeo remoto utilizando syslog.
5.12 Soporte de Alta disponibilidad en modo Activo-Pasivo.
5.13 Soporte de WINS.
5.14 Autenticación de usuarios en forma local, por RADIUS, LDAP, Firmas digitales.
5.15 Soporte de protocolo de enrutamiento RIP.
5.16 Soporte de protocolo de enrutamiento OSPF.
5.17 Soporte de protocolo de enrutamiento BGPv4.
5.18 Soporte de Policy Based Routing basados en IP-Source/Puerto(TCP o UDP) IPDestino/Puerto (TCP o UDP) y TOS.
5.19 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.
5.20 Las reglas deben permanecer en medio físico, no volátil.
5.21 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.
5.22 La configuración de equipos de la solución deberá almacenarse además de
centralmente, localmente de manera redundante.
5.23 Deberá soportar la configuración de administradores locales (mínimo 20).
5.24 Los administradores que accedan a los firewalls deberán autenticarse mediante
Radius, LDAP o SECURID.
5.25 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 : 6
5.26 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.
5.27 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.
5.28 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
pedidos de ARP que no son dirigidos directamente hacia direcciones IP declaradas en
sus propias interfaces.
5.29 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.
5.30 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.
5.31 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.
5.32 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).
5.33 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.
5.34 La solución deberá soportar la activación y desactivación de técnicas de anti-spoofing
sobre cada zona de seguridad.
5.35 La solución deberá soportar técnicas de mitigación de spoofing en todas las interfaces.
5.36 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 100000.
7.6 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.
7.10
La funcionalidad debe permitir enviar un mail al administrador del equipo
informando sobre el descubrimiento de un virus.
7.11
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.
7.12
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).
7.13
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 386.
7.16
La funcionalidad debe inspeccionar archivos de Email como: Eml, nws, msg,
plg, mbx (Eudora database).
7.17
La funcionalidad debe inspeccionar archivos de Ayuda: hlp.
7.18
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 e-mail 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.
9.10
Frente a una detección deberá soportar las siguientes respuestas:
9.10.1 Close: Cortar la comunicación y enviar un Reset al servidor y al cliente.
9.10.2 Close: Cortar la comunicación y enviar un Reset al servidor.
9.10.3 Close: Cortar la comunicación y enviar un Reset al cliente.
9.10.4 Drop: Cortar la comunicación sin Reset.
9.10.5 Drop Packet: Descartar un paquete.
9.10.6 Ignore: Luego de detector una anomalía, se hace una entrada en el log y se
ignora el resto.
9.10.7 None: Ninguna acción.
9.11
Deberá soportar las siguientes notificaciones frente a ataques
9.11.1 Session Packet Log.
9.11.2 Session Summary.
9.11.3 E-mail.
9.11.4 SNMP.
9.11.5 Syslog.
9.11.6 Webtrends.
9.12
Deberá permitir la creación y aplicación de políticas de uso para aplicaciones de
mensajería y/o peer to peer.
9.13
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 e-mail entrantes hacia
la red dependiendo del origen del correo.
10.2 La configuración de la misma debe ser por política protegiendo los servicios de correo
de la red.
10.3 La lista de orígenes maliciosos debe actualizarse al menos 2 veces cada hora.
10.4 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.
11.2 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.
11.3 Esta funcionalidad debe poder configurarse, por política, desde la interfaz grafico
(GUI) del equipo.
11.4 Esta funcionalidad debe permitir la creación de perfiles de usuarios con diferentes
permisos de acceso a las diferentes categorías.
11.5 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.
11.6 El servicio deberá incluir al menos 10 millones de URLs clasificadas.
11.7 El servicio deberá incluir la incorporación y categorización de al menos 50000 páginas
semanales.
11.8 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.
12.2 Los Firewalls deberán soportar Alta Disponibilidad en modo Activo-Activo en Capa 3
(mode L3).
12.3 Los Firewalls deberán soportar Alta Disponibilidad en modo Activo-Pasivo en Capa 3
(mode L3) y Capa 2 (mode L2).
12.4 La configuración debe ser sincronizada entre los dos Firewalls en forma automática.
12.5 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 :
1.7.1 Manejo y actualización de licencias.
1.7.2 Configuración y visualización de dirección IP / mask , Default Gateway, DNS y
rutas estáticas.
1.7.3 System security updates.
1.8 El acceso WEBUI permitirá la visualización de :
1.8.1 Status/Uptime del servidor de administración.
1.8.2 Errores o mensajes críticos.
1.8.3 Utilización de memoria y CPU.
1.8.4 Espacio libre en disco.
1.8.5 Tasa de recepción de logs en la consola de administración.
1.8.6 Configuración y ejecución de las tareas de Backup y Restore.
1.8.7 Herramientas de red como Ping Traceroute etc.
1.8.8 Core files.
1.9 El sistema debe soportar la autenticación de usuarios administrativos por medio de
RADIUS y Base de Datos Local.
1.10
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.
1.11
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)
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.
1.13
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:
3.1.1 Será completamente orientado a objetos donde los objetos serán utilizados
como parámetros para crear las reglas de los distintos dispositivos de red
3.1.2 Crear, borrar o actualizar objetos que referencien a los dispositivos de red
(hosts), redes, zonas o ataques.
3.1.3 Los objetos podrán agruparse a criterio del administrador y adicionalmente
existirán agrupaciones dinámicas de objetos con características comunes.
3.1.4 Los objetos serán utilizado para crear en un entorno grafico las reglas o
políticas de tráfico.
3.1.5 Se podrán asignar configuraciones totales o parciales por grupos de equipos.
3.1.6 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)
3.1.7 Será posible agregar, eliminar o modificar las reglas en un entorno gráfico.
3.1.8 Modificar las reglas de los diferentes equipos en forma conjunta o individual.
3.1.9 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)
3.1.10
Actualizar las políticas de seguridad de los componentes de la solución
en forma central.
3.1.11
Aplicar centralmente actualizaciones o correcciones de software y/o
firmeware a los componentes de la solución.
3.1.12
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.
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:
4.7.1 Administrador Nivel 1 con permiso sobre las vistas de eventos y auditoria.
4.7.2 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.
4.7.3 Administrador Nivel 3 permiso de acceso sin restricciones para modificar
configuraciones y políticas.
4.7.4 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:
6.4.1 Ataque o Alarma correspondiente a la acción configurada en la política
6.4.2 Evento de VPN-IPSEC
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:
6.7.1 Poder ser transferidos, utilizando un método seguro (sin necesidad de
establecer una VPN), hacia el servidor de administración.
6.7.2 Poder ser transferidos al servidor de administración en el mismo momento
que son generados, sin que el inicio de la transferencia sea demorada.
6.7.3 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.
6.7.4 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:
8.8.1 Ataques más frecuentes para IDP o FW ( Top 100 Atacks/Alarms)
8.8.2 Ataques prevenidos en periodo de tiempo
8.8.3 Mayor cantidad de ataques en ultimas 24hs
8.8.4
8.8.5
8.8.6
8.8.7
8.8.8
8.8.9
8.8.10
8.8.11
8.8.12
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).
8.8.13 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
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.
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, Email 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º 004-2009-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 PUNTAJE 40 puntos 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 Mayor 2 y Menor o Igual a 3 Veces Mayor 1 y Menor o Igual a 2 Veces Menor o Igual a 1 vez 40 puntos 30 puntos 15 puntos 05 puntos (b) PLAZO DE ENTREGA DE LOS BIENES E IMPLEMENTACION DE LA SOLUCION 30 puntos 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: 10 puntos 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