Una historia práctica del firewall – Parte 2: El valor de la gestión

Jody Brazil CEO de FireMon Check Point y los firewalls de inspección de estado ganaron la primera batalla contra los firewalls proxy (Parte 1: Los primeros días). Es fácil suponer que todo se debió a la tecnología de inspección, pero eso pasa por alto una innovación clave de la solución de Check Point: la gestión de políticas. Que los firewalls de inspección de estado se impusieran a la competencia de los proxy a mediados de los 90 se debió, en gran parte, a la facilidad de gestión. Gran parte de este artículo se centra en Check Point. Esto se debe principalmente al papel dominante que Check Point desempeñó en el mercado de firewalls a finales de los 90 y principios de los 2000. Sin embargo, también es probable que se deba a mi exposición a Check Point en esos años. Agradezco su perspectiva y espero sus comentarios. Mediados de los 90 fue una época en la que las redes evolucionaban rápidamente. Por ejemplo, ethernet era una opción, pero no siempre el protocolo de red local en uso (¿recuerda token ring?). Conectarse a Internet no se daba por sentado, se discutía. El acceso telefónico todavía era común y AOL era el actor dominante. Sugerir que los firewalls eran una tecnología generalizada sería malinterpretar a Internet como algo generalizado. Una de las implicaciones de esta red en rápido cambio fue una cantidad significativa de desconocimiento e inexperiencia. En este contexto, la facilidad de gestión de un firewall no debe pasarse por alto como un factor clave del mercado para el eventual ganador. Hoy, en el desarrollo de software, hablamos de experiencia de usuario y usabilidad. Aunque esas no eran las palabras de moda en ese momento, la razón por la que hablamos de ellas hoy importaba igual entonces. A los clientes les “gustaba” más el producto. Así que, si bien la seguridad y el rendimiento importaban, la usabilidad de la interfaz gráfica del firewall de Check Point no debe descartarse. Citando a un representante de ventas de Gauntlet de aquella época: “No importaba quién fuera el prospecto, en cada cuenta a la que entraba tenía que luchar contra la interfaz gráfica de Check Point, y por lo general perder”. Check Point presentó su firewall con gestión central y una interfaz de usuario muy innovadora. Algunas de las capacidades clave incluían:

• Un editor gráfico de reglas
• Repositorio central de objetos compartido entre las políticas de firewall
• Registro centralizado
• Gestión multidominio y OPSEC

El editor de políticas de Check Point

El concepto de que una regla de firewall sea una tupla de cinco elementos —origen, destino, protocolo, puerto (el protocolo y el puerto se combinaban en un único objeto denominado servicio) y acción— existía mucho antes del editor de políticas de Check Point. Las primeras listas de control de acceso admitían este concepto en los años 80. Sin embargo, Check Point cambió el paradigma con el editor gráfico de reglas. Ya no era necesario conocer la sintaxis de la CLI para crear una regla. Bastaba con un mouse y unos cuantos clics. Además, la edición de reglas se complementó con funciones útiles como copiar y pegar, comentarios definidos por el usuario y varios objetos por columna. Este último punto sobre varios objetos por columna fue revolucionario. Las listas de control de acceso anteriores solo admitían un único origen, un único destino y un único servicio en las columnas respectivas. La compatibilidad con varios objetos hizo que cada regla fuera más potente, y editar una política a menudo se convirtió en un acto de modificar una regla existente en lugar de crear reglas nuevas. Gran parte de este editor de políticas se basaba en otro avance: el repositorio central de objetos.

El repositorio central de objetos de Check Point

Históricamente, las listas de control de acceso se creaban con una referencia a una dirección IP específica para el origen o el destino. Esto funcionaba, pero si la IP de un sistema cambiaba, significaba que todas las reglas debían actualizarse. De forma similar al código fuente reutilizable, Check Point se dio cuenta de que crear un repositorio central de objetos y usar esos objetos en las reglas sería una mejor estrategia. Ahora, si un host cambiaba su IP, solo era necesario actualizar el objeto, y la política reflejaría automáticamente esa actualización de forma correcta, ya que la política usaba una referencia al objeto almacenado. Además, era posible crear grupos de estos objetos (y grupos de grupos) para permitir la reutilización de grupos comunes de objetos en toda la política. Estos fueron avances significativos para una gestión de políticas más eficaz.

