Permitidme introduciros las 6 peores ideas sobre seguridad informítica. ¿Cuíles son? Son lo opuesto a las buenas ideas. Son el daño cerebral que hace que tu cortafuegos ASIC turbo-stateful y con soporte para introspección de paquetes de 80.000€ sea transparente para los hackers. ¿De dónde vienen estas antí­tesis de las buenas ideas? Surgen de los malogrados intentos de hacer lo imposible que es una forma de decir intentar ignorar la realidad . Estos malogrados intentos son con frecuencia sinceros esfuerzos por parte de gente con buena intención o por compañí­as que no acaban de comprender del todo la situación. Sin embargo, otras veces son una panda de emprendedores con un producto inútil pero muy bonito que venden para ganar dinero rípidamente. En cualquier caso estas ideas estúpidas son la razón fundamental por la que todo el dinero que gastíis en seguridad no va a servir absolutamente para nada a menos que hagamos algo para evitarlo.

Para tu conveniencia he listado las ideas en orden de mís conocidas a menos conocidas. Si puedes evitar caer en la trampa de las tres primeras estís entre la verdadera élite de la seguridad digital.

#1) Permitir por defecto

Esta idea toma distintas formas; es increí­blemente persistente y muy difí­cil de erradicar. ¿Por qué? Porque es muy atractiva. Los sistemas basados en Permitir por defecto son el equivalente en seguridad informítica a las calorí­as vací­as: sabrosas y a la vez engordan.

La forma mís reconocible en que se manifiesta esta idea de Permitir por defecto es en las reglas de los firewalls. En el alba de la seguridad los administradores de redes configuraban una conexión a internet y decidí­an asegurarla cerrando todo el trífico entrante de telnet, rlogin y ftp. El resto del trífico podí­a pasar, de ahí­ viene el nombre de Permitir por defecto . Esta forma de configurar situaba al administrador de redes en una carrera contí­nua contra los hackers. Supongamos que surge una nueva vulnerabilidad en un servicio que no estí bloqueado. Los administradores deben decidir ahora si permitir o denegar el servicio, a lo mejor antes de que sean hackeados. Muchas organizaciones adoptaron Permitir por defecto a prinpicios de los 90 y se autoconvencieron de que estaba bien ya que los hackers nunca se preocuparín de ir a por nosotros . La década de los 90, con el advenimiento de los gusanos de internet deberí­a haber eliminado Permitir por defecto para siempre pero no lo hizo. De hecho, la mayorí­a de las redes de hoy en dí­a todaví­a estín construí­das alrededor de la noción de un núcleo abierto sin segmentos; es decir, Permitir por defecto .

Otro lugar donde surge Permitir por defecto es en cómo tratamos la ejecución de código en nuestros sistemas. La configuración por defecto consiste en permitir ejecutar cualquier programa en tu equipo si pinchas sobre él, excepto si se deniega la ejecución por algún programa como un antivirus o un bloqueador de spyware. Si piensas sobre ello durante un momento te darís cuenta de lo estúpido que suena. En mi equipo ejecuto 15 aplicaciones de forma regular y hay unas 20 o 30 mís instaladas que uso cada 2 meses mís o menos. Todaví­a no entiendo por qué lo sistemas operativos son tan estúpidos que permiten que cualquier virus antiguo o programa de spyware se ejecute sin ni siquiera preguntarme. Esto es Permitir por defecto .

Hace algunos años trabajé en un proyecto que consistí­a en analizar la seguridad de un sitio web como parte de un proyecto de seguridad de banca electrónica. El sistio web tení­a un balanceador de carga delante que era capaz de redirigir trífico a partir de la URL y mi cliente querí­a usar el balanceador de carga para rechazar gusanos y hackers redirigiendo los ataques a una dirección especial. Redirigir los ataques habrí­a significado adoptar la polí­tica de Permitir por defecto (por ejemplo, si no es un ataque conocido déjalo pasar) pero en lugar de ello les convencimos para adoptar una polí­tica opuesta. El balanceador de carga fue configurado para redirigir todo el trífico que no se ajustara a una lista de URLs bien construí­das a un servidor encargado de despachar imígenes y píginas de error 404, que estaba funcionando bajo una configuración muy segura. Naturalmente el sitio web ha pasado el test del paso del tiempo bastante bien.

Un sí­ntoma de que estís ante un caso de Permitir por defecto es cuando te encuentras en una carrera contra las hackers. Eso significa que te has puesto en una situación donde lo que no conoces puede herirte y por lo tanto estarís condenado a mantener el ritmo/estar a la cabeza en esa carrera.

Lo opuesto a Permitir por defecto es Denegar por defecto y realmente es una muy buena idea. Se requiere dedicación, pensar y entender para implementar una polí­tica de Denegar por defecto , por eso se usa tan poco. No es mucho mís difí­cil que Permitir por defecto pero dormirís mucho mís tranquilo.

#2) Cuantificar los males

