En busca de la privacidad... ¿en féisbuc?

Oh, bendita privacidad. Todos tenemos algo que no queremos mostrar a los demás, ya sea por seguridad o por el derecho a guardar secretos. Por eso hace dos meses compré mi control de seguridad más caro: una pantalla protectora para mi laptop, para que los de al lado no vean lo que estoy escribiendo, especialmente en las juntas. Una premisa clásica en seguridad de información es que el control (el mecanismo o instrumento utilizado para minimizar un riesgo de seguridad) no debe ser más caro que el activo que está protegiendo... y la verdad el riesgo de que mi vecino en una junta vea que estoy escribiendo en blogger.com no vale más de los 60 dólares que pagué... ni modo, ahora hay que usarlo, ¿quién me manda a andar encargando a alguien que lo compre en lugar de comprarlo yo?. :-D. En fin, todo sea por conseguir un poco de privacidad.

Hace unos días abrí una cuenta de Facebook (féisbuc), y no precisamente por estar de moda, sino más bien por una característica fundamental del hombre (y también de la mujer, por supuesto) llamada curiosidad. Extrañamente la inauguración de mi nueva y reluciente cuenta de féisbuc coincidió con una serie de artículos en periódicos y noticias televisivas en donde se pone en tela de juicio la seguridad de los sitios que sostienen las llamadas redes sociales (social networks), específicamente mencionando a Facebook, hi5 y MySpace. Ahora el tema de la seguridad y de la privacidad repentinamente son del interés común, y esto no habría sido relevante de no haber ocurrido en México recientemente un secuestro que terminó en tragedia, cuyas investigaciones revelaron que la víctima (antes de serlo) había publicado prácticamente sus detalles de vida en al menos uno de los mencionados sitios. Es bien sabido que en esas redes se muestran no sólo los nombres de los amigos de una persona, sino también sus fotografías, la dirección donde vive, las actividades que tendrá el fin de semana, o los lugares a donde va frecuentemente, pero de eso precisamente se alimenta una red social, ¿o no?

Armado con mi fresquecita cuenta de féisbuc y mi incipiente lista de amigos que tuvieron el honor de aceptarme en su red :-P, me di a la tarea de revisar qué es lo que pudiera representar un riesgo por fuga de información. En realidad es más simple de lo que cuentan, aunque hace falta cierta habilidad (no mucha, por cierto) para interpretar lo que ahí se ve; a fin de cuentas es sólo minería de datos (data mining) y la interpretación depende de otros factores. De entrada, si no estás registrado no ves prácticamente nada, aunque el registro es cuestión de unos cuantos clics, con una validación bastante simple. Una vez dentro, lo que sigue es buscar gente: puede usarse la búsqueda del sitio o a través de los enlaces de amigos de tus amigos, y de los amigos de los amigos de tus amigos...

¡Espera mil milisegundos...! (java.lang.Thread.sleep(1000);) ¿eso quiere decir que cualquier persona puede ver la información que alguien publica en esos sitios? No precisamente. Todo depende de cuánta información revele. Es decir, que al final todo se reduce a que el nivel de exposición está en relación directa con el grado de apertura que cada persona tiene y desea mostrar a otros, conocidos y desconocidos, por iniciativa propia o por pura ignorancia; y es importante aclarar que dichos sitios se protegen, con cláusulas que los eximen de cualquier responsabilidad derivada del uso que hagan los suscriptores del servicio. Realmente no es un problema del servicio en sí, sino de la forma en que la gente hace uso de él.

