Recuento.

Llegaron las épocas navideñas y de año nuevo. Época preferida por muchos para reflexionar sobre el pasado y el futuro. ¿Sobre qué podrían meditar los encargados de la seguridad de la información desde el punto de vista laboral? Sin querer ser pretencioso ni soberbio, aquí enlisto algunos puntos incompletos a considerar y ver si los propósitos laborales 2011 se pueden ver influenciados por nuestras reflexiones y mejorar cómo nos ven y cómo vemos a los demás.

Habilitadores. A los profesionales de seguridad nos encanta decir “No”. A pesar de escuchar que debemos de ser habilitadores, seguimos diciendo “No” ante peticiones de una nueva red inalámbrica o el uso de una iPad para el trabajo. Cuando escuchamos que la razón de ser de una empresa no es la seguridad y que ésta apoya al negocio, parece que asentamos con la cabeza pero no logramos entender su significado.

La seguridad está para que el negocio haga lo que estime que es competitivo o necesario y la seguridad está para proteger ese iPad, ese nuevo sitio e-commerce o esos discos de estado sólido que el negocio considera importante tener.

FUD. En inglés significa “Fear, Uncertainty and Doubt”. En seguridad odiamos el FUD (al menos yo sí), pero a veces lo usamos hasta sin darnos cuenta. Cada segundo martes del mes exigimos que “x” parches sean aplicados inmediatamente que porque “ve cómo Microsoft los cataloga como muy críticos”. Claro, se nos olvida el firewall personal que tenemos y otros controles que mitigan ese riesgo.

O leemos “eso del Stuxnet” y mandamos bloquear todos los USB porque “mira lo que le hicieron a una planta nuclear”. Claro, se nos olvida que con bloquear la ejecución de cualquier archivo desde las USB y otro par de controles se puede mitigar el riesgo y seguir usando los USB.

Si no queremos al FUD, tampoco lo promovamos.

Binarios. “Si quieres dar protección a ese viejo Windows 2000 es necesario ponerle antivirus. No hay de otra. Lástima que no tenga suficiente espacio en memoria”. A veces nos cuesta trabajo encontrar opciones para proteger un bien y si no tiene antivirus está sin seguridad, así de sencillo. Si no está protegido con AES de 256 bits, simplemente no está protegido. Ante una justificación razonable, debemos de pensar en opciones viables de protección, en diversos niveles que ofrezcan ambientes seguros. Los controles compensatorios existen y hay que incorporarlos cuando damos opciones. Hay que ofrecer de dulce, chile, mole, pollo y puerco, por así decirlo.

Dóciles. Algunos otros son dóciles ante “la alta dirección” y se pasan de “habilitadores” porque aunque al inicio pueden decir “no”, fácilmente dicen “sí” cuando se les presiona un poco o de plano dicen “sí” a todo. Si eres el encargado de una planta nuclear y ves que tus sistemas se infectan por USB, es factible que te puedan atacar por esa vía. Si lo dices y no te hacen caso, vuélvelo a decir y esta vez trae armada una demo para que ese riesgo no sólo lo vean en PowerPoint, sino en vivo y directo. Una hack-demo vale más que mil slides.

Congruentes. ¿Hacemos lo que decimos? Como encargados de la seguridad en una empresa, en casa tenemos nuestro antivirus desactualizado? ¿Tenemos WEP en el ruteador? ¿En nuestra laptop contamos con Adobe Reader versión 8 y la última vez que aplicamos parches al SO fue hace 4 meses?

Hay que ser congruentes y si por ejemplo das consejos de cómo navegar de manera segura, tú mismo sigue ese mismo consejo, es lo menos que podemos hacer.

80-20. El 20% de tus actividades harán más por incrementar la seguridad de la empresa que el otro 80%. Los profesionales de seguridad no dirigen todos sus esfuerzos a proteger la información. Hay “n” actividades que quitan ese tiempo valioso.

Realiza un ejercicio de una semana y ve cuántas horas le dedicas a actividades que realmente estén encaminadas en un 100% a aumentar el nivel de la seguridad de un aspecto de la organización. Te sorprenderás. Trata de incrementar ese tiempo y que éste sea lo más efectivo posible.

Conclusiones.

No sólo de bebida y comida está hecha esta época. Si estás metido en esto de la “seguridad de la información” espero que alguna de estas reflexiones te haya hecho “click”; y si no fue así, piensa en otros puntos importantes: siempre es posible mejorar.

Si no estás metido en esto de la seguridad, bien te puede ayudar para entender un poco mejor algunos de los problemas y atascos a los que se enfrentan “esos de seguridad”.

Punto y aparte. ¿Mi mensaje navideño-año nuevo? Reflexiona sobre lo que personalmente lograste y lo que deseas para este 2011.

No te pongas propósitos banales o efímeros y no te llenes de “n” propósitos. Es mejor un par que sepas que son importantes y que puedes cumplir a lo largo de todo el 2011.

Yo te puedo colmar de buenos deseos, pero el o la que va a hacer posible eso que tanto deseas eres tú mismo, nadie más. Yo te puedo desear salud, felicidad y dinero; pero quien tiene que ejercitarse para tener salud eres tú; quien tiene que llevarse mejor con la familia y vecinos no soy yo; y quien debe de tener un plan de acción para conseguir más dinero serás tú mismo. Así es que mi deseo para ti es que desees cumplir tus anhelos y que tomes acción…como dicen por ahí: “a darle”.

Wiki wiki.

Si nunca habías escuchado hablar de los Wikileaks, seguramente esta semana te enteraste o si ya sabías más o menos del tema, probablemente incrementaste lo que sabías al respecto.

El sitio de Internet de los wikileaks es una herramienta para publicar información confidencial y su postura, básicamente, es la del libre acceso a la información. De ahí que reciben datos, los analizan y posteriormente se decide si es publicada. Por otro lado están los que piensan que publicar cierta información clasificada o importante es riesgoso por las implicaciones que conlleva.

Si estás a favor de los wikileaks, tal vez no te guste lo que voy a decir. La idea romántica, “cool” y rebelde del libre acceso a toda la información es como la idea de relacionar a los crackers con “héroes” y ese pensamiento de “quisiera ser como ellos”. Mi trabajo es resguardar lo mejor posible la información, por lo tanto, sería incongruente respaldar eso del “libre acceso a la información” o a los propios wikileaks. Las áreas de seguridad de la información precisamente tratan de evitar que ésta pierda su confidencialidad (entre otras cuestiones) y ello implica que no toda la información es pública sino que tiene niveles de clasificación dentro de una organización (confidencial, privada, pública, etc.).

