Javier Guerra

Solución Firewall de Aplicaciones Web

1. Condiciones Generales

• La solución estará conformada por equipamiento basado en plataforma appliance (hardware y software de propósito específico) del mismo fabricante, que proporcione las funcionalidades WAF y consola de gestión. Sin necesidad de la instalación de software y/o hardware en algún equipo adicional que no forme parte de la solución.

• Proporcionar, con el correspondiente respaldo del fabricante, los servicios de garantía de hardware, mantenimiento software y soporte técnico, para la solución por el periodo de dos (02) años.

2. Funcionalidades WAF

2.1. Características del appliance

• El equipo WAF perteneciente a la solución debe poseer como mínima las siguientes características:

o Contar con cuatro (04) interfaces Ethernet 100/1000Base-TX.

o Poseer una (01) interface independiente para administracion, de tipo Ethernet 100Base-TX.

o Contar con 4GB de RAM y 500 GB de disco duro.

o Throughput de 500 Mbps.

o Soportar bypass de dos (02) segmentos ante fallas.

o Soportar aceleracion SSL en forma opcional.

o Rackeable en gabinete de 19".

• Soportar varios modos de operación, tales como puente transparente en línea (transparent inline bridge) y fuera de linea (non-inline).

• Capacidad de integrarse a la red en modo bridge (capa 2 del Modelo OSI, las interfaces no requieren de una dirección IP). Las interfaces deben incluir bypass/failopen/failclose configurable tanto para fallas de hardware como de software.

• Permitir la integración en los modos reverse proxy explícito y reverse proxy transparente.

• Capacidad de integrarse a la red en modo sniffing analizando el tráfico de red a través de port mirroring.

• La solución deberá soportar el volumen de tráfico y deberá tener una latencia sub¬milisegundo, para no impactar el desempeño de las aplicaciones web.

2.2. Protección de aplicaciones web

• Permitir bloquear las transacciones web en forma preventiva, antes de que estas lleguen al servidor.

• Capacidad de detectar, alertar y opcionalmente bloquear, en tiempo real, cualquier comportamiento malicioso conocido y/o desconocido.

• Contar con un modo de aprendizaje que permita definir cuáles son las acciones esperadas y aceptadas para los usuarios.

• El modo de aprendizaje, deberá aprender la estructura y elementos de la aplicación y esta información deberá estar disponible para automatizar la configuración del modelo positivo de seguridad. Como mínimo debe aprender sobre: Hosts válidos, URLs, parámetros, tipo de contenidos de los parámetros y cookies.

• En modo aprendizaje, deberá aprender también en base al comportamiento esperado del usuario y este información deberá estar disponible para automatizar la configuración del modelo positivo de seguridad. Como mínimo debe aprender sobre: Longitud del valor esperado, caracteres aceptados y si el parámetro es de solo lectura o editable por el usuario.

• El modo aprendizaje podrá ser activado y desactivado manualmente para extender el tiempo de reconocimiento del patrón de conducta.

• A fin de asegurar la calidad de los datos auditados, al operar en modo bridge la solución no debe modificar las conexiones entre los clientes y el servidor, por lo que se debe asegurar que los mismos paquetes (IP origen, IP destino, puerto origen, puerto destino, número de secuencia y datos de TCP) sean idénticos en ambos extremos.

• Respecto de algún ataque o alguna otra actividad no autorizada, la solución deberá ser capaz de tomar las acciones adecuadas, como mínimo: Terminar las solicitudes y respuestas, bloquear la sesión TCP, bloquear el usuario de la aplicación y bloquear la dirección IP.

• Contar con un conjunto de patrones correspondientes a los ataques conocidos. Esta base de datos de patrones debe actualizarse periódicamente en forma automática y no asistida.

• Permitir la creaci6n de reglas lógicas que permitan identificar condiciones definidas por los usuarios, como una expresión regular o un valor determinado, en cualquier de los siguientes elementos: Encabezado y cuerpo del requerimiento HTTP, encabezado y cuerpo de la respuesta HTTP.

• Permitir definir para las alarmas condiciones lógicas, en la cual la alarma no se dispare si no ha ocurrido por lo menos una cantidad de veces definida, en un periodo de tiempo definido.

• Capacidad de analizar el trafico HTTPS sin la necesidad actuar como terminador de las sesiones SSL.

• Capacidad de proteger Web Servicies basados en SOAP y de aprender las estructuras de los elementos SOAP y su contenido, proponiendo la configuración.

• Capacidad de recibir y utilizar los certificados y pares de llaves publico/privadas para los servidores web protegidos.

• Contar con las siguientes funcionalidades:

ü Inspeccionar y monitorear todos los datos HTTP y la aplicación, incluyendo, los encabezados HTTP, campos de formularios, y el cuerpo HTTP.

ü inspeccionar las peticiones y respuestas HTTP.

ü Capacidad de decodificar datos a su mínima expresión y validarla.

ü Validar todos los tipos de datos ingresados, incluyendo URLs, formularios, cookies, cadenas de queries, campos y parámetros ocultos, métodos http, elementos XML y acciones SOAP.

• Disponer de una funcionalidad de búsqueda de servidores web en la red y la capacidad para configurar automáticamente la protección para los servidores encontrados.

• Capacidad de identificar el usuario de la aplicación web. La identificación debe persistir hasta que el usuario haya abandonado la aplicación.

• Permitir identificar y mantener un registro de las sesiones web a nivel aplicativo, por medio del seguimiento de cookies o parámetros de aplicación.

• Capacidad de efectuar el parchado virtual de las aplicaciones web, para remediar las vulnerabilidades detectadas

...