Las 6 peores ideas sobre seguridad informtica

www.segu-info.com.ar

Las 6 peores ideas sobre seguridad

informtica
Marcus J. Ranum
http://www.ranum.com/security/computer_security/editorials/dumb/
Traduccin
http://www.laflecha.net/canales/seguridad/articulos/6ideas/
Septiembre de 2005
En el campo de la seguridad salen novedades a menudo; estamos siendo
continuamente bombardeados con nuevos productos y nuevas tecnologas que
suenan muy interesantes y crebles. Cada 2 meses me invitan a una nueva
conferencia sobre seguridad o me piden que escriba una introduccin para un
nuevo libro de seguridad. Y gracias al hecho de que es un asunto de inters
general y un tema importante para los polticos tambin estamos asistiendo a
una oleada de nuevas leyes sobre seguridad digital. En resumen, la seguridad
informtica es un tema candente. Pero por qu aunque gastando tanto dinero
y tiempo todava seguimos teniendo problemas?
Permitidme introduciros las 6 peores ideas sobre seguridad informtica.
Cules son? Son lo opuesto a las buenas ideas. Son el dao cerebral que hace
que tu cortafuegos ASIC turbo-stateful y con soporte para introspeccin de
paquetes de 80.000 sea transparente para los hackers. De dnde vienen
estas anttesis 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 intencin o por compaas que no acaban de comprender del
todo la situacin. Sin embargo, otras veces son una panda de emprendedores
con un producto intil pero muy bonito que venden para ganar dinero
rpidamente. En cualquier caso estas ideas estpidas son la razn
fundamental por la que todo el dinero que gastis 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 ms conocidas a menos
conocidas. Si puedes evitar caer en la trampa de las tres primeras ests entre
la verdadera elite de la seguridad digital.

1. Permitir por defecto

Esta idea toma distintas formas; es increblemente persistente y muy difcil de
erradicar. Por qu? Porque es muy atractiva. Los sistemas basados en
"Permitir por defecto" son el equivalente en seguridad informtica a las
caloras vacas: sabrosas y a la vez engordan.
La forma ms 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 conexin a Internet y decidan
asegurarla cerrando todo el trfico entrante de telnet, rlogin y ftp. El resto
1 de 10

Las 6 peores ideas sobre seguridad informtica

www.segu-info.com.ar

del trfico poda pasar, de ah viene el nombre de "Permitir por defecto". Esta
forma de configurar situaba al administrador de redes en una carrera continua
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 principios de los 90
y se auto-convencieron de que estaba bien ya que "los hackers nunca se
preocuparn de ir a por nosotros". La dcada de los 90, con el advenimiento
de los gusanos de internet debera haber eliminado "Permitir por defecto"
para siempre pero no lo hizo. De hecho, la mayora de las redes de hoy en da
todava estn construidas alrededor de la nocin de un ncleo abierto sin
segmentos; es decir, "Permitir por defecto".
Otro lugar donde surge "Permitir por defecto" es en cmo tratamos la
ejecucin de cdigo en nuestros sistemas. La configuracin por defecto
consiste en permitir ejecutar cualquier programa en tu equipo si pinchas
sobre l, excepto si se deniega la ejecucin por algn programa como un
antivirus o un bloqueador de spyware. Si piensas sobre ello durante un
momento te dars cuenta de lo estpido que suena. En mi equipo ejecuto 15
aplicaciones de forma regular y hay unas 20 o 30 ms instaladas que uso cada
2 meses ms o menos. Todava no entiendo por qu lo sistemas operativos son
tan estpidos que permiten que cualquier virus antiguo o programa de
spyware se ejecute sin ni siquiera preguntarme. Esto es "Permitir por
defecto".
Hace algunos aos trabaj en un proyecto que consista en analizar la
seguridad de un sitio web como parte de un proyecto de seguridad de banca
electrnica. El sistio web tena un balanceador de carga delante que era
capaz de redirigir trfico a partir de la URL y mi cliente quera usar el
balanceador de carga para rechazar gusanos y hackers redirigiendo los
ataques a una direccin especial. Redirigir los ataques habra significado
adoptar la poltica de "Permitir por defecto" (por ejemplo, si no es un ataque
conocido djalo pasar) pero en lugar de ello les convencimos para adoptar una
poltica opuesta. El balanceador de carga fue configurado para redirigir todo
el trfico que no se ajustara a una lista de URLs bien construdas a un servidor
encargado de despachar imgenes y pginas de error 404, que estaba
funcionando bajo una configuracin muy segura. Naturalmente el sitio web ha
pasado el test del paso del tiempo bastante bien.
Un sntoma de que ests 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 situacin donde lo que no conoces puede herirte y por lo tanto estars
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 dedicacin, pensar y entender para
implementar una poltica de "Denegar por defecto", por eso se usa tan poco.
No es mucho ms difcil que "Permitir por defecto" pero dormirs mucho ms
tranquilo.
2 de 10