Los wikileaks pueden sonar “cool” y buena onda siempre y cuando tu organización no sea la afectada, por así decirlo. Muchos comulgan con la idea de “pelear contra el sistema” porque es “buen plan” estar del lado de los que se rebelan; yo no comulgo con esa idea.

Miren, vean eso del “libre acceso a la información” del lado personal. Imaginen que el señor X pone en Internet varios aspectos de su vida privada. Hackea su Facebook y expone todo lo que han puesto ahí. Saca a la luz pública sus archivos de su computadora y el contenido de sus correos electrónicos, los sitios que visitan y sus números de tarjetas , cuánto ganan, dónde trabajan y la dirección en donde viven. Tal vez no les agrade ver todo esto regado por ahí.

Así como las personas tienen derecho a tener cierto nivel de privacidad, también lo tienen las organizaciones. Esa es mi postura y respeto si tienes otra.

El wikileak es un riesgo particular. No es un bug en un software, no es una mala configuración en un ruteador o firewall y tampoco tiene que ver con que uno use Linux, Windows o Mac. El wikileak explota una debilidad en las personas, quienes se basan en sus creencias o principios para considerar publicar cierta información. Ciertamente, la gente tiene que poder acceder a la información para hacer su trabajo, así es que no importa qué algoritmos de cifrado se usen ni la seguridad del canal de transmisión; en algún momento la información debe estar disponible a ciertas personas y si creen que debe estar en wikileak o similar, harán todo lo posible por extraerla y publicarla.

¿Existen controles para evitar la fuga de información? Vaya que los hay, ahí están por ejemplo los famosos DLP (Data Leak Prevention) que varias empresas estarán gustosas de mostrarles, o bien una solución tipo OpenDLP. Hay otros mecanismos que en conjunto pueden levantar una alerta cuando se extraiga cierto tipo de información (o cierta cantidad) o de plano pueden prevenir el copiado de datos a un medio externo como un disco duro, USB o DVD, entre otros posibles controles administrativos y tecnológicos.

Sí, existen diversos controles que mitigarán el riesgo. Por ahí @Dejan_Kosutic comentaba que el 27001 podría ayudar al “problema” del wikileak. Ciertamente y sin duda, pero como siempre, podremos mitigar el riesgo ya que por más tecnología y procesos administrativos que pongamos, si hay uno o varios individuos en la organización que creen fervientemente que están haciendo un bien a la sociedad al wikileakear, harán esfuerzos considerables para hacerlo (y procurarán realizarlo sin ser detectados). Digamos que con el wikileak, ahora debemos “creer” en el “insider threat” independientemente de las estadísticas a favor y en contra; con uno o un par de “rebeldes” en puestos clave tienes suficiente para “creer” y ponerle atención.

Por otro lado, el wikileak logró tal vez lo que no hicieron los virus, troyanos y rootkits: preocupación por la seguridad de la información (y no pocas veces la preocupación genuina se traduce en dinero para fortalecer dicha seguridad). También logró el entendimiento de aquellos que todavía se preguntan a qué se refiere uno con eso de “los activos de información” y lo de “la información tiene valor para las organizaciones”.

Entonces, para resumir. Los wikileaks tienen para algunos su lado romántico-seductor-rebelde que los hace suspirar. A mí no. En otro sentido, los wikileaks y riesgos similares explotan la postura de las personas y si bien podemos poner tecnología para minimizar ese riesgo, debemos de tener en cuenta otros controles compensatorios (perfiles psicológicos, observación del comportamiento, etc.). Y ya por último, si en tu análisis de riesgos no tienes considerado lo de la “fuga de información”, este sería un buen momento para incorporarlo, no crees?

FireSheep: Yo..Soy Tú

¿Es fácil que yo sea tú? En el mundo online, es posible. Existen técnicas como por ejemplo el clásico robo de usuario y contraseña, o bien, la llamada “session hijacking”, entre otras. En la primera, robo tus credenciales de acceso como por ejemplo las de Facebook (tal vez usando un troyano) y entro tal cual fueras tú. En la segunda, espero que establezcas sesión con Facebook usando tus credenciales y posteriormente robo (secuestro) tu sesión ya establecida (siempre y cuando el servicio en cuestión no mantenga dicha sesión con SSL).

Para yo convertirme en ti en el mundo online, sí debo de picotear varios comandos aquí y allá, tal vez usar Linux y ponerme mis lentes de geek para “comandear”, es decir, teclear comandos en un shell. Todo esto puede sonar complicado para los usuarios “promedio”, pero eso se acabó.

La aparición de FireSheep lo cambió todo; es un complemento (addon) de FireFox. Todos los que hemos usado Firefox hemos utilizado algún addon (de hecho esa es una de las razones para usar este navegador: su amplia gama de addons) como por ejemplo: FastestFox, FireFTP, FireTorrent, YouTube Download o Webmail Notifier por mencionar sólo algunos.

¿Qué hace FireSheep? Pues bien, es un secuestrador de sesiones. Cuando uno entra a LiveMail, Twitter o FaceBook, enviamos nuestras credenciales y se verifica que sean las correctas; de ser así, el servidor manda a nuestro navegador una “cookie” la cual es usada en subsecuentes peticiones para identificar nuestra sesión previamente establecida. De esta manera el servidor de LiveMail sabe que mi navegador es quien al inicio se identificó como “Juanito Smith”.

Varios sitios sólo usan SSL (https) para que uno mande usuario/contraseña por un canal cifrado y posteriormente regresan a http (otros ni al inicio lo usan). Así pues veremos el enlace como por ejemplo: https://twitter.com/sessions. Pero no todos los servicios continúan con SSL habilitado (y ahí está el gran error). Eso hace posible el secuestro de sesión porque la manera subsecuente de identificarse con el servicio es usando la mentada “cookie”, la cual es robada por FireSheep.

Como mencioné, FireSheep es un addon para FireFox: luego de instalarlo, uno le pone “start” y automáticamente empieza a escanear una red abierta en busca de sesiones establecidas para que baste un click y poder entrar al FaceBook, LiveMail o Twitter de alguien más.

Te puede parecer que este FireSheep es “otra herramientita” más de esas que nos gusta a los geeks. Pero precisamente no es para geeks, no hay que comandear. Es poner el addon y apretar “start”. Y por cierto, esto del robo de sesiones no es nada nuevo ni mucho menos, ha existido por varios años ya; la diferencia es ahora la facilidad de uso. Ya “hasta un addon” de Firefox (de esos que son casi casi como “plug and play”) que puede ser usado por cualquiera roba sesiones de manera fácil y sin complicaciones.

FireSheep trae el secuestro de sesiones a las masas. Basta estar en una red inalámbrica abierta como algunas de Starbucks donde no se pide contraseña para unirse a la red. O estar conectado a una red alámbrica (yo hice pruebas en un hub y fueron exitosas). ¿Cómo protegernos? Ahí está la cosa rosa:

a).- Las redes deben de cambiar y usar el protocolo seguro WPA. Así se impide este tipo de ataques (y otros). Actualmente estas redes no usan cifrado (son abiertas al público para que se usen) o usan uno muy chafa llamado WEP; en ambos casos FireSheep es exitoso. Es posible cambiar a WPA y que la contraseña para unirse a dicha red sea pública (así sigue siendo abierta al público pero segura contra robo de sesiones).

b).- Los servicios que usamos deben de ya usar TLS (https) siempre, no sólo al inicio de la sesión. Antes se decía que no se usaba SSL porque requería enviar más datos por la red; ahora con las bandas anchas este argumento se desquebraja. No veo otra razón (válida y que proteja nuestra privacidad) por la cual no usar https todo el tiempo para ciertos servicios, como al usar FaceBook, por ejemplo (la propuesta no es usar https para toda la navegación online). Y sí, esto no depende de nosotros sino de quien ofrece el servicio (Twitter, LiveMail, etc.).

c).- Las dos anteriores son soluciones que no dependen de nosotros. ¿Entonces? Podemos elegir usar Force-TLS, o HTTPS Everywhere, por poner unos ejemplos. O una VPN. De hecho apareció BlackSheep (solución limitada), que es una especie de anti-FireSheep.

d).-No usar redes abiertas para entrar a los servicios que ofrece la web. Y como ven, esta propuesta no es viable ni razonable. Costo-beneficio, le dirían algunos.

Conclusión: no veo a FireSheep como otra herramientita, ojalá y sea un parte-aguas y produzca cambios en los que proveen el servicio y en nuestros hábitos de navegación. De hecho ya produjo un cambio: a raíz de FireSheep, Hotmail estará usando https en todo momento.

A continuación unos screenshots de unas pruebas que hice:

1.- Lo primero es bajar FireSheep de http://codebutler.com/firesheep

2.- El antivirus de Microsoft Essentials detecta el addon recién bajado como algo malicioso. Ok, lo apagamos.

3.- Al querer instalarlo, tal vez Windows proteste diciendo que no lo reconoce. No hay problema, seleccionamos a FireFox como el programa que debe encargarse de abrirlo y listo.

4.- Instalamos el addon, como cualquier otro addon.

5.- Si esta prueba se hace en un hub, podemos saltarnos al paso 6. Si vamos a estar en una red abierta inalámbrica, deberemos de instalar WinPCap si es que usamos Windows.

6.- En firefox, seleccionamos FireSheep del menú Ver->Panel lateral.

7.- Damos start y listo, ya encontró a una víctima.

De la C, la E y la H

CEH. Certified Ethical Hacker. Tomé el curso recientemente. Los que ya lo han tomado, sabrán que se trata de que uno entienda en general las técnicas usadas por “los malos” para penetrar sistemas/redes y poder así lograr sus fines.

La idea es que si no sabes las técnicas de ataque, difícilmente sabrás cómo defenderte. En el curso te dan un “overview” de las fases del hackeo que básicamente son: Reconocimiento, Escaneo, Obtención de accesos (a nivel sistema y/o red), Mantenimiento del acceso y el Borrado de huellas.

Para cada una de las fases te dicen de qué se trata y qué herramientas (aplicaciones) usan “los malos” para completar esa fase. Recordemos que la diferencia entre un hacker y un profesional de seguridad es la intención y los objetivos perseguidos; las herramientas y técnicas son las mismas pero unos las usan para atacar y otros las prueban (sin daño) para entenderlas y poder defenderse.

El curso tiene una duración de 5 días donde se introduce al asistente en el mundo del hackeo, se muestran técnicas y herramientas usando no sólo PowerPoint sino también laboratorios en ambientes controlados para hacer prácticas.

Ahora bien, algunas opiniones respecto al curso:

+ Mil y un herramientas. Lo cierto es que la cantidad de herramientas que el curso pretende que “veas” es considerable y si sigues tal cual lo que indica el curso no acabas de dominar ni una sola. Tal vez esa es la intención, pero caramba, en unas cuantas semanas apenas y recordarás el nombre de los cientos de programas que se pretenden ejecutar y conocer.

+Leyes de EUA. El curso toca el tema de leyes, pero centrado en EUA. Afortunadamente fue breve, ya que en lo particular confieso que me aburren las leyes y en todo caso el material debería de “tropicalizarse” para incluir leyes de otros países.

+Herramientas desactualizadas. No todas las herramientas incluidas en el material del curso fueron “del 2010” o recientes. No puedo decir un porcentaje, pero por ejemplo el libro incluye Smurf que fue un ataque de finales de los noventa, el POD (Ping of Death) que explotaba una debilidad de la pila TCP/IP en varios sistemas existentes en 1996 (al menos esa es la fecha del aviso del CERT). También el material incluye el NetBus que algunos de mis compañeros en la Universidad llegaron a usar para gastarle bromas a otros estudiantes (estoy hablando de 1998-1999). Parecía un desfile retro de viejos ataques que llegué a ver o escuchar cuando estaba estudiando la ingeniería. Algunas otras herramientas son viejitas pero vigentes, como por ejemplo nmap. Conclusión: está bien ver algunos ejemplos pasados de viejos ataques como que para saber “lo que existió”, pero vaya, yo sí le daría una actualizada al material del curso para ponerlo más 2010 y menos noventero (verdad, “wardialing”?).

+Instructor. Qué tanto te guste el curso y qué tanto te hayan quedado ganas de que pudo haber sido un poco mejor depende (en mi opinión) en gran medida del instructor. En mi caso el curso me gustó, David (Twitter @codigoverde) le dio un giro interesante y supo mantener mi atención con técnicas vigentes y herramientas usadas por “los malos” en el 2010 y aún así manteniendo el balance con los puntos importantes del material del curso. Sí se despegó -lo suficiente- del PowerPoint y de lo que decía el “manual” que se tenía que ver en cuestión de herramientas, y gracias al Dios Todopoderoso que lo hizo. Asimismo vimos herramientas a una profundidad adecuada. Es decir, la dinámica impuesta por mi instructor fue determinante para que el curso en general valiera bastante la pena y he de confesar que superó mis expectativas.

+ ¿Ya soy pentester si curso el CEH? En mi opinión, no. Tampoco si te certificas. Si a mí me viene un fulanito a decir que puede hacer un pentest a mi empresa porque tomó el curso y posteriormente se certificó CEH sin más credenciales y/o justificaciones, le diría que no gracias y seguiría buscando. Sólo tomar el curso y/o certificarte no te hace pentester, o al menos uno que haga un buen trabajo. Recordemos que un buen pentester domina a profundidad las técnicas y herramientas de hackeo para que con tu aval, lleve a cabo pruebas de hackeo controladas que muestren tus debilidades para que mejores. En mi opinión, el curso CEH es introductorio y (si aún no las tienes) tendrás que adquirir los conocimientos y técnicas -a profundidad- por otros medios.