Para concluir mi investigación, preparé una prueba de concepto para tratar de demostrar que el problema de la divulgación de información es pertinente al individuo, y no necesariamente a la infraestructura de la red social. La prueba consistió en crear una cuenta falsa de féisbuc, asociada a una dirección de correo igualmente falsa, junto con un perfil más falso que un billete de 3 pesos. Obviamente no era yo, sino una identidad que yo inventé (y sí que me vi creativo, créanme). Comencé incorporando a la identidad prima (matemáticamente hablando) una apariencia difícil de resistir, con datos ficticios pero creíbles. La prima comenzó la búsqueda: primero sus "compañeros" de la Universidad, luego otros aleatorios, algunos conocidos (míos) y sus amigos (de mis conocidos). En ese mismo día hubo respuestas: varios incautos aceptaron a la prima sin ningún problema (o les pareció conocida, o de plano les gustó). Ahora, usando la cuenta prima puedo ver los perfiles, las fotografías, el domicilio (con Google Maps y todo) y otros datos personales, gracias a que todavía hay gente que cree en la amistad y en la buena voluntad de las personas (hasta tengo ganas de llorar, "pero tan sólo de mi ojo derecho", como dice Juan Luis Guerra), y que haría cualquier cosa con tal de tener una lista extensa de amigos y ser populares, aunque involuntariamente estén exponiendo incluso a sus familias.

¿Qué hacer, entonces? Por supuesto no hay que tomar la postura radical de no usar esos servicios por miedo a que alguien nos investigue, pues sería equivalente a decir que no saldremos a la calle por temor a sufrir un accidente. Lo importante es ser precavidos y no ser tan confiados. Al menos en féisbuc pude configurar mi cuenta (la real) para que nadie pudiera ver mis datos y fotografías, excepto mis contactos, incluso para no aparecer en los resultados de la búsqueda. De sobra está decir que no tendré muchos contactos ni seré popular, pero tampoco es algo que me quite el sueño. No he mencionado que la misma situación es aplicable a los blogs, pero si este blog fuera privado no se estarían enterando de ésto y yo sí quiero que se enteren. Hay que buscar el balance. Por cierto, durante mi recorrido por el féisbuc encontré muchas cuentas (algunas conocidas) con perfiles públicos, es decir, a la vista de todos. Si estás entre mis amigos y conocidos y estás leyendo esto, revisa por favor tus opciones de privacidad en tu féisbuc, y si no también. :-D. Sólo hay que dedicar un poco de tiempo y evitar problemas.

Ya por último, ¿cómo puede alguien estar seguro de que aquél que está solicitándote integrarse a tu red social es realmente alguien que conoces? Es difícil, pero puede usarse un principio de seguridad telefónica básico conocido como call back. Hacer call back (también conocido como dial back, o "devolver la llamada") quiere decir que cuando alguien te llama por teléfono, para asegurarte que realmente es él, cuelgas y le llamas tú al número que conoces de él o ella. Aplicándolo al caso féisbuc, equivaldría a escribirle a tu amigo o amiga (a la dirección previamente conocida, no a aquella que viene en el perfil del solicitante, pues podría ser falsa) y preguntar si realmente hizo la solicitud. En la práctica es más fácil asumir el riesgo, pero ¿cuántas veces realmente alguien se pone a pensar en la posibilidad de que sea un engaño y alguien esté tratando de hacernos daño? Casi siempre puede más la curiosidad que la seguridad personal.

Las redes sociales son, entonces, una de tantas formas de interrelacionarnos, al menos virtualmente, con personas afines y de intereses comunes, compartir información de interés mutuo, como noticias y fotografías, pero que deben ser usadas con responsabilidad, con la responsabilidad que amerita el uso de un servicio de naturaleza informativa y de relaciones interpersonales. Sin embargo, como sabiamente dijo alguien que conozco, pero cuya identidad me reservo por su propia seguridad :-P (cito textualmente): "Debido a que las redes sociales hoy en día ponen en riesgo nuestra integridad fisica, tendremos que volver a las viejas prácticas donde nos vemos en un lugar, platicamos sin teclado, y no podemos subir videos ni usar Ks a nuestro antojo, deformando palabras o poner caritas de msn con signos y letras". Palabras sabias, sin duda.

Ahora ya lo saben, si algún día reciben una solicitud de féisbuc (Facebook, pues) para agregar como amigo o amiga a alguien que no conozcan (o que aparentemente sí conocen), piénsenlo dos veces... podría ser algún malintencionado, ...o podría ser mi prima... mi cuenta prima. :-D

:wq!

Cuida el ambiente... y el ancho de banda