En los inicios de la informítica sólo habí­a un reducido número de agujeros de seguridad ampliamente conocidos. Esto tuvo mucho ver con que proliferase la idea de Permitir por Defecto ya que cuando solamente habí­a 15 formas conocidas de hackear una red era posible examinar y plantearse sobre cada una de esos ataques y bloquearlos. De esta manera, los especialistas en seguridad cogieron el habito de cuantificar los males , es decir, listar todas las posibles causas de ataques que conocí­an. Una vez que las listabas podí­as poner sensores para detectarlos o defensas para detenerlos.

¿Por qué Cuantificar el mal es una mala idea? Es una mala idea porque en algún momento de 1992 la cantidad de Maldad en Internet comenzó a sobrepasar con un amplio margen la cantidad de Bondad. Por cada programa inofensivo y legí­timo hay docenas o cientos de software intrusivo, gusanos, exploits o código viral. Con echarle un vistazo a un antivirus actual os daréis cuenta de que hay cerca de 75000+ virus que pueden infectar vuestros equipos. Compara esto con los aproximadamente 30 programas legí­timos que puedas tener instalados en tu equipo y te darís cuenta de la mala idea que es tratar de seguir 75000 piezas de Maldad cuando incluso una persona de pocas miras puede gestionar 30 piezas de Bondad. De hecho, si fuesemos capaces de hacer funcionar únicamente los 30 programas habituales y bloquear todo lo demís habrí­amos eliminado simultíneamente los siguientes problemas:

• Spyware

• Virus

• Troyanos

• Exploits que necesiten tener código preinstalado que no uses habitualmente

Gracias a todo el marketing que hay detrís de los anuncios y de cómo hacerlos hay (de acuerdo a algunos analistas de la industria) cerca de 200 a 700 nuevas maldades en Internet cada mes. Cuantificar el Mal no solo es una mala idea, es que ademís se ha vuelto mís estúpida durante el tiempo que habéis estado leyendo este artí­culo.

Si discutiese esta idea con el tí­pico ejecutivo TI se levantarí­a y dirí­a: Eso suena genial pero nuestra red corporativa es realmente compleja. ¡Tener controlado todo el software del que dependemos es algo imposible! ¡Lo que dices suena razonable pero enseguida te das cuenta de lo absurdo que es! A lo cual yo responderí­a: ¿Cómo puedes llamarte a ti mismo/considerarte un Chief Technology Officer si no tienes ni idea de qué estí haciendo tu tecnologí­a? Un CTO no tiene por qué conocer al dedillo todas las aplicaciones que funcionen en su red pero si no tienes una vaga idea de qué estí funcionando es imposible hacer previsiones de capacidad, previsiones para casos de desastre, planificar la seguridad ni virtualmente nada de las cosas que debe hacer un CTO.

En 1994 programé un cortafuegos que necesitaba unas rutinas de anílisis de los registros de sistema para alertar al administrador en caso de que se detectase alguna condición no esperada. La primera versión usaba Cuantificar Maldad (sí­, yo también he sido un estúpido), pero la segunda versión usaba lo que llamé Ignorancia Artificial , un proceso por el cual el cortafuegos eliminaba los registros que sabí­a que no eran interesantes. Si habí­a algo después de desechar lo que sabes que no es interesante entonces seguro que lo que quedaba era interesante. Este planteamiento funcionó extraordinariamente bien y detectamos un elevado número de situaciones operativas interesantes y condiciones y errores que sencillamente no se nos podrí­an haber ocurrido buscar.

Cuantificar el Mal es la idea que hay detrís de un enorme número de productos de seguridad y de sistemas, desde antivirus a sistemas de detección de intrusos, seguridad de aplicaciones y firewalls de inspección detallada de paquetes . Lo que esos programas y dispositivos hacen es outsourcing de tu proceso de saber qué es bueno. En lugar de tomarte el tiempo de hacer una lista con las 30 aplicaciones que necesitas es mís fícil pagar 29,95€ a alguien para que mantenga una lista exhaustiva de todo el mal en el mundo. Excepto que desgraciadamente tu experto en maldad obtendrí otros 29,95€ al año por la lista de antivirus, otros 29,95€ al año por la lista de spyware y te comprarís un firewall personal por 19,95€ que tendrí control sobre las aplicaciones de red. Para cuando hayas terminado de pagar a otras personas para que enumeren todo el software maligno que podrí­a llegar a atacar a tu equipo habrís pagado mís del doble del coste de tu sumamente barato sistema operativo.

Un claro sí­ntoma de que tienes un caso de Cuantificar el Mal es cuando tienes un software o un sistema que necesita actualizaciones de firmas de forma regular o un sistema que deja pasar a un guasno que no ha visto antes. La cura para Cuantificar el Mal es, por supuesto, Enumerar el Bien . Pero por increí­ble que parezca no hay virtualmente ningún soporte en los sistemas operativos para ello. He intentado usar el Control de Ejecución de Programas de Windows XP Pro pero estí orientado a identificar el mal y es por sí­ mismo una implementación estúpida de una idea estúpida.

En un sentido, Cuantificar el Mal es un caso especial tonto de Permitir por Defecto pero es tan común que merecí­a ser mecionada aparte