+ Certificación vs Utilidad. ¿Quieres tomar el curso para certificarte CEH o para aplicar lo aprendido en tu trabajo? ¿Yo? Para las dos cosas. Aunque sinceramente me interesa más lo aprendido en esos 5 días. Hay varias cosas que me latería incorporar en lo que hago porque aumentará el valor de mi trabajo. ¿Me faltará tiempo para hacerlo? Tal vez, pero habrá que buscarlo e incorporar técnicas de ahorro de tiempo, no?

¿Vale la pena el curso? Yo pienso que sí, opino que vas a aprender y de paso (estudiando) te certificas. Pero insisto de nueva cuenta en que el instructor hace La diferencia.

En fin, ahora empezaré a buscar tiempos para estudiar y hacer el examen de certificación. Ya que lo haga les estaré contando de cómo me fue y cómo es el examen.

Ni te Arriesgues.

¿Tenemos que hacer un análisis de riesgos? Yo más bien diría que debemos de pensar en hacer uno porque obtendremos un beneficio. ¿Por qué no todos tenemos uno? Respuestas: “tedioso”; “no le veo utilidad”; “falta tiempo”; “ni sé por dónde empezar”. ¿Y saben? No los culpo del todo.

De que existen metodologías de análisis de riesgos para la seguridad de la información, existen. Y varias. Magerit, CRAMM (CCTA Risk Analysis and Management Method), 27005 u OCTAVE (Operationally Critical Threat, Asset and Vulnerability Evaluation). Si ustedes siguen alguna de estas metodologías u otra similar, creo que pueden detenerse en este momento y dejar de leer, este post no es para ustedes.

Si no sigues ninguna, tendrás tus razones. Probablemente se te hace complicado, tedioso, consume-tiempo o hasta una pérdida de tiempo.

¿Qué te puedo decir? Para hacer un análisis de riesgos hay que invertir tiempo (y para seguir una metodología necesitarás mucho tiempo e inclusive probablemente dinero en forma de cursos, documentación o hasta honorarios de alguien –yo me apunto- que te “traduzca” lo que la bendita metodología quiere decir). Sin olvidar el hecho de que debes de mantener tu análisis actualizado (es decir, más tiempo). Y luego viene el trabajo posterior al análisis, porque ya que evaluaste tus riesgos, hay que hacer algo al respecto, no? Pero tiene un lado positivo.

El beneficio principal en general -en mi opinión- es que te “obligas” a pensar en las amenazas y vulnerabilidades de los activos; y eso ya es bueno aunque no hayas seguido “esas” dichosas metodologías. Y claro, asumo que posterior al análisis, le darás un tratamiento (es decir, algo harás con ese riesgo). En general, todo lo anterior sería administración del riesgo: analizar-actuar-medir-analizar-actuar, etc.

En fin, si crees que seguir una metodología es complicado y tedioso, te propongo explicarte de qué se trata esto del análisis de riesgos y que está bien hacer “atajos” (adaptaciones de una metodología). Existen maneras de hacer análisis de riesgos fáciles y ágiles que es mejor que no tener nada.

Si eres un purista y fiel seguidor de una o unas de las metodologías “serias” de análisis de riesgos, mejor ni sigas leyendo, me llenarás este post de críticas y malos comentarios porque cualquier cosa que no se apague a CRAMM, 27005 o Magerit te podrá parecer incorrecto.

Empecemos.

¿Qué quieres proteger? Tal vez sea el servicio de correo, la información que pones en tu página web, los registros de tus clientes que guardas en una base de datos o un proceso de facturación.

¿Cuáles son los activos? Es decir, qué cosas son importantes para que se lleve a cabo lo que quieres proteger? ¿Qué “cosas” están involucradas en ese servicio o proceso? Si es el servicio de correo, podría ser la base de datos del Exchange, el Exchange mismo (software), el sistema operativo donde está montado, el servidor (hardware) o hasta el personal que lo administra.

¿Cuáles son las amenazas? Algunas metodologías te dicen que listes tus vulnerabilidades y amenazas de tus activos. Atajo: puedes omitir las vulnerabilidades, asumo que si evalúas amenazas, implícitamente estás tomando en cuenta las vulnerabilidades, así es que basta listar esas amenazas (por ejemplo, el 27005 lista una serie de amenazas que te pueden dar una idea de las que podrías tomar en cuenta y evaluar; es como un checklist y vas viendo si te afectan o no). Supongamos que tu activo es la base de datos del correo. Las amenazas podrían ser que se la roben, que se corrompa, que falle el disco duro. Dale un valor a esa amenaza: “Alto-medio-bajo” o “3-2-1” o bien “Relevante-No relevante”. Asimismo, piensa y enlista si hay alguien (persona/organización) que quisiera hacerte daño y qué es capaz de hacer (sus capacidades); así puedes identificar más amenazas.

¿Cuál es el impacto y la frecuencia? Si se concreta esa amenaza tendrá un impacto, cierto? Y si esa amenaza se da con cierta frecuencia entonces hay que tomarla en cuenta. Para un análisis de riesgos no se puede entender el impacto sin su debida frecuencia. Por ejemplo, la llegada de un meteorito mata-todo sería de impacto alto, sin embargo la frecuencia es baja (no ha pasado desde la extinción de los dinosaurios). ¿Lo ven? El impacto puede ser muy alto pero si la frecuencia o probabilidad de ocurrencia es baja o despreciable, entonces no nos debemos de preocupar tanto o tal vez nada (en este ejemplo, mitigar el riesgo asociado a que un meteorito efectivamente caiga, traería un desbalance en el costo-beneficio por lo cual deberíamos aceptar el riesgo y no mitigarlo, o simplemente no considerar esa amenaza). Pero si el impacto es alto y sucede a cada rato, entonces hay que tomar una acción pronta y efectiva en caso de que no lo hayamos hecho ya. Al igual que la amenaza, dale un valor al impacto y otro a la frecuencia.

Ponlo en una licuadora. Si tomamos en cuenta las amenazas de los activos, sus impactos y frecuencia, obtendremos un riesgo. Tal vez tu riesgo más alto esté asociado a una falla del disco duro y la consecuente pérdida de tu base de datos. Hasta ahí ya tienes tu análisis de riesgos, es decir, tienes enlistados tus riesgos. Ahora tienes que hacer algo con ellos: mitigarlos (por ejemplo con un control administrativo o una aplicación), transferirlos (que un tercero tenga tu base de datos y se encargue de los riesgos), aceptarlos (se vale decidir que entiendes el riesgo pero que por el momento no puedes/quieres hacer algo al respecto) o eliminarlo (recuerden que para eliminar un riesgo se debe de eliminar el activo que lo genera, en este caso, tendríamos que eliminar la base de datos, lo cual es impráctico).