Diariamente mis buzones de correo electrónico (e-mail, i-meil) tienen mucha actividad, igual que los de muchos de ustedes. Mensajes que entran y salen, a veces indiscriminadamente; SMTP e IMAP en todo su esplendor. Todos esos bits recorriendo el éter.

No soy ambientalista, aunque de repente trato de seguir algunos de los consejos que considero prácticos, especialmente aquellos de quien he llamado La Conciencia Ecológica de IT, aquí donde trabajo. En últimas fechas me llamó la atención que varias firmas de correos electrónicos que recibía desde hace ya varios meses incluían una leyenda como:

P Cuide el ambiente: por favor no imprima este e-mail a menos que sea realmente necesario.

Curioso como soy, me di a la tarea de googlear el famoso letrerito, y encontré que alguien sugirió el año pasado incluir el mensaje en las firmas de correo electrónico, como una manera de crear consciencia en la comunidad y no se imprimieran innecesariamente los correos electrónicos, pues eso representa, según el mensaje original, un desperdicio. Desde entonces cada vez más y más correos llegan con esa leyenda. Suena bien intencionado, y no lo critico, pero ¿realmente alguien deja de imprimir un correo después de leer ese mensaje?

Como decía, el tema ambientalista no ha estado dentro de mis temas prioritarios (ambientalistas: este es el momento de rasgar las vestiduras), pero creo que mi geek interior me impulsó a estar a la moda, sin renunciar a mi posición de neutralidad ecológica. Así que redacté mi propia firma-creadora-de-consciencia-ambiental-posicionadora:

Í Cuida el ambiente, el ancho de banda y el espacio en disco: Por favor, no reenvíes este e-mail a menos que sea realmente necesario. ;)

(Sí, amigos: reemplacé el arbolito verde y el caminito por un floppy disk azul.)

Los que me conocen saben que soy enemigo de las cadenas, pues llenan de pura basura los buzones de correo electrónico, como en otro tiempo llenaban nuestros buzones postales aquellas cartas que tenías que fotocopiar como 51,966 veces y repartirlas indiscriminadamente entre vecinos, parientes y otros incautos, antes de que te cayera la maldición de no-se-quién, como "constaba" en los testimonios incluidos: "fulanito no lo hizo y al otro día perdió su trabajo"; pero si lo hacías recibirías grandes beneficios, porque "fulanita sí lo hizo y al día siguiente ganó la lotería", seguramente porque mientras repartía las cartas antes de que le cayera un rayo, pasó por el puesto de billetes de lotería y, con lo que le sobró de las fotocopias, compró el cachito ganador. Perdón, me explayé. El caso es que las cadenas son molestas y no sólo llenan los buzones, sino que también llevan consigo las direcciones de correo de todos aquellos seres que tan inocentemente reenviaron el mensaje (o lo recibieron) sin saber que lo que estaban haciendo no era solamente evitar que les cayera un piano encima, sino proveyendo de materia prima a los spammers (si algún spammer está leyendo esto, acuérdese de lo que le ocurrió a Vardan Kushnir. He dicho).

¿Y todo este rollo, por qué es? Ah, pues porque mi mensaje dice: Cuida el ambiente, el ancho de banda y el espacio en disco: Por favor, no reenvíes este e-mail a menos que sea realmente necesario. ;) (el emoticon al final es para que nadie lo vea como una orden, pues ¿quién soy yo para decirle a otros lo que debe o no hacer con su e-mail? :D).

Los servidores de correo electrónico tienen mucho trabajo recibiendo y enviando mensajes, aplicando filtros bayesianos para determinar si un mensaje es probablemente spam, verificando las cuotas de los usuarios para evitar que se excedan, revisando los archivos adjuntos con el antivirus, almacenando los e-mails en los discos, y todo eso cuesta y debe administrarse. Además, el simple hecho de enviar algo por el éter, consume recursos en la red: electrones viajando por el cobre, o fotones por la fibra óptica, o señales de radio por el aire; los routers deben dedicar tiempo y procesamiento para enviar los mensajes eligiendo la mejor ruta, y ¿qué decir de la energía eléctrica que se consume en cada ciclo de CPU para procesar el envío, a cualquier nivel?. Todo un despliegue de tecnología al servicio de alguien que posiblemente pensó: "no vaya a resultar cierto y me abandone mi novia o se muera mi perro. Por si acaso, mejor lo mando las 128 direcciones que me piden".

