El eslabón mas débil, rompe la seguridad

Normalmente la seguridad de los sistemas se suele romper por el eslabón más débil de la cadena. Existen unos tópicos que hacen creer que estamos seguros, y que ayudan a facilitar la rotura del eslabón más débil:

  • Tengo un firewall que me protege.
  • Estoy usando SSL en mis aplicaciones web.
  • Mis servidores están actualizados hasta el último parche.
  • Nadie puede ver mis bases de datos.
  • Hace 6 meses pasamos la auditoría de seguridad, ¿para que más?

Bien, como decía esto son algunos tópicos que hacen crear una falsa sensación de seguridad, el eslabón más débil se puede romper. Analicemos la situación:

  • Tengo un Firewall: si necesito un firewall es por que tengo conexión a internet o por que quiero proteger ciertos segmentos de mi red. Hasta aquí está todo correcto, le pongo, lo configuro, contrato a un administrador de Firewall, y ya estoy seguro. Pero claro, que mi red ha de tener tráfico que permita la comunicación, por lo que ciertos puertos han de estar abiertos, a saber, puerto 80 para el tráfico web, puerto 25 y 110 para el mail, ya tengo las puertas abierta al público, eso sin contar con otros protocolos de comunicación.
  • SSL: que mejor forma de proteger los datos de mis aplicaciones que viajar cifrados, así un men in the middle no puede lograr leer y modificar los datos. Ya tengo que añadir otro puerto más, 443, a abrir en mi firewall, y cuando los datos llegan a la aplicación se descifran y viajan entre servidores descifrados, del servidor de aplicaciones al servidor de base de datos, y ¿estoy seguro que los datos no incluyen ataques de SQL Injection o XSS?
  • Los Parches: cuento con mis sistemas operativos y servidores web, aplicaciones y bbdd correctamente parcheados, pero que es lo que ha sucedido al aplicar el parche, me ha actualizado alguna de mis políticas de seguridad, cómo he aplicado estos parches, cuento con un entorno idéntico al de producción en el que hacer pruebas y validar antes de confiar. Y los parches no protegen las aplicaciones propias que se desarrollan por la necesidad de mi negocio, quién me protege estas, un parche puede dejar al descubierto una debilidad de mi aplicación, que tendré que corregir lo más rápido posible.
  • Ver mi base de datos: mi base de datos está correctamente aislada por el firewall y parcheada, ya nadie puede acceder. Realmente para poder afirmar esto, se tendría que cortar hasta el acceso de las aplicaciones a los datos, en ese caso, ¿para qué tener una base de datos y una aplicación si no puedo acceder a los datos? Cualquier vulnerabilidad en mi aplicación permitirá múltiples opciones de acceso a un atacante mediante técnicas de SQLInjection.
  • Pasamos la auditoría: sí, la auditoría la pasamos hace 6 meses, un mes, 15 días ¿qué más da cuando se pasó?. Nuestro negocio sigue avanzando, sigue creciendo y se siguen haciendo cambios. La simple aplicación de un parche o de una actualización de nuestras aplicaciones hacen que la auditoría que pasmos ayer la tengamos que volver a revisar y mantener los checks de las listas de validación.

Y, cuándo estoy seguro de que estoy seguro. Es una pregunta que, por lo menos yo, no me arriesgo a afirmar que estoy siempre seguro. La verdadera seguridad es no bajar la guardia, estar siempre pendiente de las actualizaciones, vigilar constantemente los análisis de tráfico, aplicar herramientas que me ayuden a detectar intrusiones y errores, hacer continuas pruebas a todos mis sistemas, sobre todo a las aplicaciones que genero, mantener el nivel de formación en todos los integrantes de una organización. Si bajo la guardia un solo segundo y me creo que estoy seguro, he roto el eslabón más débil de la cadena que me proteje.

Tampoco nos podemos volver locos aplicando seguridad, y el gasto ha de estar equilibrado a la necesidad real, he aquí el existo del gobierno que se ha de realizar.

Leave a Reply