Las 6 peores ideas sobre seguridad informática (I)

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.

(continuará la semana que viene...)

Traducción autorizada del original
www.ranum.com/security/computer_security/editorials/dumb/