En fin, si alguien tiene curiosidad y quiere incluir el ahora-famoso mensaje ambientalista, sólo necesita agregar el siguiente código HTML en su firma de correo (si es que soporta HTML):



<font color="#006600" face="Webdings" size="+1">P</font><font color="#006600"> Cuide el ambiente: por favor no imprima este e-mail a menos que sea realmente necesario.</font>



Y si quieren incluir una versión mía, ligeramente modificada, donde recomiendo reutilizar el papel en lugar de prohibir imprimir (y reemplazando irreverentemente el arbolito original):



<font color="#006600" face="Webdings" size="+1">Q</font><font color="#006600"> Si necesita imprimir este e-mail, hágalo... pero reutilice y recicle el papel. ;)</font>



Y ya por último, si se quieren unir a mi causa por la preservación de los bits y el ahorro de espacio en los medios magnéticos y el ahorro de energía al no usar innecesariamente los procesadores de los servidores de correo y otros dispositivos de red que también han sido víctimas del temible "forward", he aquí mi firma (por supuesto, con el floppy):


<font color="#000066" face="Webdings" size="+1">Í</font><font color="#000066"> Cuida el ambiente, el ancho de banda y el espacio en disco: Por favor, no reenvíes este e-mail a menos que sea realmente necesario. ;)</font>


Bueno. Después de escribir todo este asunto pseudo-ambientalista, creo que es hora de ver esas presentaciones de PowerPoint que me llegaron esta mañana. :D

Por favor, reenvíen este mensaje a sus amigos y conocidos. No van a ganar la lotería, ni la chava más guapa de la escuela les va a hacer caso por enviarlo, pero al menos podrían contribuir a reducir el calentamiento global... de los servidores de correo.

:wq!

Del plato a la boca, se cae la sopa: El caso DNS-Kaminsky-Dullien

No hace mucho les platicaba acerca del caso Kaminsky y cómo mantuvo en secreto (aunque, eso sí, divulgando a los cuatro vientos que tenía un secreto) una vulnerabilidad encontrada en el protocolo DNS, y comentaba yo acerca de la importancia de no revelar algo que pudiera caer en manos enemigas y ser explotado. En esto estábamos, cuando me entero este fin de semana que alguien se le adelantó a Kaminsky (que ya se veía con los reflectores encima): Thomas Dullien (aka Flake) publicó en su blog lo que él pensaba (por cierto, acertadamente) que podía ser el problema del DNS. Esto no sería relevante si no fuera porque alguien que participó en el proyecto de Kaminsky lo confirmó, con lujo de detalles. Aunque esta información estuvo publicada en Internet poco tiempo (fue quitada después de una disculpa), fue suficiente para que ahora medio mundo conozca los detalles y seguramente ya se están preparando los exploits correspondientes.

Bueno, esto iba a ocurrir de cualquier manera en agosto, cuando Kaminsky lo dijera en el BlackHat, así que los que hicieron la tarea y actualizaron (o parcharon) sus sistemas podrán dormir tranquilos. (?)

Esto deja varias lecciones: Primero, que cualquier persona con el tiempo, conocimiento y motivación suficientes, pudo haber descubierto la falla. Segundo, que no podemos confiar en la Seguridad por Oscuridad, es decir, que el simple hecho de ocultar algo no lo hace seguro. Y tercero, que a veces no conviene esperar tanto a los reflectores, especialmente cuando hay tanta expectativa: bien dicen que del plato a la boca, se cae la sopa.

Hasta luego.

:wq!

Error forense en Numb3rs

¿Y la cadena de custodia, 'apá?