En fin, no traté de establecer una metodología de análisis de riesgos ni mucho menos, sino decirte que es mejor tener algo aunque sea supuestamente incompleto que no tener nada. El análisis de riesgos te obliga a pensar en escenarios de “qué tal si”; te obliga a enlistar amenazas y a evaluar sus impactos y posible frecuencia. Si haces eso ya habrás tomado un paso importante, creo yo. Y no tienes que hacerlo solo, entre más gente esté ayudándote se enriquecerá el análisis de riesgos. Por cierto, recuerda que el resultado del análisis de riesgos es tan bueno como el “input” que le des.

Si mi forma simplista de presentarte lo que es el análisis de riesgos te pareció muy chafa (dame chance, este sólo es un blog), no temas agarrar una metodología “seria” y quitarle todo lo que no consideres relevante; insisto, es mejor que nada. También puedes ver la propuesta del SANS que es bastante práctica, creo yo. Los caballeros templarios te dirán que si no sigues una metodología seria de “pe” a “pa” y 100% apegada entonces no sirve. Ni ellos ni yo tenemos la respuesta, la tienes tú. Así es que ni te arriesgues a no pensar en tus riesgos. Y ahí me dices cómo te fue.

Algunas frases de Bruce Schneier [Beyond Fear, 2003] ligadas al tema:

“Making large changes in response to rare events often doesn’t make sense”.

“An attack is a specific way to attempt to break the security of a system or a component of a system”.

“Many countermeasures are ineffective. Either they do not prevent adverse consequences from the intentional and unwarranted actions of people, or the trade-offs simply aren’t worth it”.

Sandboxeando al Reader.

A inicios de este mes de octubre, Adobe nos dejó ver algunos detalles de lo que va a ser su tecnología sandbox que incorporará en una futura versión de Adobe Reader y que supone un avance en la protección contra las numerosas debilidades que son explotadas en cada nueva versión del Reader.

Una sandbox es una tecnología de seguridad que tiene como fin crear un ambiente virtual donde se ejecuta un programa para evitar en lo posible que se lleven a cabo acciones fuera de lo permitido. Es una “cajita de arena” para que los niños buenos y sobre todo los malos se empujen, se caigan y jueguen luchitas sin que se hagan demasiado daño ya que caerán sobre la suave arena y no podrán dañar el resto del kinder. Es una especie de caja de arena para confinar y limitar las acciones tanto de los “buenos” como de los “malos”.

En Adobe Reader esta funcionalidad también se le conocerá como “Protected Mode” y no sólo prohibirá ciertas acciones abusadas como la instalación, borrado o modificación en el sistema, sino que también “encerrará” al código malicioso que se quiera distribuir vía un archivo PDF sin mencionar que prevendrá la elevación de privilegios en el sistema del usuario.

El sandbox del Reader va a delimitar el “parseo” al leer el archivo PDF y limitará la nefasta característica para ejecutar JavaScript. Se implementará el concepto de un “intermediario” para los procesos que requieran salir del sandbox (así se implementa un control para que no cualquier proceso hijo de vecino haga lo que se le de la gana en el sistema). Finalmente, se incorporarán dos niveles de privilegio: el del usuario y el del PDF; así podremos bajar un archivo de Internet y éste se ejecutará en un contexto de muy bajos privilegios (restringidos) mientras que nosotros seguiremos trabajando con privilegios –normales- de usuario.

El concepto de sandbox no es nuevo. Uno de los más recientes en usarlo fue Chrome. También Java tiene el suyo, por decir unos ejemplos. ¿Es un sandbox “la neta”? No. Pero es un gran avance y para mí será un parte-aguas en lo que a la (in)seguridad que el Reader representa. No es secreto que la sandbox de Java tiene en sí misma debilidades que han sido explotadas en el pasado y por otro lado la seguridad de estas sandbox depende de la seguridad que pueda proveer el sistema operativo (nos quedamos indefensos si nos atacan el sistema operativo para “pagarle” al sandbox).

Más detalles técnicos los pueden encontrar en el blog de Adobe. Lo más importante a recordar es que estén al pendiente de cuando salga esa versión para que privilegien su instalación por la mejora ya expuesta (pueden suscribirse al RSS de seguridad de Adobe o seguir a @vupen que provee este tipo de información).

Sin olvidar que no deben de esperar a futuros sandbox, ya pueden sandboxear varios programas con por ejemplo SandboxIE, ya lo probaron?

StuxNet: Atacando el Mundo Real.

Salen tantos gusanos tan seguido que la mayoría no llegan a ser noticia fuera de algunos foros de seguridad, pero algunos llegan a los titulares por su peligrosidad. StuxNet es uno de ellos.

Hace unos cuatro meses, se descubrió la existencia de StuxNet, un gusano muy peculiar. Su objetivo no es tan “mundano” como el malware actual orientado a robar dinero de las víctimas. StuxNet quiere tomar control de sistemas Siemens tipo industrial llamados SCADA (Supervisory Control and Data Acquisition).

A mí antes de StuxNet no me decía nada eso de SCADA, así es que seamos más específicos. Todo apunta aparentemente a que el gusano StuxNet quería dañar plantas nucleares donde se usa SCADA. Más específico: la planta nuclear de Irán llamada Bushehr.

Ok. Ahora vayamos a unos cuantos detalles técnicos. El funcionamiento de StuxNet es complejo, tanto, que se ha manejado que un gobierno podría estar detrás de la creación de este gusano. Explotó en su momento tres debilidades de día cero de Windows (sin solución) y una debilidad zero-day del software SIMATIC de Siemens. Se propaga por ejemplo vía USB o recursos compartidos (network shares), contiene tecnología rootkit y usa certificados digitales -que al parecer fueron robados sólo para este propósito- para instalar sus propios drivers dentro de Windows. Tiene un tamaño de 1.5 MB, muy inusual para un gusano, lo cual –en este caso- significa que es altamente complejo.

StuxNet está diseñado para pegarle a sistemas industriales, por lo que se sospecha que el o los creadores del gusano saben manejar estos sistemas SCADA de Siemens y entienden su funcionamiento (por ejemplo aprovecharon una contraseña de SCADA que no se puede cambiar –hard coded-); de hecho es probable que hayan tenido acceso a un sistema industrial de “pruebas” donde hayan ensayado su “creación” para corregir posibles fallas o verificar el buen funcionamiento del bicho. Por otro lado, desgraciadamente, StuxNet también infecta equipos Windows de compañías y usuarios (esto último yo lo veo como un error del creador ya que un objetivo de este tipo de malware es permanecer en el anonimato); sin embargo no hay una aparente afectación (McAfee lo cataloga con criticidad Low) salvo que tu sistema estuviera controlando una planta nuclear.