Las 6 peores ideas sobre seguridad informtica

www.segu-info.com.ar

2. Cuantificar los males

En los inicios de la informtica slo haba un reducido nmero de agujeros de
seguridad ampliamente conocidos. Esto tuvo mucho ver con que proliferase la
idea de "Permitir por Defecto" ya que cuando solamente haba 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 conocan. Una vez que las listabas podas
poner sensores para detectarlos o defensas para detenerlos.

Por qu "Cuantificar el mal" es una mala idea? Es una mala idea porque en
algn 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 legtimo hay docenas o cientos de software intrusivo, gusanos,
exploits o cdigo viral. Con echarle un vistazo a un antivirus actual os daris
cuenta de que hay cerca de 75000+ virus que pueden infectar vuestros
equipos. Compara esto con los aproximadamente 30 programas legtimos que
puedas tener instalados en tu equipo y te dars 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 fusemos capaces de
hacer funcionar nicamente los 30 programas habituales y bloquear todo lo
dems habramos eliminado simultneamente los siguientes problemas:

Spyware
Virus
Troyanos
Exploits que necesiten tener cdigo preinstalado que no uses
habitualmente

Gracias a todo el marketing que hay detrs de los anuncios y de cmo 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 adems se ha vuelto ms estpida durante el tiempo que habis estado
leyendo este artculo.
Si discutiese esta idea con el tpico ejecutivo TI se levantara y dira: "Eso
suena genial pero nuestra red corporativa es realmente compleja. Tener
3 de 10

Las 6 peores ideas sobre seguridad informtica

www.segu-info.com.ar

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 respondera: "Cmo puedes llamarte a ti mismo/considerarte un
Chief Technology Officer si no tienes ni idea de qu est haciendo tu
tecnologa?" 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 firewall que necesitaba unas rutinas de anlisis de los
registros de sistema para alertar al administrador en caso de que se detectase
alguna condicin no esperada. La primera versin usaba "Cuantificar Maldad"
(s, yo tambin he sido un estpido), pero la segunda versin usaba lo que
llam "Ignorancia Artificial", un proceso por el cual el cortafuegos eliminaba
los registros que saba que no eran interesantes. Si haba algo despus 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 nmero de situaciones operativas interesantes y
condiciones y errores que sencillamente no se nos podran haber ocurrido
buscar.
"Cuantificar el Mal" es la idea que hay detrs de un enorme nmero de
productos de seguridad y de sistemas, desde antivirus a sistemas de deteccin
de intrusos, seguridad de aplicaciones y firewalls de "inspeccin 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 ms fcil 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 ao por
la lista de antivirus, otros 29,95 al ao por la lista de spyware y te comprars
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 podra llegar a atacar a tu equipo
habrs pagado ms del doble del coste de tu "sumamente barato" sistema
operativo.
Un claro sntoma 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 increble que parezca no hay virtualmente ningn soporte en los sistemas
operativos para ello. He intentado usar el Control de Ejecucin de Programas
de Windows XP Pro pero est orientado a identificar el mal y es por s mismo
una implementacin estpida de una idea estpida.
En un sentido, "Cuantificar el Mal" es un caso especial tonto de "Permitir por
Defecto" pero es tan comn que mereca ser mencionada aparte.

4 de 10

Las 6 peores ideas sobre seguridad informtica

www.segu-info.com.ar

Hay un viejo dicho que reza: "No puedes hacer una pulsera de seda a partir de
la oreja de una cerda". Es verdad excepto si acabas usando tanta seda para
parchear la oreja de la cerda que la reemplazas completamente.
Desafortunadamente, cuando un software repleto de errores se corrige casi
siempre se corrige aadiendo nuevo cdigo, en lugar de quitar los antiguos
trozos de la oreja de la cerda.