Anoche ví el episodio Sacrifice de la primera temporada de Numb3rs, la serie de televisión donde Charlie Eppes, un chavo matemático, ayuda a su hermano Don, agente del FBI, a resolver casos usando ¿qué creen? sí, matemáticas. He visto algunos episodios de la primera temporada y, aunque el concepto es interesante, algunas cosas son realmente difíciles de creer (de acuerdo, es entretenimiento). Cuando llego a ver televisión (algo muy remoto), lo hago para divertirme, no para estudiar matemáticas (esas las estudio a otra hora), y Numb3rs había sido prometedor, pero el episodio que vi anoche casi me causa una conmoción cerebral, por el impacto recibido al ver cómo los principios de investigación forense (al menos en el ámbito de la informática) eran echados a la basura. Les platico, aunque les advierto que revelaré parte de la trama. Bueno, están advertidos.

Como algunos de ustedes saben, me apasiona el tema de la seguridad de información, la criptografía y las investigaciones forenses en crímenes informáticos. Así que, cuando comienza el episodio y me doy cuenta de que la computadora de la víctima formará parte de la investigación, digo: "esto se va a poner interesante", pero, ¡oh, desilusión!, nunca se involucró a un forense de computadoras que conociera el procedimiento, obviamente no se inició la cadena de custodia, y peor aún, se transgredieron varios principios fundamentales del análisis forense que habrían ocasionado que, en caso de que tuvieran que ir a un juicio, la evidencia hubiera resultado inútil.

El episodio trata de la investigación del homicidio de un investigador que trabaja en un proyecto clasificado (confidencial) del gobierno; los archivos de su computadora personal (donde presumiblemente estaba toda su investigación) habían sido borrados. Primero: ¿qué hacía este investigador con información confidencial en su computadora casera? Por lo visto nadie le explicó al investigador el modelo de confidencialidad Bell-LaPadula, lo mismo que aquél militar que fue cesado porque su hija divulgó información clasificada del ejército, misma que encontró en una memoria flash (USB) donde su papá (el ex-militar) había copiado dichos archivos confidenciales... aunque esa es otra historia.

Pero, como dijera Jack El Destripador (Jack The Ripper): "vamos por partes" :-D. Por ejemplo: cuando llegan los supuestos forenses, comienzan a revisar la computadora directamente en la escena del crimen. Un buen forense no hubiera hecho eso; debieron haber comenzado la cadena de custodia del equipo, llevado al laboratorio forense, extraído el disco duro, obtenido una imagen bit a bit, montado la copia en modo read-only en un sistema operativo para analizar (de preferencia el de Linus, no el de Bill :-)) y, ahora sí, comenzar a investigar. Al no haber hecho esto, nuestros amigos investigadores expertos del FBI incurrieron en un error forense, al manipular directamente la computadora involucrada. Otra falla fue el hecho de que Charlie trató de revisar la PC del investigador, ahora occiso, también directamente, sin trabajar sobre una copia. Puras fallas.

Por otra parte, la explicación que Charlie le da a su hermano respecto a la sobreescritura de datos es algo ilustrativa, y cumple con el propósito de poner en contexto a la audiencia. Lo que él explica es un concepto que en seguridad conocemos como zeroization, que consiste en sobreescribir los datos con algún patrón de bits, de modo que se dificulte la recuperación de los datos originales. El asesino sabía que borrar los archivos no era suficiente, pues generalmente son recuperables, pero con zeroization sería mucho más difícil (pero no para nuestro héroe matemático). A lo mejor si se hubiera robado la computadora, el móvil hubiera parecido distinto y la investigación no hubiera requerido a los forenses de cómputo. Caso cerrado. :-D

Ya sé que todo esto al final es ficción y que en la vida real no se hubieran cometido tantos errores en materia forense. Además, pienso que para muchos es mucho más entretenido ver a estos personajes en la investigación que al forense y su laboratorio. Al final, como siempre, encontraron al culpable y todos vivieron felices, listos para el siguiente episodio... excepto Charlie, que se quedó pensando si lo que hacía era bueno o malo, si ayudaba a salvar vidas o las quitaba. Un dilema muy grande para una mente tan brillante. ;-)

:wq!

// Para los que no entendieron el subtítulo, está inspirado en la frase célebre del comercial de un chavito que está platicando con su papá, y le pregunta cuándo va a hereder la camioneta.

