Historias aterradoras para contar en la red

Con Halloween a la vuelta de la esquina, aquí va una historia de terror real sobre políticas de firewall. (Para mayor efecto, siéntase libre de imaginarla con una voz ronca y aterradora de advertencia… o la de Morgan Freeman, si lo prefiere.)

Como ingeniero de ventas, paso muchos días haciendo demos de nuestros productos y hablando con ingenieros de seguridad, responsables de cumplimiento, gerentes de DevOps y CISOs sobre firewalls y seguridad de red. A veces las historias de quienes están en la trinchera son increíbles y, en ocasiones, francamente aterradoras. Aquí va un relato reciente de un cliente que quitará el sueño a cualquier ingeniero de firewalls.

Escenario:
La empresa había adoptado recientemente una filosofía de “zero trust” y había invertido un tiempo considerable en acercarse a ese objetivo. Durante el último año se concentraron en depurar sus políticas de firewall escribiendo reglas específicas para la necesidad del negocio: nada más, solo las IPs y redes específicas que necesitaban acceso. Estaban avanzando cuando uno de sus ingenieros hizo un descubrimiento espeluznante: una temida regla “Any – Any – Any – Accept” enterrada en medio de la política.

Se apresuraron a averiguar por qué existía esa regla. Con el tiempo descubrieron que un ingeniero de redes junior, simplemente tratando de hacer que algo funcionara, la había creado. Esa única regla anulaba todo el progreso que habían logrado hacia su objetivo de zero trust y exponía la red a un riesgo enorme.

Estaba claro que la regla debía eliminarse. Pero esta regla llevaba en la política —sin ser detectada— al menos 6 meses y sin duda permitía tráfico crítico para el negocio. De hecho, los registros indicaban que era una regla extremadamente activa. Por supuesto, probablemente permitía algo más que tráfico crítico para el negocio: es probable que también estuviera permitiendo tráfico malicioso. Necesitaban remediar el problema rápidamente.

Primero, se reunieron con el personal de redes y trataron de adivinar qué tráfico podría ser, haciendo una lluvia de ideas sobre aplicaciones críticas y tráfico que quienes conocían la red creían que podía estar usando esa regla. Pero al final decidieron que simplemente tenían que armarse de valor, eliminar la regla y ver quién se quejaba.

Así que notificaron el error a los gerentes de todas las unidades de negocio. Con vergüenza, anunciaron que se establecería una “línea directa” con operadores en espera, y finalmente tuvieron que poner a personas a probar todas las funciones críticas del negocio para asegurarse de que sus productos, sus aplicaciones y todo aquello a lo que necesitaran acceso para hacer su trabajo y permitir que sus clientes, socios y proveedores hicieran negocios con ellos solo estuviera caído hasta que pudieran configurar las cosas. Sí, hubo caídas, y sí, estaban preparados para intentar crear nuevas reglas que remediaran los problemas, pero vaya pesadilla.

—

Quizá usted no tenga un escenario de pesadilla como el que acabo de describir, pero FireMon aún puede facilitarle el trabajo ayudándole a depurar sus políticas de firewall. Aquí hay algunas formas en que FireMon podría haber evitado el escenario anterior. Y, si alguna vez descubre una regla excesivamente permisiva y aterradora en su política, revise el punto 6 a continuación para una solución sin complicaciones.

1) Alertas e informes de cumplimiento:
Habríamos notificado de inmediato al equipo si se hubiera activado una regla tan permisiva como esta. Básicamente puede “ajustar el dial” según el nivel de permisividad que desee para las reglas, por ejemplo “Reglas que permiten acceso a más de 60,000 destinos” o “Reglas con orígenes mayores que una red /16”.

2) Alertas de cambios:
Esta regla aparecería en nuestra vista normalizada —sin importar el fabricante del firewall— y se vería claramente que fue agregada. Así que no podría “colarse”. Algunos ingenieros y gerentes reciben automáticamente por correo electrónico informes de cambios de política cada vez que se realiza un cambio, o incluso solo una instantánea de 30 días de todo lo que cambió.

3) Con nuestra herramienta de automatización, FireMon Policy Planner, implementada, la regla riesgosa se habría detenido en seco, antes incluso de ser publicada. Con nuestro “análisis previo al cambio”, la regla se habría identificado y marcado antes de enviarse a producción, sin permitir que pasara por ella ni un solo paquete de tráfico. Por eso a los responsables de cumplimiento les encanta que no solo recomendemos reglas para su creación según la necesidad, sino que, como en un entorno de sandbox, ejecutemos nuestros algoritmos de cumplimiento antes de poder publicar las reglas automáticamente. Algunos clientes adquieren Policy Planner SOLO por esta funcionalidad, y utilizan nuestras APIs para acceder a ella.

4) También con las alertas de cambios, el equipo sabría con certeza quién hizo qué cambios y cuándo. En este caso, dado que se trataba de un ingeniero junior, un gerente o líder podría haber filtrado u ordenado rápidamente los cambios que ese usuario había realizado durante la última semana, o al menos en el mes, para ver qué tipo de cambios había hecho. Esto también es algo que el equipo de cumplimiento podría haber revisado, o incluso el propio usuario.

5) Desde el punto de vista de la documentación, FireMon puede ser la única fuente de verdad para aspectos como “quién solicitó esto, quién es el propietario de la aplicación, cuándo se revisó esta regla por última vez, etc.”. Así, al filtrar y ordenar reglas con su documentación, esto también se habría identificado más rápido.

6) Dejé lo mejor para el final. Si usted tiene una regla excesivamente permisiva —por ejemplo, si sus predecesores tenían una política de creación de reglas distinta, con un estilo más “abierto o flexible” que el suyo—, contamos con una forma sencilla de depurar estas reglas. Mediante el análisis de flujo de tráfico, nuestra herramienta examina todas y cada una de las direcciones IP que pasan por la regla, descomponiendo un any/any/any en flujos específicos. Usted puede exportar esos flujos y crear reglas específicas basadas en ellos.