Hay muchos más detalles técnicos en la red que no estaremos analizando aquí, como los de Symantec o el FAQ de FSecure, sin olvidar el de McAfee. Ya hasta hay video en YouTube donde se hace una pequeña demostración de las capacidades de StuxNet.

¿Qué significa StuxNet? Que tal vez no sea el primero de su tipo pero sí es el primero de su clase que se descubre y discute públicamente. Otra característica es que se aprovecha el software para “brincar” al mundo físico: un pedazo de código con el potencial de manipular los controles de una planta nuclear. No estamos hablando del robo del usuario/contraseña para entrar a la banca en línea ni de un Blaster que reinicia equipos; estamos hablando de plantas nucleares que por cierto se controlan con software (de Siemens u otros). ¿Sí ven la relación software-bug-gusano-planta nuclear?

No por nada la OTAN ha tomado recientemente cartas en el asunto: “Pero además de los ataques militares, Rasmussen menciona otras amenazas que podrían motivar la defensa en conjunto. Entre estas amenazas se habla de los ataques cibernéticos a los sistemas informáticos de los países miembro de la OTAN”.

StuxNet es un ejemplo de lo que se podría llegar a hacer. No sabemos de un impacto que de hecho haya logrado llevar a cabo (no se ha “volado” ninguna planta nuclear recientemente, cierto?), no sabemos quién lo creó ni quién es a ciencia cierta el objetivo de StuxNet; Siemens ha comentado que lo detectó en 15 clientes de SCADA y a nivel mundial se estima que 45,000 equipos Windows se infectaron (recordemos que estos últimos no son el objetivo de StuxNet).

Inclusive en algunos sitios se ha calificado a StuxNet como un arma. ¿Era el objetivo de StuxNet volar la planta nuclear de Irán? ¿Tenía otros objetivos? ¿Los cumplió? ¿Quién está detrás de StuxNet: EUA, Israel o algún país árabe tal vez? ¿Qué sucedió con la noticia de que arrestaron a algunas personas en Irán involucradas con StuxNet?

¿Es posible destruir una planta nuclear, dañar instalaciones eléctricas, manipular compuertas de una presa o impedir el flujo de agua potable con un malware programado para lograrlo? La respuesta es que es posible hacer todo lo que el software a cargo de estas plantas y sistemas de infraestructura puedan hacer. Si los sistemas de una planta nuclear no la pueden llevar al límite, tampoco lo podrá hacer un gusano (a menos, claro, que el gusano aprovechara un error o debilidad en el sistema de control que lo obligara a llevar a cabo acciones no previstas…pero bueno, dejémoslo hasta aquí).

Se cree que StuxNet empezó a operar desde el año pasado. ¿Cuántos otros malware de este tipo andan por ahí ahora o anduvieron antes de StuxNet? Lo que sí puedo decir es que veremos noticias de software bélico en el futuro que causará más que robo de dinero o inconveniencias. Desgraciadamente, esto no se ha acabado y a penas inicia dado que cada vez más software controla sistemas e infraestructura crítica y que –mucha de- la gente a cargo de ello no hace lo suficiente para controlar ese riesgo (se cree que StuxNet entró a la planta de Irán vía USB: ¿no pudieron prohibir estos dispositivos sabiendo que son un claro vector de ataque informático? ¿y si decidieron tener Windows, no lo pudieron endurecer? Por favor).

En Casa del Herrero: Azadón de Palo

¿Pensaba desgarrarme las vestiduras y poner el grito en el cielo? Nada constructivo; así es que mejor tratar de verlo con el cristal de “lecciones aprendidas”, no vaya a ser que un día hasta a mí me pase, cierto?

Tenemos al US-CERT, cuyo About us dice que: “is charged with providing response support and defense against cyber attacks for the Federal Civil Executive Branch”. Uno esperaría que este US-CERT fuera “punta de lanza” en cuestiones de seguridad que por cierto, forma parte del Department of Homeland Security.

Recientemente le hicieron una revisión a sus sistemas. Encontraron “202 huecos de seguridad críticos” debido a falta de parches (el 93% de estos huecos estaban en las aplicaciones y el restante fueron parches del sistema operativo). Ahora ya me entienden el título de “En Casa del Herrero…”: una agencia encargada de proteger pero ella misma está “desprotegida”.

Y pongo desprotegida entre comillas; no sabemos los controles compensatorios existentes o la criticidad de los sistemas involucrados. En fin, les ofrezco las lecciones aprendidas de este caso desde mi punto de vista:

+ Si eres de “los de seguridad”, protégete. El asesor financiero lleno de deudas, el bombero sin extinguidor en casa o la patrulla que se pasa el alto (en otros países, claro). La lección es que si eres de los “de seguridad”, pues debes de servir de ejemplo de lo que “debería de ser”. Aplica las medidas y controles que quieres que los demás apliquen y sigue las políticas de seguridad. Suena obvio pero no siempre es así.

+ Mantenerse actualizado es difícil. Tener la infraestructura al día en cuestión de últimos parches y últimas versiones es un infierno. Nuevas versiones de Adobe Reader y Flash, parches de Windows y Unix, service packs de SQL Server…y la lista se incrementa entre más aplicaciones y operativos se tenga. Inclusive algunas aplicaciones se dedican a parchar con el fin de automatizar esta actividad; ciertamente es una ayuda pero igual habrá ventanas de tiempo con des-actualizaciones y sistemas críticos en donde se deba de actualizar a mano y de manera pausada, entre otros “detallitos”.

+ Auto-hackéate. Pentest para jugar el papel del hacker y tratar de penetrar redes y/o sistemas. Lo anterior con el fin de evaluar el nivel de protección y tapar nosotros mismos los huecos de seguridad para evitar un “quemón” externo.

+ Fácil de atacar, difícil defender. Resultaría muy fácil criticar al US-CERT. “Pues qué brutos”, dirán algunos. Sin embargo, estar del otro lado viendo la manera de entrar en una red o sistema es “sencillo”: hay que encontrar un solo eslabón débil. Estar de este lado protegiendo resulta más complicado de lo que parece. En ciertas zonas de provincia donde abundan las hormigas, ¿han tratado de mantener un tarro de miel abierto y “sellar” la casa para evitar que entren hormigas e infesten la miel? Para entrar, una hormiga requiere de un descuido (una puerta abierta), un pequeño orificio no detectado o entrar colgada de la ropa de una persona. La hormiga es el hacker, la miel tu información. Sin hablar de esas “hormigas internas” que pensamos nunca se atreverían a tocar la miel. La lección es no bajar la guardia, dejar de pensar que somos invulnerables y sí tener una sana dosis de paranoia.