La importancia de no 'soltar la sopa': El caso DNS-Kaminsky

Hasta este día no había escrito ningún comentario referente a vulnerabilidades o riesgos de seguridad, aún cuando siempre procuro estar pendiente de las actualizaciones y avisos relevantes diariamente. Sin embargo, mientras leía y profundizaba en los detalles de una de las actualizaciones relevantes de Microsoft de esta semana, me llamó enormemente la atención el caso de Dan Kaminsky, un profesional en seguridad informática que descubrió hace pocos meses (y por accidente, dice él) una vulnerabilidad en la implementación del protocolo DNS, que afecta tanto a servidores DNS como a clientes DNS.

Sólo para estar en el mismo contexto y para que nadie se sienta excluído: DNS (Domain Name System) es el servicio que se usa en Internet para evitar tener que memorizar (nosotros los humanos) direcciones IP (como 209.85.173.104) y en lugar de eso, recordar más fácilmente nombres de dominio tales como www.google.com. Sin DNS, Internet no sería lo que es ahora (no sería atractivo para muchísima gente).

Regresando al tema, lo que me llamó la atención de esto fue la forma de proceder de Dan Kaminsky al darse cuenta del problema. El hacker típico sin ética (black hat) habría explotado la vulnerabilidad en algún servidor expuesto (que, tratándose del servicio de DNS, no hubiera representado ninguna dificultad) y casi inmediatamente lo habría difundido en algún foro de hacking (en esos ámbitos, el dudoso prestigio de ser el primero en consumar un ataque es muy bien visto, aunque no sea éticamente correcto o legal). El problema aquí es que, por tratarse de un problema masivo, es decir, que afecta a todos los sistemas DNS, independientemente del fabricante, el atacante podría tener virtualmente control absoluto de prácticamente cualquier sistema de resolución de nombres de dominio (DNS) y direccionar a sitios falsos para robar información o cometer actos fraudulentos. Un gran riesgo.

Pero Kaminsky no lo hizo público. En lugar de anunciar públicamente (y quizá irresponsablemente) la falla, buscó a los principales proveedores involucrados en el desarrollo de servicios DNS (Sun Microsystems, Cisco, Microsoft) y al CERT (Computer Emergency Response Team) de Estados Unidos, y en conjunto comenzaron a trabajar secretamente en la solución, con el propósito de liberar la solución a nivel mundial al mismo tiempo. Esto ocurrió ayer, el día en que los principales proveedores de la industria liberaron simultáneamente los patches para sus respectivos productos. Las palabras clave en esto son "secretamente" y "en conjunto". Si no se hubiera hecho así, a estas alturas tendríamos un caos por todos los que habrían explotado ya la vulnerabilidad sin existir una solución de fondo en todos los sistemas. El mismo Kaminsky invita a seguir investigando el DNS, y a no hacer públicos los hallazgos en los foros o canales de IRC, y yo estoy completamente de acuerdo con él.

Los ataques a los sistemas DNS no son nuevos. Desde hace tiempo han existido los ataques de buffer overflow, DNS cache poisoning, spoofing, entre otros, pero no se había presentado un caso que involucrara de forma masiva a los sistemas en todo el mundo, y que se manejara de forma tan profesional y organizada como se hizo en esta ocasión. Así es como lo veo.

¿Qué tiene que ver esto con un usuario de servicios a través de Internet? Absolutamente todo. DNS interviene en prácticamente cualquier interacción en Internet... imagínense tener que visitar sitios Web usando la dirección IP, como http://209.85.173.104 por ejemplo. ¡Qué complicado! (las campañas de mercadotecnia se verían en apuros). Así que DNS nos ayuda a que escribamos http://www.google.com en el navegador, en lugar de la dirección IP, pues DNS hace la traducción del nombre de dominio en la dirección IP correspondiente. Si este problema se explotara, podríamos ser redirigidos sin darnos cuenta a servidores falsos y ser víctimas de pharming; o los correos electrónicos que enviáramos serían dirigidos a servidores extraños y ser interceptados por alguien más. Si DNS falla, Internet falla. El impacto sería enorme, pero aquí es donde la estrategia de manejarlo en forma coordinada tiene un gran valor.

