Enemigos de la seguridad perimetral

fenceDespués de ver los enemigos de los parches, esta vez toca hablar de los enemigos de la seguridad perimetral. En principio, todo apunta a que esto debería de ser una tarea muy sencilla, basada en la regla «sólo se deben de habilitar los permisos que sean necesarios». Sin embargo, con rascar un poco sobre la superficie, es habitual ver grandes errores en la configuración y problemas en la gestión perimetral de las organizaciónes. En esta entrada vamos a comentar los enemigos técnico, estructurales y organizativos que hacen que aparezcan problemas en la seguridad perimetral de las organizaciones. En otras palabras, cómo es posible que se llegue, sin darse cuenta, a situaciones en las que la arquitectura de la red, o la reglas y ACLs implantadas no son correctas desde el punto de vista de la seguridad.

Las prisas. Este es un problema típico de la seguridad en todos los niveles, y por tanto, también de la seguridad perimetral, que produce situaciones como «Esto tiene que salir a producción ya», «Tú abre los puertos para que funcione para ver si es eso y luego ya veremos», «Tú dale usuario y contraseña de la VPN y luego lo gestionamos como toca», etc.

Solución: Debe considerarse la parte de comunicaciones y seguridad perimetral como una parte de cualquier proyecto de implantación.

Falta de especificaciones de accesos externos: El no contemplar los requisitos de seguridad perimetral en el proyecto, desemboca en que cuando ya tienes todo el proyecto desarrollado, y parece que tiene que funcionar, resulta que los servicios y puertos necesarios no están abiertos en el cortafuegos. que abran lo que se necesite los de comunicaciones.

Solución: Exactamente en el caso anterior, las especificaciones de seguridad deben de contemplarse en todas las fases de los proyecto, incluyendo las comunicaciones y la seguridad perimetral.

Desconexión entre desarrolladores/implantadores y los encargados de la seguridad/explotación: Todo el macro proyecto esta diseñado, implementado y probado en el entorno de preproducción y/o pruebas. Pero resulta que los especialistas en las tecnologías de BBDD, servidores de aplicaciones y servidores web no han tenido en cuenta las restricciones de acceso entre la DMZ y la zona interna, o los accesos entre el segmento de ofimática y la DMZ. Esto desemboca en que a) hay que averiguar los permisos, puertos y servicios que hay que abrir en los cortafuegos, b) además hay que hacerlo con prisas, y c) igual nos toca abrir «de patas» todo un segmento para que esa maravillosa aplicación funcione.

Solución: Volvemos a incidir en lo mismo: las especificaciones de seguridad deben de contemplarse en todas las fases de los proyecto, incluyendo las comunicaciones y la seguridad perimetral.

Software no documentado: ¿Qué puertos hay que abrir entre la aplicación java y el servidor de telefonía ese que hay definido ahí? ¿Alguien lo sabe? Conclusión: se empieza poniendo ‘ANY’s en reglas de los cortafuegos, que después de las pruebas y la implantación acaban quedándose como ‘ANY’s, porque por supuesto, no vamos a arriesgarnos a que la aplicación en producción deje de funcionar…

Solución: Hay que definir los accesos de red necesarios para cada aplicativo, y tener esa información previamente a la implantación, por lo que lo mejor será solicitarla y/o buscarla en fases tempranas del desarrollo, para tenerla cuando sea necesaria.

Equipos portátiles/móviles: Cuando hablamos del perímetro, nos estamos refiriendo a lo que nos protege del exterior, normalmente un cortafuegos externo. Pero ¿qué pasa con lo equipos portátiles conectados a la red corporativa mediante Wifis de hoteles, Wifis domésticas, VPNn, o dispositivos extraíbles? En este caso, ¿donde esta el perímetro? No duden que la gran mayoría los últimos incidentes por virus o gusanos han tenido que ver con dispositivos móviles donde el perímetro no está tan definido.

Solución: Los equipos portátiles deben de ser tratados como equipos expuestos al exterior, y dotarlos de medidas adecuadas.

Falta de criterio o de reglas: Es fácil, con el día a día, que las reglas en los cortafuegos no sean coherentes, se repitan, haya objetos repetidos y nomenclaturas diferentes, se contradigan, se den de alta temporalmente para una demo y luego no se eliminen, etc.

Solución: Es necesario que haya políticas y/o procedimientos que definan los grupos de IPs, si se corta la salida o se corta la entrada, qué reglas nunca pueden ponerse en la DMZ (algún día les explicaré mi regla de la mano derecha y la mano izquierda en relación con la gestión de reglas), qué no se puede poner cuando el acceso es desde la red de un proveedor, cuáles son las redes de proveedores, como se nombran los objetos, qué grupos de usuarios hay definidos, etc…

Flujo de aprobación de permisos: Quien aprueba la apertura de determinados permisos en el cortafuegos puede no entender los riesgos que esta asumiendo, ya que puede guiarse por las necesidades de negocio, pero dejar de lado o no entender la parte técnica. El argumento de que el director de la compañía es quien aprueba los permisos por la sencilla razón de que es el director es un indicativo de que muchas cosas están fallando, además de la importancia que el director le da a la seguridad.

Solución: La persona que apruebe las reglas en el cortafuegos debe de estar en sintonía con el equipo de seguridad, ya que además ciertas aperturas de puertos deberán ser también validadas y auditadas previamente por seguridad. Es necesario un perfil que entienda la parte de negocio, activos involucrados, con la parte técnica, protocolos inseguros, redes origen, etc., y si esto no es posible, lo mejor es siempre disponer de una aprobación técnica y otra funcional, que recaiga en personas con funciones, conocimientos y funcionalidades diferentes.

Obviamente, cuantos más servidores, segmentos de red, servidores VPN y cortafuegos, más enemigos y más grandes, pero en cualquier caso, ¡el enemigo hay que conocerlo!