3. Penetrar y parchear
"Penetrar y parchear" es una idea estpida que se podra expresar
perfectamente en el lenguaje de programacin BASIC:
10 GOSUB BUSCAR_AGUJEROS
20 IF AGUJERO_ENCONTRADO = FALSE THEN GOTO 50
30 GOSUB CORREGIR_AGUJERO
40 GOTO 10
50 GOSUB AUTOCONGRATULARSE
60 GOSUB SER_HACKEADO_EVENTUALMENTE
70 GOTO 10
En otras palabras, atacas tu firewall/software/sitioweb/lo que sea desde
fuera, identificas un fallo en l, lo corriges y luego vuelves a buscar. Haciendo
esto no mejoras la calidad del cdigo a largo plazo aunque Direccin pueda
agradecer la aparente brillantez de dicha estrategia a corto plazo. En otras
palabras, el problema con "Penetrar y parchear" es que no hace mejorar la
arquitectura de tu cdigo/implementacin/sistema; por el contrario lo nico
que hace es conseguir que sea ms duro a base de probar y fallar. El artculo
de Richard Fenyman's "Personal Observations on the Reliability of the Space
Shuttle "era lectura obligada para todos los ingenieros de software que he
contratado. Contena ideas bien explicadas y profundizaba acerca de las
expectaciones sobre dependencia del software y cmo se alcanzaba en
sistemas complejos. En resumen, su significado para los programadores es:
"Excepto en el caso de que tu sistema est pensado para ser hackeado no
debera ser hackeable."
"Penetrar y Parchear" est por todas partes y es la idea estpida que lidera la
moda actual (activa desde hace cerca de 10 aos) de anuncio de
vulnerabilidades y actualizaciones a travs de parches. Segn los
"investigadores de vulnerabilidades" estn ayudando a la comunidad
encontrando agujeros de seguridad en el software y estn corrigindolos antes
de que los hackers los encuentren y los exploten. Segn las empresas estn
haciendo lo correcto publicando lo antes posible parches para adelantarse a
los hackers y a sus intentos de explotar dichos agujeros de seguridad. Ambos
grupos estn comportndose de forma estpida ya que si las empresas
estuvieran escribiendo cdigo que estuviese diseado para ser seguro y
dependiente entonces el trabajo de investigacin de vulnerabilidades sera
una tarea tediosa y poco gratificante!
Permteme decirlo de otra forma: si "Penetrar y Parchear" fuera efectivo ya
habramos dejado de encontrar agujeros de seguridad en Internet Explorer a
5 de 10

Las 6 peores ideas sobre seguridad informtica

www.segu-info.com.ar

estas alturas. Cmo ha ido? 2 o 3 vulnerabilidades al mes durante 10 aos? Si

nos fijamos en aplicaciones diseadas para trabajar en Internet podemos ver
que hay un nmero de ellas que continuamente tienen problemas de
seguridad. Y a la vez, tambin hay un nmero de aplicaciones bien pensadas
desde el principio como Qmail, Postfix, etc que han sido diseadas de tal
forma que el nmero de bugs que han aparecido para dichas aplicaciones ha
sido nfimo. La misma lgica se aplica a "tests de penetracin". Conozco redes
que han sido testeadas en busca de agujeros de seguridad y que han sido
hackeadas y hechas trizas rutinariamente. Esto ocurre porque su arquitectura
(o sus prcticas de seguridad) estn tan fundamentalmente equivocado que
ninguna cantidad de parches van a mantener a los hackers fuera. Tan solo
quitan a Direccin y a los auditores de seguridad de encima de los
administradores de redes.
Tambin conozco redes para las que es literalmente intil hacer tests de
penetracin ya que han sido diseadas desde el principio para ser permeables
solo en ciertas direcciones y solo para cierto trfico destinado a unos
servidores especficos configurados a propsito y que ejecutan software
especialmente seguro. Lanzar tests de penetracin para bugs de Apache
contra un servidor que corre bajo un cdigo personalizado en C ejecutado en
una porcin aislada de un sistema embebido es completamente intil. Por
esto, "Penetrar y Parchear" no tiene sentido ya que sabes que o bien vas a
encontrar infinidad de bugs o bien sabes que es imposible encontrar nada
comprensible.
Un claro sntoma de que tienes un caso de "Penetrar y Parchear" es cuando te
das cuenta de que tu sistema es vulnerable al "bug de la semana". Eso quiere
decir que te has puesto en una situacin en la que cada vez que los hackers
inventan un nuevo arma automticamente eres vulnerable. No suena
estpido? Tu software y tus sistemas deberan ser seguros por diseo y
deberan haber sido diseados para controlar fallos desde el principio.