Registro centralizado

Un problema extremadamente común con los firewalls es bloquear el tráfico equivocado. Particularmente al colocar un firewall entre dos redes que previamente no estaban segmentadas, lo cual a finales de los 90 era el caso de casi todas las nuevas implementaciones de firewall. El registro centralizado de todos los logs del firewall, que además era fácil de consultar, hacía que el diagnóstico de errores de política fuera muy evidente y comparativamente sencillo. Un usuario podía reportar un problema, proporcionar una combinación de IP de origen / IP de destino, y un administrador podía encontrar el log de “drop” en el visor de logs y la regla asociada que causó el descarte (o, alternativamente, encontrar un log de “accept” y decirle al usuario que estaba equivocado). Los errores eran, y siguen siendo, comunes en la administración de políticas de firewall, por lo que la facilidad de resolución de problemas era un valor agregado clave para cualquier plataforma de firewall.

Gestión multidominio y OPSEC

A principios de los 2000, Check Point redobló la apuesta por el poder de la gestión al introducir la gestión multidominio con Provider-1 y las API de integración con OPSEC. Ambas fueron una apuesta significativa por el poder de la gestión para diferenciar a Check Point de otros competidores de firewalls, y funcionó. Provider-1, como su nombre lo sugiere, estaba dirigido a la comunidad de proveedores, telecomunicaciones y proveedores de servicios administrados. Si bien los proveedores fueron los primeros en adoptar la tecnología, las empresas rápidamente encontraron razones para ser también consumidoras del producto. Capacidades clave como el control de permisos, el rendimiento de la gestión y de la interfaz mediante la división de políticas y bases de datos de objetos grandes, y las reglas globales que podían aplicarse y ejecutarse de forma global fueron todas características clave deseadas por las grandes empresas. En gran medida, estas eran limitaciones de la plataforma de gestión estándar. Si bien algunos podrían argumentar que Check Point debió corregir la plataforma de gestión en lugar de exigir a los clientes pagar un sobreprecio significativo por Provider-1, los clientes vieron los beneficios y estuvieron dispuestos a pagar por estas capacidades avanzadas de gestión. OPSEC fue un programa de socios y un conjunto de API publicados por Check Point para fomentar la integración de productos de terceros. Entre los primeros éxitos se incluyeron productos de reportes que usaban la Log Export API (LEA), productos de filtrado de URL que usaban el URL Filtering Protocol (UFP) y productos de gestión, como FireMon, que usaban la Check Point Management Interface (CPMI). El programa y las integraciones fueron un gran éxito. Hoy hay bastante más de 100 socios de OPSEC que ofrecen alguna capacidad de integración con la plataforma. Este ecosistema de productos de seguridad brinda a los clientes valor adicional y confianza en su inversión. Hoy damos por sentadas las integraciones por API, pero en 2001, al momento del lanzamiento de OPSEC, esto no era ni de cerca tan común.

Cisco y la CLI eran un actor dominante

El mercado no estaba completamente dominado por Check Point y la interfaz gráfica. Si bien Check Point se estableció como líder en el mercado de firewalls con una interfaz gráfica potente y fácil de usar, Cisco se mantuvo fiel a sus raíces con una interfaz de línea de comandos (CLI) en el Pix. El Pix fue un competidor anterior en el mercado de firewalls, que se remonta a 1994 y fue adquirido por Cisco en 1995. La familiaridad de los administradores de red con Cisco y la CLI hizo del Pix la opción preferida cuando el equipo de redes era responsable de la seguridad. Check Point iría reduciendo esta ventaja con sus funciones de seguridad y su interfaz gráfica, impulsado por un lento cambio en la estructura organizativa empresarial, en el que la seguridad pasaría a ser un grupo separado del equipo de redes. A medida que ocurrió este cambio, la relación existente de Cisco con el equipo de redes fue perdiendo peso en la selección del proveedor de firewall. Las capacidades de gestión mejoradas ayudaron a consolidar la posición de Check Point en el mercado y reforzaron el valor de la gestión para los productos de seguridad. Pero, así como el rendimiento ayudó a Check Point a vencer al proxy en los 90, en los años siguientes el rendimiento volvería a ser un criterio de decisión clave, y esta vez Check Point se vería amenazado. Parte 3: El rendimiento toma protagonismo