Aún no hay información detallada acerca de esto, y la implementación presumiblemente se ha hecho pensando en que sea muy difícil la ingeniería inversa de los parches que están siendo liberados, precisamente para dar tiempo de instalar los parches en todos los sistemas que usan DNS, o de mover de BIND8 (que ya está muerto, excepto en Yahoo!) a BIND9. De hecho en este preciso momento ya hay varios tratando de identificar (usando ingeniería inversa) exactamente qué es lo que los parches corrigen, para tratar de explotarlo; esto es algo que no se puede evitar, y es la razón por la que es importante que todos los que tienen servicios que usan DNS instalen los parches cuanto antes. Kaminsky va a dar su versión en la próxima conferencia de Black Hat en Las Vegas, pero los detalles seguirán en secreto, al menos por un buen rato.

La seguridad es asunto de todos, y la seguridad en Internet no es la excepción. Al menos yo quiero que cuando mi familia se conecte a Internet para leer las noticias, comprar un libro, jugar en línea, usar el correo electrónico, hacer un pago bancario o simplemente leer un blog, lo haga con seguridad. ¿Quién no? Qué bueno que Dan Kaminsky no soltó la sopa. ;-)

:wq!

ISO 27001:2005, Primera Reunión de Intercambio de Experiencias en Monterrey

"La Seguridad no es un producto; la Seguridad es un proceso".

La frase anterior es el mantra que todos los gurús profesionales en seguridad repiten una y otra vez (¿repetimos?). Esto es una gran realidad, pues en la actualidad muchas empresas no han entendido que la seguridad no es algo que se compre en caja, ni un proyecto que tenga una fecha de inicio y una fecha de conclusión, o algo que sea responsabilidad exclusiva de TI, sino que es un proceso de mejora continua, en el que todo el personal de la compañía debe estar involucrado.

Con esto en mente, ALAPSI Noreste organizó el 29 de mayo la Primera Reunión Cumbre de Intercambio de Experiencias con Sistemas ISO 27001:2005 Certificados, que tuvo como finalidad juntar a representantes de algunas empresas de México que han obtenido la certificación en Sistemas de Gestión de Seguridad de Información ISO27001:2005, para que platicaran sus experiencias en torno a la certificación, los beneficios obtenidos, las recomendaciones para aquellos que estén planeando iniciar el proceso de certificación, los retos que enfrentaron, etc. Entre los panelistas tuvimos a Patricia Molina de Elcoteq, a Carlos Rincón de Laboratorios Armstrong, a Daniel Aldrete de Hispanic Teleservices y a Ricardo Morales de Alestra. Todos ellos coincidieron en algo: la certificación ISO 27001:2005 les trajo beneficios a sus respectivas organizaciones, tales como mayor confianza por parte de sus clientes, estandarización y mejora de sus proceso internos, ahorros significativos, entre otros más.

ISO 27001:2005 es un estándar para la seguridad de información basado en la norma británica BS 7799, y que define lo nececesario para implementar, mantener y mejorar un Sistema de Gestión de Seguridad de Información, de acuerdo al Ciclo de Deming (o Plan, Do, Check, Act). Aunque la seguridad en sí no es un producto ni un proyecto, como ya lo mencioné anteriormente, la implantación de este estándar en una empresa con miras a la certificación sí requiere que se maneje como un proyecto, con su propio presupuesto. En general la implantación de ISO 27001 puede durar entre 6 meses y un año, según el alcance requerido y qué grado de madurez tienen los procesos en la organización. Aunque algunas empresas requieren el apoyo de consultores externos, es importante considerar dos cosas: primero, que tengan la experiencia suficiente en implementaciones anteriores, no que vengan a aprender con la empresa; y segundo, que su participación se limite a guiar al personal estratégico en cómo hacer las cosas, y no a hacer él sólo todo el trabajo desde lo básico (créanme, un consultor puede resultar muy caro). Una vez que el sistema está implementado y se tienen al menos unos 3 meses de evidencia documentada, ya se puede invitar a un organismo certificador (externo a la empresa) para que revise los procesos, la evidencia documental y se cerciore de que se cumple con lo establecido en el estándar. Por lo que escuchamos por parte de los que ya han recorrido este camino, no es fácil, pero vale la pena.