4. Hackear es Guay
Una de las mejoras formas de deshacerse de las cucarachas de tu cocina es
esparcir migas de pan debajo de las encimeras, verdad? No! Es una idea
estpida. Una de las mejores formas de desalentar el hacking en Internet es
darles a los hackers acciones, comprar los libros que escriben sobre exploits,
tomar clases sobre "kung fu de hacking extremo" y pagarles decenas de miles
de euros para hacer "tests de penetracin" contra tus sistemas, verdad? No!
"Hackear es guay" es una idea estpida.
En la poca en la que yo estaba aprendiendo a andar, Donn Parker investig
los aspectos de comportamiento de hackear y la seguridad informtica. Nadie
lo podra decir ms claro que l: "La informtica a distancia libera a los
criminales de su requerimiento histrico de estar prximos a sus crmenes. El
anonimato y la libertad de no enfrentarse directamente a su vctima han
incrementado emocionalmente las posibilidades de cometer un crimen; por
ejemplo, la vctima slo fue un ordenador inanimado, no una persona real ni
una empresa. Las personas tmidas podran volverse criminales. La
6 de 10

Las 6 peores ideas sobre seguridad informtica

www.segu-info.com.ar

proliferacin de sistemas y modos de proceder idnticos y la automatizacin

de los negocios hicieron posible e incrementales las economas de automatizar
crmenes y construir poderosas herramientas criminales y scripts con gran
facilidad."
Oculto en la observacin de Parker est el hecho de que hackear es un
problema social. No es en absoluto un problema tecnolgico. "Las personas
tmidas podran volverse criminales." Internet ha dado un espacio
completamente nuevo a las personalidades poco sociables. La cuarta cosa ms
estpida que los practicantes de seguridad informtica pueden hacer es
alentar a los hackers ponindolos en un pedestal. Los medios de comunicacin
toman parte directamente en esta macabra idea al mostrar a los hackers
como "jvenes genios" o "brillantes tecnlogos" - por supuesto, si eres un
periodista de la CNN, cualquiera que pueda instalar Linux entra dentro de la
categora de "brillante tecnlogo". Me resulta interesante comparar las
reacciones de la sociedad hacia los hackers como "jvenes genios" y contra los
spammers como "artistas de baja categora". En realidad me agrada ver cmo
spammers, phishers y otros farsantes estn adoptando a los hackers y a sus
tcnicas ya que de esta manera se invertir la vista de la sociedad hacia los
hackers mejor que de cualquier otra forma.
Si eres un practicante de seguridad, ensearte a t mismo cmo hackear forma
parte tambin de la estpida idea de "Hackear es Guay". Pinsalo: aprender
cmo usar un montn de exploits y cmo usarlos significa que ests
invirtiendo tiempo en aprender a usar un montn de herramientas y tcnicas
que van a estar desfasadas tan pronto como todo el mundo se haya protegido
contra ese fallo en concreto. Significa que has hecho que una parte de tus
conocimientos sean dependientes de "Penetrar y Parchear" y que vas a tener
que formar parte de una carrera si no quieres que tus conocimientos queden
obsoletos. No sera ms lgico aprender cmo disear sistemas seguros que
estn construidos a prueba de hacks que aprender cmo identificar sistemas
de seguridad estpidos?
Mi prediccin es que la idea de que "Hackear es Guay" estar muerta en los
prximos 10 aos. Me gusta fantasear con la idea de que ser reemplazada por
la idea opuesta "Una Buena Ingeniera es Guay" pero hasta el momento no
tiene visos de ocurrir.
Se puede aplicar "Penetrar y Parchear" tanto a los seres humanos como al
software en forma de educacin de los usuarios. Por encima, la idea de
"educar a los usuarios" no parece estpida: la educacin siempre es buena.
Por otra parte, al igual que con "Penetrar y parchear", si esta idea fuese a
funcionar ya lo habra hecho a estas alturas. Ha habido numerosos e
interesantes estudios que indican que un gran porcentaje de los usuarios
intercambiaran su contrasea por caramelos, y el gusano de Anna Kournikova
nos ha demostrado que prcticamente la mitad de la humanidad pinchara en
cualquier cosa que aparente contener imgenes explcitas de chicas semifamosas. Si planeas adoptar la estrategia "Educar a los usuarios" deberas
prepararte para tener que "parchear" a tus usuarios cada semana. Es estpido.
7 de 10