+ Bienvenidos los Controles Compensatorios. Existe un riesgo por tener aplicaciones des-actualizadas. Lo mejor sería mantenerlas actualizadas (lo cual no es fácil). Ok. Dadas las circunstancias, ponemos un control compensatorio, por ejemplo usando unos IPS personales o herramientas como SandboxIE. Este es sólo un ejemplo de cómo podemos mitigar riesgos con controles compensatorios que precisamente hacen eso: compensan la pata coja.

+ Administración del riesgo. “Oh! Mira cuántos parches faltan, es un desastre! ¡Cómo es posible! ¡No, no, no!”. Si nos ponemos a gritar “catástrofe” sin siquiera saber qué tipo de debilidades se encontraron, en dónde se encontraron y el impacto real entonces no estamos administrando riesgos y en cambio sí nos estamos orientado al “peor de los escenarios”. Sobre todo en cuestión de nuevas versiones en aplicaciones y parches faltantes en sistemas operativos, quiero ver quién tiene su infraestructura actualizada al 100% y que sostenga ese estado. Para administrar el riesgo de seguridad en las TI, hay que entenderlo, y para entenderlo, lo que se llama entenderlo, no sólo hay que saber cómo funcionan las TI sino (también) cómo un atacante puede ir más allá de las limitaciones impuestas por estas tecnologías.

Tomando el Control de tu Automóvil

¿Qué nos viene a la mente cuando pensamos en autos? Una hermosa carrocería con un color llamativo, llantas con rines vistosos y un motor que ruge cuando apenas pisamos el acelerador. Creo que a nadie nos cruza la idea de computadoras, sensores y procesadores, cierto?

Los viejos tiempos. El Modelo T, creado por Henry Ford, era puramente mecánico, cero computadoras. Nada de circuitos, sólo motor. Hasta autos como por ejemplo los vochos todavía son autos autos y tienes que saber solamente cómo arreglar un motor para ponerlo en marcha de nuevo. Una banda por aquí, una bujía por allá, un distribuidor y volilá!

Hoy todo ha cambiado. La vida de la mayoría de los autos de reciente fabricación es regida por las nuevas tecnologías. Este mismo año tuve problemas con mi auto. Fue “la computadora”. Todo empezó con la falla del tacómetro para terminar con jaloneos inexplicables al acelerar. “Son las bujías güero”, me llegaron a decir; y yo feliz porque el costo de reposición era muy razonable. Pero no, de hecho resultó ser “la computadora” y me insistieron “Esto es el principio, si no la cambia, pues un día igual y ni prende”. Sí, tuve que cambiar “la computadora”.

En fin. Entremos en materia. Desde el 2008, los autos en EUA deben de traer ya sensores en las llantas para que manden datos de su presión a la ECU del automóvil (Electronic Control Unit). Al estar en constante movimiento, lo más fácil es transmitir esta información inalámbricamente. Y bueno, aquí mismo podríamos acabar este post porque ya sabes cómo acaba la historia.

La información que mandan las llantas viaja sin cifrar, es decir, en claro. La señal se puede recibir hasta a 40 metros de distancia de cada llanta. Cada 90 segundos el sensor de la llanta manda un “ping” al ECU para informar el nivel de la presión.

Estarás pensando “¿Y eso qué?”. Un grupo de investigadores descubrió que puedes enviar información falsa al ECU, sustituyendo la que mandan las llantas. Lo anterior crea una “confusión” del ECU que a su vez “vuelve loco” al tablero que ve el conductor. Es posible “crashear” el ECU y a veces ni con un reboot es suficiente para componerlo.

Lo anterior se logra enviando repetidamente información de “baja presión” o datos de presión fuera del rango lógico.

Otro vector es que si yo sé el ID de los sensores de tus llantas, podría poner rastreadores en ciertas ubicaciones para saber cuando llegas a un lugar (clubes nocturnos, reuniones políticas, etc.).

¿Nos debemos preocupar por los sensores de presión en las llantas? ¿Volver a los caballos? ¿Comprar autos antiguos para no ser hackeados? No, no lo vamos a hacer. El punto que no hay que perder de vista es la incorporación de tecnología en artículos de uso cotidiano -como los autos- sin que muchas veces se tenga en cuenta su seguridad.

Este mismo año se llegaron a demostrar inseguridades en los autos mucho más peligrosas (que esta de la presión de las llantas) donde se llegó a tomar un control real del auto (deshabilitar frenos, acelerar o impedir apagar el motor).

Entre más crezca la incorporación de procesadores y mini redes inalámbricas que transmitan datos en tostadores, refrigeradores y autos, la exposición a diversas inseguridades será mayor con diferentes consecuencias (finalmente, si logran que mi refri reporte falta de queso oaxaca, no va a ser algo que me quite el sueño). Y para variar, en estos casos como en otros, los fabricantes desean que las cosas funcionen, no que sean seguras. El objetivo es que funcione el envío del nivel de presión de las llantas; si eso se cumple, todo mundo feliz. ¿No es verdad?

¿Bug o no bug?

“DLL Hijacking”... alguien había escuchado de este término? Si jamás lo llegaste a escuchar, no te sientas mal, es otro terminajo que nos encanta a los de seguridad. En las últimas semanas de agosto tomó relevancia ya que se descubrieron problemas de DLL hijacking en cierto sistema operativo (adivinen cuál).

Cuando una aplicación, digamos AppX.exe se ejecuta, es probable que haga uso de una DLL. Una DLL es una “librería que contiene código y datos que pueden ser usados por más de un programa a la vez”. En caso de que haga uso de esa librería, nuestra amiga AppX.exe va a buscarla en el mismo directorio donde vive.

Ejemplifiquemos. Si la AppX.exe reside en “c:\program files\AppX\”, entonces ahí mismo va a buscar primero su DLL. Si no la encuentra ahí seguirá un orden preestablecido de búsqueda y se irá a tratar de encontrarla en otras rutas, como la del sistema o la de Windows; lo anterior sucederá a menos que el desarrollador haya especificado una ruta (y que es lo que debería de suceder en un mundo ideal).

Pues bien, ya se imaginan a dónde voy. Si saco a AppX.exe de su entorno natural y la pongo (por ejemplo) en un USB junto con una DLL maliciosa que yo hice, lo que hará AppX.exe es llamar a esa DLL porque ambas están juntas en el mismo directorio y ya no buscará su DLL benigna a donde vivía antes: c:\program files\AppX\.