Esta reunión fue organizada por ALAPSI Noreste, que es la Asociación Latinoamericana de Profesionales en Seguridad Informática, de la cuál formo parte. Nuestra misión es crear conciencia y capacitar a organizaciones e individuos en el área de Seguridad de Información, por medio de cursos, seminarios, conferencias, artículos en publicaciones relacionadas con seguridad, etc., y promover prácticas que aseguren la confidencialidad, integridad y disponibilidad de los recursos informáticos de las organizaciones.

En resumen, espero que con eventos como éste cada vez más empresas se sientan comprometidas con la seguridad de la información, y comiencen a establecer las bases necesarias para que sus organizaciones mantengan los niveles de seguridad que se requieren en esta era de la información.

:wq!

Lo nuevo en Sun Tech Days 2008, México

Otro año más y no he podido ir al JavaOne. Ni modo. Pero esta ocasión estuve nuevamente en el Sun Tech Days 2008, en la Ciudad de México, que sigue siendo una buena (y barata) opción para actualizarse en temas de Java y Solaris. El evento lo organiza Sun Microsystems y es algo así como un "world tour". Ahora no escuché a Sang Shin, pero estuve en varias conferencias con Raghavan "Rags" Srinivas (el del sombrero vaquero), por ejemplo, y nuevamente con Fabiola Gallegos. Mi objetivo principal en este viaje fue el de actualizarme en temas como SOA (Service Oriented Architecture), seguridad en Web Services y, por supuesto, en Mobile Applications.

Como un plus, estuve en una demo de Sun SPOT (Small Programmable Object Technology), que es una tecnología (aún experimental) de Sun Labs para la programación de dispositivos inalámbricos, equipados con sensores de luz y temperatura, acelerómetros, y un transmisor de radiofrecuencia de 2.4GHz, entre otras cosas (sin olvidar que corre con una implementación especial de virtual machine llamada Sqwawk, que corre directamente en la flash del dispositivo, hace la función de sistema operativo e implementa Java ME). La sesión se enfocó en demostrar la programación del dispositivo para transmitir la información recolectada por los sensores, o la incorporación de un dispositivo electrónico externo (en ese caso, una brújula electrónica) que transmitió la orientación hacia el basestation, y fue representada gráficamente en una aplicación de escritorio con Swing; fue sencilla, pero bastante ilustrativa. Lo malo es que en México aún no pueden conseguirse los kits de Sun SPOT, porque tienen que cumplirse ciertas regulaciones antes, pero un día de éstos conseguiré mi propio kit para jugar un rato.

Referente a Java ME, las demostraciones de Fabiola en este año se enfocaron a ejemplificar la ejecución de programas Java en dispositivos ejecutando Windows (como Pocket PC) y en BlackBerry. Fue todo un show, porque ejecutar una aplicación de Java ME en una Pocket PC requiere primero la instalación de una JVM específica para esa plataforma, y luego ya la instalación de la aplicación Java, que no es nada sencillo, sin embargo es posible. Para el caso de BlackBerry es más sencillo, pero aún así no es tan directo como en la mayoría de los teléfonos celulares habilitados con Java.

Y para terminar, las sesiones de SOA fueron bastante extensas y muy ricas en contenido. Como lo mencioné, mi principal preocupación era escuchar sobre los temas referentes a seguridad, y no me decepcionaron. Esto es particularmente importante por tratarse de una arquitectura que pretende integrar múltiples servicios a través de Web Services independientes de lenguaje, BPEL para coordinar u orquestar las transacciones que deban hacer uso de múltiples Web Services, y que permite la integración de tecnologías de seguridad que protegen la integridad y confidencialidad de los datos a través de todas las operaciones entre todas las entidades, y no sólo entre dos servidores. Sobre este tema escribiré en otra ocasión más ampliamente.

Bueno, así fue la semana anterior: "100% Pure Java".

:wq!