Las 6 peores ideas sobre seguridad informtica

www.segu-info.com.ar

5. Educar a los usuarios

La verdadera pregunta no es "podemos educar a nuestros usuarios para ser
mejores en el mbito de la seguridad?" sino "por qu tenemos si quiera que
educar a nuestros usuarios?". En cierta manera esto no es ms que un
"Permitir por Defecto" encubierto. Por qu los usuarios tienen permisos para
obtener archivos ejecutables? Por qu esperan los usuarios recibir emails de
bancos en los que no tienen cuentas? La mayor parte de los problemas que se
pueden corregir educando a los usuarios se corregirn a s mismos a lo largo
del tiempo. A medida que una generacin ms joven de trabajadores se
mueve al frente de los puestos de trabajo vienen pre-instalados con un
saludable escepticismo acerca de fraudes e ingeniera social.
Tratar con cosas como los archivos adjuntos y el phishing es otro caso de
"Permitir por Defecto", nuestra idea estpida favorita. Despus de todo, si
ests dejando a todos tus usuarios obtener archivos adjuntos en sus emails
ests "Permitiendo por defecto" cualquier cosa que se les mande. Una idea
ms apropiada podra ser simplemente poner en cuarentena todos los archivos
adjuntos a medida que llegan a la compaa, eliminar todos los ejecutables
directamente y almacenar slo los pocos tipos de archivos que decides que
son aceptables en un servidor donde los usuarios puedan entrar a travs de un
navegador con soporte SSL (requerir una contrasea eliminara una gran
cantidad de mecanismos de propagacin de gusanos de golpe). Hay
herramientas gratuitas como MIMEDefang que pueden ser utilizadas
fcilmente para eliminar archivos adjuntos de emails entrantes, escribirlos a
un directorio por usuario y reemplazar los adjuntos en un email con una url a
la direccin donde se pueda descargar el adjunto. Por qu educar a los
usuarios si puedes clavarle una estaca al problema directamente en el
corazn?
Cuando era CEO de una pequea startup de seguridad informtica no tenamos
administrador de sistemas Windows. Todos los empleados que queran
ejecutar Windows tenan que saber cmo instalarlo y manejarlo ellos mismos
o directamente no les contratbamos. Mi prediccin es que en 10 aos los
usuarios que necesiten ser entrenados estarn fuera del mercado laboral o
que se entrenarn en casa para mantenerse competitivos. Esta misma
prediccin incluye el saber que no hay que abrir archivos adjuntos de
extraos.

6. La accin es mejor que la inaccin

Los ejecutivos de TI parecen estar divididos en 2 categoras: los "adoptadores
tempranos" y los "pausados y pensativos". A lo largo de mi carrera me he dado
cuenta de que un nmero realmente pequeo de los "adoptadores tempranos"
han construido sistemas con xito y seguros para objetivos crticos. Esto es as
porque por alguna razn creen que "la accin es mejor que la inaccin": es
decir, si te encuentras con una nueva tecnologa es mejor instalarla ahora
mismo que esperar, pensar sobre ello, ver lo que les ocurre a otros
8 de 10

Las 6 peores ideas sobre seguridad informtica

www.segu-info.com.ar

adoptadores tempranos y entonces instalarla una vez que ya ha sido puesta a

punto y ha tenido su primera generacin de usuarios experimentados. Conozco
a un ejecutivo TI senior -uno de los pausados y pensativos-, cuyo plan para
instalar soporte wireless a lo largo y ancho de su compaa era "esperar 2 aos
y contratar a una persona que haya hecho una instalacin wireless exitosa
para una compaa ms grande que la nuestra". No solo la tecnologa estar
ms refinada para entonces sino que ser mucho, mucho ms barata. Que
estrategia tan brillante!
Hay un importante corolario a la estpida idea de "la accin es mejor que la
inaccin" y es este:

"A menudo es ms fcil no hacer algo estpido que hacer algo

inteligente."