Espero no haberte confundido más. En fin, Microsoft dice en pocas palabras que ese no es su problema porque los desarrolladores deben de especificar en su codificación una ruta definida donde la aplicación busque su DLL (lo que evitaría este ataque). Tal vez a los codificadores les da flojera o ignoran este peligro y llaman a su DLL (desde las líneas de código) sólo por nombre y sin poner su ruta específica.

Y no se trata de un par de aplicaciones afectadas por ahí, sino que hay toda una lista. Safari, Chrome, Media Player, PowerPoint, Microsoft Movie Maker o Firefox, entre otras. Y sí, hay aplicaciones de Microsoft que se ven afectadas. Así es que ellos mismos hicieron el error de llamar a las DLL por nombre y sin especificar una ruta, chups.

Para no variar y como varios ataques populares, este DLL hijacking ya tiene video-demo. El usuario abre una presentación PowerPoint y cuando lo hace, zas! Acabó todo para la víctima. Como ven, se necesita participación del usuario. Pero vaya, digamos que los usuarios en general son muy cooperativos, cierto?

¿Bug o no bug? Por diseño se permite llamar a una DLL por nombre (supongo que para facilitar la vida y no tener que poner una ruta cada vez que se llama a una DLL), así es que es una vulnerabilidad o una simple funcionalidad abusada inteligentemente?

Debido a este DLL hijacking no se va a acabar el mundo ni se van a crear gusanos apocalípticos como Blaster. Me llamó la atención desde el inicio y quería comentarlo aquí porque es un ejemplo de una semi-vulnerabilidad que está en el limbo debido a que no hay contundencia en que sea una debilidad o una característica de la cual se ha abusado.

Aunque si un atacante puede realizar un ataque aprovechándose de esta “funcionalidad”, pues que no es...mmhh...una vulnerabilidad?

Tendencias en Seguridad.

Las áreas de seguridad tienden a transformarse. Empezarán a diluirse y entretejerse cada vez más en otras áreas organizacionales de TI. En el futuro cercano, en las corporaciones ya no deberá de haber un área de seguridad informática como se concibe hoy, sino que las funciones de seguridad estarán bajo la responsabilidad de diversas áreas de TI.

Dentro de una empresa, el área de desarrollo será responsable de codificar software no sólo funcional sino seguro y tendrá uno o más codificadores capacitados para desarrollar con seguridad. La Oficina de Redes también ya no sólo será responsable de la operación de las redes, sino de su seguridad, por sí sola esta Oficina tendrá un par de ingenieros capacitados en seguridad que propondrán productos de protección, revisarán su buen funcionamiento y estarán al tanto de las tendencias en ataques y controles que los mitiguen.

Los administradores de servidores o bases de datos ya no andarán sólo atendiendo que “la operación” prevalezca, sino que también estarán a cargo de la seguridad de los servicios que residen en sus servidores y de los servidores mismos.

Las áreas de seguridad informática tienden a transformarse y especializarse en ciertos temas “avanzados” de seguridad y en entender las tecnologías para poder atender los riesgos a los que se enfrentan. Las funciones operativas de seguridad tienden a absorberse. Los productos de seguridad tienden a ser administrados ya no por esos de “Seguridad”, sino por cada área administrativa.

¿Antivirus? Para los de Servicios de Sistemas Operativos. ¿Firewall perimetral? Para Redes. ¿Antispam? Para los encargados del Correo. ¿Filtrado de contenido y/o DLP? Redes también (bueno, hablemos de DLP cuando madure un poco más).

El área de seguridad cambiaría su nombre a algo así como “Protección de la Información” o “Administración de Riesgos de la Información”, probablemente con funciones de análisis de riesgos informáticos y de la información, auditorías de seguridad (incluyendo revisión de configuraciones) y pentest. Así lo veo (y algunas de estas ideas de hecho las empecé a escuchar de @ElProfeSeguro). ¿En todas las corporaciones? Estimo que por la naturaleza del cambio, esto se daría en organizaciones medianas y grandes (si no es que ya se está dando de forma natural).

Lo anterior también se puede ver en la tendencia de incorporar la seguridad en servicios y productos. Google en su servicio de GMail tiene un satisfactorio filtro antispam y control de malware. Microsoft muere de ganas por incorporar su antivirus Security Essentials en Windows y eventualmente lo hará de alguna manera u otra al 100% (por ejemplo, ¿recuerdan la integración del firewall de MSFT en XP-SP2? Ahí van poco a poco, no?). Asimismo, Intel acaba de comprar a McAfee. HP a Fortify.

Tiene lógica. Cuando compro un auto, no quiero comprarle por separado dos bolsas de aire, cinco cinturones de seguridad, un sistema ABS o una alarma. Hoy en día estas protecciones vienen incorporadas en muchos de los autos nuevos, y así debería de ser. La seguridad forma parte de las características del auto, como el sistema de frenos o el eléctrico.

Bueno, eso es todo de este tema. Ahora cambio de dirección y les comparto algunas de mis opiniones respecto a la compra Intel-Mcafee anunciada la semana pasada (que fue la que me dio la idea de este post):

+ Intel pagó un 60% más por acción. Muestra un gran interés y que le ven potencial a McAfee. Osease, ven lana.

+ Intel en su comunicado comentó que la seguridad no es suficiente en dispositivos móviles, ATM o automóviles. Intel, el gran fabricante de chips para las PC, no lo es para el mercado móvil que representa un jugoso futuro. Tal vez quiera ofrecer productos/servicios de seguridad para estas “nuevas” áreas de oportunidad y estar presente ahí.

+ Se ha dicho que de alguna forma se delegarán funciones del software de seguridad (Mcafee) al hardware (chip Intel). No estoy convencido de esto. Tal vez (eso sí) vayan a crear hardware (no forzosamente procesadores) especializado en seguridad que se incorpore en los sistemas de cómputo o móviles. La idea de Intel tal vez sea que la seguridad estará –mejor- en el hardware y no en el software.

+ Se ha dicho que este tipo de adquisiciones afecta la innovación. Yo no ligo poca innovación con grandes corporaciones. Creo que la innovación se da cuando están las bases puestas.

+ Se ha dicho que Intel buscaba especialistas en seguridad para colaborar en los diseños de sus procesadores y que de ahí la compra. No creo que hayan tenido que comprar toda una compañía para conseguir a estos especialistas.

¿Cuál es tu lectura de la compra?

Finalmente, un comentario de Bruce Schneier del 2008: “What we're going to see is consolidation of non-security companies buying security companies. So, remember, if security is going to no longer be an end-user component, companies that do things that are actually useful are going to need to provide security. So, we're seeing Microsoft buying security companies, we're seeing IBM Global Services buy security companies, my company was purchased by BT, another massive global outsourcer. So, that sort of consolidation we are seeing, it's not consolidation of security; it's really the absorption of security into more general IT products and services”.