Sun Tzu no escribi esa frase en "El Arte de la Guerra" pero si le dices a un
ejecutivo TI que lo hizo te tomarn mucho ms en serio. A muchos de mis
clientes les he estado aconsejando: "mantente apartado del outsourcing de
seguridad durante un ao o dos y entonces busca recomendaciones y opiniones
sobre los sangrientos y mutilados supervivientes, si es que queda alguno."
Puedes ver la estpida idea de que "la accin es mejor que la inaccin" a lo
largo y ancho de las redes corporativas y tiende a estar relacionado con
directivos TI que hacen sus decisiones de compra de productos leyendo los
informes de investigacin Gartner y los coloridos folletos publicitarios de las
compaas. Si te encuentras en la cadena de mando de dicho directivo,
sinceramente espero que hayas disfrutado de este artculo porque
probablemente entiendas perfectamente de lo que estoy hablando.
Una til tcnica de kung-fu burocrtico es recordar que si te encuentras
luchando contra un "adaptador temprano" te puedes apoyar en tus
compaeros. Hace varios aos tuve un cliente que estaba planeando gastarse
una importante suma de dinero en una tecnologa sin probarla
operativamente. Recomend extraoficialmente al director de TI al cargo que
enviase a alguien de su equipo a una conferencia relevante donde le fuese
posible encontrar a alguien con experiencia en dicha tecnologa. Recomend
al directivo que su empleado pusiera un mensaje en el boletn de noticias que
dijese:
"Tienes experiencia directa con xyz de la compaa pdq.com? Si es as estoy
autorizado a llevarte a cenar al Hilton si prometes darme toda la informacin
que tengas del funcionamiento del producto. Contctamente, etc."
El director de TI me coment ms tarde que una cena de 200 le evit gastar
ms de 400.000 en un infernal trauma tecnolgico.
Realmente es ms fcil no hacer algo estpido que hacer algo inteligente. La
clave est en que cuando evitas hacer algo estpido te aseguras de que tus
superiores sepan que has navegado a travs de unas arenas particularmente
sucias y de que obtienes el crdito necesario por ser inteligente. No es esta
9 de 10

Las 6 peores ideas sobre seguridad informtica

www.segu-info.com.ar

la mayor expresin del kung-fu profesional? Recibir alabanzas por no hacer

nada!

Estupideces menores
Estas ideas estpidas no merecen el status de "La ms estpida", pero son
suficientemente estpidas como para no mencionarlas, aunque sea de pasada:

"No somos un objetivo" - s, lo sois. Los gusanos no son suficientemente

inteligentes como para darse cuenta de que tu sitioweb/red no es
interesante.
"Todo el mundo estara protegido si utilizasen <sabor-de-seguridad-delmes>" - no, no lo estaran. Los sistemas operativos tienen problemas de
seguridad porque son complejos y la administracin de sistemas no es
un problema que est resuelto. Hasta que alguien consiga resolver el
problema de la administracin de sistemas, cambiar al sabor-del-mes
va a hacer ms mal que bien porque vas a hacer ms difcil que tus
administradores de sistemas ganen una experiencia que slo se gana
con el tiempo.
"No necesitamos un firewall, tenemos una buena seguridad en cada
equipo" - no, no la tienes. Si tu red no es segura cualquier aplicacin
que se comunique a travs de la red es potencialmente un objetivo. 3
palabras: Sistemas de Resolucin de Nombres.
"No necesitamos seguridad en cada equipo, tenemos un buen firewall" no, no la tienes. Si tu firewall deja pasar trfico destinado a los
equipos que hay detrs entonces tienes que preocuparte de la
seguridad individual de esos equipos.
"Llevmoslo a produccin ahora y ya lo aseguraremos ms tarde" - no,
no lo asegurars. Una pregunta ms apropiada sera: "Si no tenemos
tiempo para hacerlo bien ahora, tendremos tiempo para corregirlo una
vez est roto?" Algunas veces, desarrollar un sistema que est
constantemente en reparaciones significa que tendrs que emplear
aos invirtiendo en parchear porque no estuviste dispuesto a dedicar en
primer lugar unos das para hacer un trabajo bien hecho.
"No podemos parar los problemas ocasionales." - s, s que puedes.
Viajaras en lneas areas comerciales si supieses que la industria de la
aviacin tomase este camino con tu vida? No lo creo.

Adis y Buena Suerte

He tratado de mantener el tono ligero y agradable pero mi mensaje va en
serio. La seguridad informtica es un campo que se ha enamorado demasiado
con la moda del momento y ha olvidado el sentido comn. Tu trabajo como
practicante de seguridad informtica es cuestionar - si no directamente
enfrentarte- la sabidura convencional y el status quo. Despus de todo, si la
sabidura popular estuviese funcionando el ritmo de equipos comprometidos
ira disminuyendo, verdad?

10 de 10