DSE: Legislación Mexicana de Seguridad

El día de hoy 14 de marzo inicié el programa de Dirección en Seguridad en Empresas. Es un curso donde se tratan temas de seguridad física. Les comparto algunos apuntes de temas tratados en esta sesión que ignoraba, que no conocía suficiente o que simplemente me parecieron interesantes. Varios puntos formaron parte de mi tarea.

Primera advertencia: los temas no están relacionados con seguridad de la información o en todo caso tienen poca relación.

Segunda advertencia: normalmente trato de redactar mis posts con cierta coherencia y orden. No será el caso para esta serie de posts express.

Dicho lo anterior, comencemos.

+ Coche bomba es diferente de coche con bomba. En el primer caso hay interconexión de la bomba con el auto. En el segundo caso se deja la bomba dentro del auto sin interacción entre ambos.

+ Liga de la Ley de Seguridad Nacional. Artículos que mínimo hay que leer: del 1 al 5.

+ Liga del Código Penal para el Distrito Federal.

+ Si uno se guarda algo en el bolsillo dentro de un súper, se considera robo? Se podría pensar que no y que es robo hasta que uno se sale de la tienda. Al parecer existe el concepto de “sustracción de la esfera de vigilancia del legítimo tenedor” con el cual se podría considerar robo al acto descrito. No encontré mucha información sobre este concepto en la red.

+ LEY GENERAL DE ACCESO DE LAS MUJERES A UNA VIDA LIBRE DE VIOLENCIA. Qué te parece esta Ley? Sólo por poner un ejemplo:

ARTICULO 6. Los tipos de violencia contra las mujeres son:

I. La violencia psicológica. Es cualquier acto u omisión que dañe la estabilidad psicológica, que puede consistir en: negligencia, abandono, descuido reiterado, celotipia, insultos, humillaciones, devaluación, marginación, indiferencia, infidelidad, comparaciones destructivas, rechazo, restricción a la autodeterminación y amenazas, las cuales conllevan a la víctima a la depresión, al aislamiento, a la devaluación de su autoestima e incluso al suicidio;

+ Inhumar: Enterrar un cadáver. Exhumar: Desenterrar un cadáver o restos humanos.

+ Clasificación de las Instalaciones estratégicas:

Siendo su clasificación como "AAA" aquellas cuya afectación o interrupción del proceso normal de operación, implique un riesgo desestabilizador directo y/o inmediato para la Seguridad de Nación. (Nivel Nacional) "AA" aquellas cuya interrupción del proceso normal de operación –no obstante afecte a extensas e importantes zonas geográficas de la Nación- no represente un riesgo directo y/o inmediato de desestabilización para el País. (Nivel Regional) "A" aquellas cuya afectación o interrupción del proceso normal de operación, repercuta solo en perímetros geográficos y poblacionales reducidos, sin que ello atente contra la estabilidad de la Nación de manera directa, y/o, inmediata..

+ Hay una “Ley Federal de Seguridad Privada”. Lo desconocía.

+ Blindaje: barrera que se interpone entre un factor de riego y un sujeto. Las barreras pueden ser naturales, informáticas, etc.

Lo Único Que Quiero es Que te Vayas

En pocas palabras eso es lo que le dijo Microsoft a su hijo Internet Explorer 6. Y hasta abrió un sitio web (www.ie6countdown.com) donde registra el % de uso de su hijo. En palabras de @microsoftnews: “los amigos no dejan que los amigos usen IE6”. ¿Pues qué hizo tan malo como para que le anden pateando su azul trasero?

Probablemente tú sí mantengas tu software actualizado o al menos tus ventanas de tiempo de actualización son lo más cortas posibles. Sin embargo un porcentaje importante de empresas y usuarios alrededor del mundo simplemente dejan que su software se quede en el olvido. Les importa un cacahuate mantener su software al día… o les da flojera hacerlo; tal vez usan software pirata y están a gusto así. Muchos no saben para qué sirve eso de “actualizar” si sus apps “jalan a la perfección”.

Internet Explorer 6 salió hace 10 años…y la gente lo sigue usando!! Yo que me preocupo cuando veo casos en los que pasan meses sin actualizar, pero el problema del software olvidado se cuenta en a-ñ-o-s.

Y por cierto, para qué rayos sirve actualizar el software?? Ahhh, pues a diferencia del Jetta de mi papá de 1995 que aún sirve porque lo mantiene al día, el software debe de actualizarse -la gran mayoría de las veces- porque así dan solución a problemas en su seguridad.

Por ejemplo, recientemente se publicó un estudio de los laboratorios M86, donde se establece que el top-15 de los ataques en Internet se podrían evitar porque ya tienen parches, es decir, cuentan con soluciones por parte del fabricante. Ponen el ejemplo del ataque No 2 de la lista que explota una debilidad en “Office Web Components Active Script Execution”… el parche está disponible desde 2002. Otras debilidades tienen parches desde el 2006.

Sinceramente no necesité este estudio ni el sitio de Microsoft que registra la muerte lenta de IE6 para saber el tamaño del conflicto.

Entonces, el problema está del lado de los inútiles usuarios..o de los inútiles fabricantes de software que no incorporan mecanismos de actualización efectivos a sus productos?

Yo le voy a los fabricantes de software que nos han dado software chafa. Y los números hablan por sí solos: desde el IE6 de Microsoft, hasta los productos de Adobe o el Java JRE que se quedan como muertos vivientes a lo largo del tiempo entre otros ejemplos. Y bueeeeno .. nosotros compartimos un poco de culpa por aceptar software deficiente (desde el punto de vista de seguridad).

¿Qué hacer? Empezar con lo que está bajo nuestro control. En la Mac o PC de casa, al menos una vez el mes darle su alineación y balanceo. Si trabajas en (o estás a cargo de) un área de TI..pues creo que no tienes excusa válida si tu infraestructura está como muerto viviente.

Los amigos no dejan que los amigos se queden con aplicaciones antiguas e inseguras.

Política Para el Uso de Redes Sociales.

Si los empleados necesitan una “política” de uso de redes sociales realmente me preocuparía. ¿Mentarle al jefe en el muro público de Facebook? ¿Hablar pestes de tu empresa? ¿Poner fotos de un sitio reservado de la empresa? ¿Necesitamos una política para reglamentar la conducta online?

El uso de las redes sociales es simple sentido común, cuestión que al parecer algunos no tienen. Las mismas consecuencias que tendrás en el mundo offline las tendrás en el mundo online. Si le mientas la madre al jefe en tu muro público de Facebook y crees que de alguna manera eso no cuenta porque lo dijiste en Internet, entonces me preocuparía (más que la propia mentada tal vez) el hecho de que hubiera un empleado con una fuerte escasez de sentido común.

Sobre todo si en una organización ya existe una manera (tal vez un reglamento general) de lidiar con insultos entre empleados, exposición de fotos comprometedoras y otros comportamientos inapropiados, entonces lo mismo va a aplicar a las redes sociales. El comportamiento es uno y las consecuencias también, lo único que cambia el es el medio.

Algunos llegan a ver a Internet como un mundo paralelo al real, uno donde de alguna manera las cosas que se hacen o dicen no cuentan y donde puedo fastidiar a una organización o individuo con total libertinaje.

Pero caray, sobre todo si nuestro perfil de Facebook, Twitter o Linkedin coincide con nuestro nombre, apellidos y hasta lugar de trabajo…no sé cómo se asume que de alguna manera nuestras mentadas, comentarios, fotos o videos impertinentes podrían pasar desapercibidos envueltos en un anonimato selectivo. ¿Tuitear sobre un caso legal en curso de la empresa? ¿Facebookear información confidencial? ¿Discutir el contenido de una junta con Directivos en redes sociales? ¿Decir la estrategia interna de ventas para el siguiente año? Apliquemos el sentido común a las preguntas anteriores.

Algunos hasta se llegan a quejar amargamente en redes sociales de su empresa, de las condiciones en que trabajan o del bajo sueldo que reciben. ¿Y eso está mal? ¿Nos debemos quedar callados? Caray, podemos comentar y quejarnos, siempre y cuando estemos dispuestos a sostenerlo cara-a-cara en caso de que el jefe, el compañero de trabajo, el área de Asuntos Laborales o área de Relaciones Públicas se entere (ah sí…me faltó el área Legal).

Facebook, Twitter, LinkedIn, FourSquare o Instagram son redes para expresarnos y comentar; y sobre todo si están ligadas a nuestra persona, lo mismo da opinar con Chana (offline) que con Juana (online).

Y como empresa o Institución, se deben de atender los desplantes online tal cual se haría con los offline, así de sencillo. Y es importante contar con un reglamento general donde entre otras cuestiones, se atiendan comportamientos/actitudes…no el medio por el cual se expresan.

(Nota personal: por cierto, me molestan los que se la pasan quejándose de su trabajo todo el tiempo…si tanto lo aborrecen, que se cambien de empleo y dejen de lloriquear).

El fin de los Días Cero.

¿El fin? Lo dudo. Justin Rattner, CTO de Intel, comentó en días pasados que esa compañía estaba –y cito-: “working on security technology that will stop all zero-day attacks”.

Un ataque de día cero es cuando existe un exploit, código de concepto u otra manera de atacar un software, hardware, protocolo o especificación y todo esto sin que haya una solución definitiva.

Rattner no dio muchos detalles que digamos de cómo trabajaría esta “nueva tecnología”. Y también agregó: “We've found a new approach that stops the most virulent attacks. It will stop zero-day scenarios. Even if we've never seen it, we can stop it dead in its tracks”.

Supuestamente esta nueva tecnología estará basada en hardware; suena lógico si pensamos que Intel fabrica… errr, chips. Y también recordemos que Intel compró a McAfee (compañía de antivirus). Entonces si unimos las piezas, intuimos que no es que Intel vaya a detener en frío a “todos” los días cero.

Creo que lo que Intel quería decir es que están desarrollando una nueva tecnología basada en hardware que dificultará la infección por virus y demás código malicioso en un sistema, dándole un respiro a la actual manera en que los antivirus detienen a estos bichos que es por medio de firmas. ¿No quedó mejor? Me deberían de contratar como asesor del CTO de Intel…ajá.

En fin, afirmar que estás desarrollando una tecnología que detendrá “todos” los días cero es algo ciertamente osado y que tengo que verlo para creerlo. Hasta ahora los días cero surfean alegremente las aguas del Internet y hasta son usados para dar problemas a plantas nucleares (StuxNet).

Por ejemplo, podemos mitigar los riesgos de estos días cero en Windows usando controles compensatorios como sandboxes, firewalls personales, el buen no-script para FireFox y otros más que en conjunto podrían salvarnos de que exploten nuestras ventanas.

Los Desarrolladores son los Culpables.

Ok, ok, no quiero a decenas de desarrolladores comentando este post con mensajes de odio ;). Sólo estaba pensando el otro día lo mucho que criticamos a los usuarios por ser “el eslabón más débil”, por “no tener ni idea” o “ser poco inteligentes”.

Pero si se ponen a pensar, realmente la mayoría de las amenazas que pululan en Internet, en las redes internas y sistemas son originados o facilitados por las vulnerabilidades presentes en sistemas operativos y aplicaciones. Tenemos al fulano que le roban su dinero al usar banca en línea, o la computadora que es usada para ser parte de una bot y más recientemente, un ataque a los sistemas de una planta nuclear.

Inyección de SQL, cross site scripting, troyanos y gusanos que aprovechan debilidades de software para concretar sus objetivos. Un reciente ejemplo fue la conferencia de BlackHat de este año que estuvo nutrida por demostraciones de debilidades…en software: http://tinyurl.com/BlackH11.

Sí claro, ya que se explota la debilidad de software, muchas veces el usuario ayudará a finalizar el ataque. Sin embargo piensen en un mundo imaginario donde el software no tiene vulnerabilidades: cuántos ataques se podrían llevar a cabo? Se me ocurre el phishing donde el usuario da su usuario/contraseña en un sitio web falso. No intervino ninguna debilidad de software…el usuario es el “culpable”.

Pero salvo en algunas excepciones, realmente el problema de raíz es el software que si bien funciona, tiene buffer overflows y demás imperfecciones que hacen posible en primera instancia que un ataque sea exitoso. Hay desarrolladores detrás de Adobe Reader, Windows, Adobe Flash, Java JRE, QuickTime, Linux, Safari, Office o Mac OSX…todas ellas con debilidades. Sin mencionar las aplicaciones que se hacen en las corporaciones e instituciones de todo el mundo.

Y no siendo suficiente el hecho de meterle debilidades al software, los desarrolladores y diseñadores no le agregan la funcionalidad de actualización automática a la aplicación (esto último ya ha estado cambiando en Windows y algunas aplicaciones).

En fin, lo anterior se lo comenté a un desarrollador durante una plática y me dijo:

a) El aprendizaje que recibí y recibo para codificar no involucró la parte de seguridad. La escuela no lo hizo y mi empresa tampoco me da una capacitación al respecto, sólo me queda hacerlo por mí mismo…sin embargo mis empleadores no valorarían esa inversión de tiempo porque lo que quieren es que la aplicación jale. Sinceramente dentro de las empresas lo que se busca es sacar aplicaciones funcionales en el menor tiempo posible, así es que eso de “la seguridad” realmente es un gasto de tiempo indeseable.

b) Es fácil criticar la inseguridad de mis aplicaciones web que desarrollo, pero enséñame tres aplicaciones de más de 5,000 líneas de código que esté exenta de errores y entonces me callo. Desarrollar software seguro es difícil, y entre más complejo sea la aplicación, más difícil es darse cuenta de ese tipo de errores. Enséñame un sistema operativo sin bugs que se ejecute en una computadora moderna…eso no existe hoy y dudo que pueda pasar en el mediano plazo.

Ahhhhhh verdad?. La cosa no está tan fácil ¿Los desarrolladores tienen la culpa? Tú dime…al parecer el problema es más complejo que apuntar a “los desarrolladores”, a “los de seguridad” o a “los usuarios”. Dejando de lado quién tiene “la culpa”, pienso que los desarrolladores deben de ver el hecho de codificar aplicaciones con una noción de seguridad en mente como un “plus” o un extra que pueden incorporar a sus destrezas y verlo como una ventaja competitiva, en lugar de verlo como “pérdida de tiempo” o “si a mis jefes no les importa, para qué aprenderlo?”.

Si eres desarrollador piensa en lo que dije…es posible que puedas verlo como una habilidad que te dará una ventaja competitiva? Si eres empleador de un desarrollador, anímalo a que se capacite o aprenda esta habilidad y premia el hecho de que no sólo se hagan aplicaciones funcionales sino lo más seguras posibles.

Como muchas veces, las cosas no van a cambiar si dejamos que “el gobierno”, “la regulación”, “el jefe”, “los de seguridad” o “el vecino” hagan algo al respecto. ¿Qué puedes hacer desde tu trinchera?

(Googleando me encontré con esta página que habla del tema…parece que no soy el único en poner este tema sobre la mesa: http://www.nextgov.com/nextgov/ng_20100216_8606.php).

Nota: a mí en la Universidad no me enseñaron codificación segura…se omitió prácticamente de los temarios.

¿Vivir con los Workarounds? Not.

¿Esperan los fabricantes de software que sigamos cada uno de sus workarounds para las vulnerabilidades de día cero? Debe de ser una mala broma.

Tenemos una debilidad de día cero en una aplicación o sistema operativo; esas que tanto nos gustan donde no hay parche que le dé solución y en la cual simplemente nos tenemos que aguantar…o comernos un sabroso workaround que es una medida temporal para evitar un ataque (esto claro, siempre y cuando el fabricante de software se “digne” siquiera a publicar un workaround; hay casos en donde simplemente hay que esperar el parche y uno mismo tiene que ideárselas para tratar de evitar el ataque).

En fin, podríamos pensar que los “workarounds” son los buenos de la película, ya que una vez que hay un defecto en el software, el buen fabricante nos propone esta medida alterna para ser aplicada y evitar un ataque a la falla. ¿Qué puede haber de malo en eso?

Si tuvieras días cero de vez en cuando y si tuvieras pocas aplicaciones en un solo sistema operativo, no tendría casi ninguna queja. Sin embargo eso no es la realidad ni para un usuario en casa y menos para una empresa donde al menos existe un sistema operativo (dije: al menos) y hay cientos de aplicaciones.

Tal vez para un usuario en casa aplicar workarounds no sea del todo fastidioso (aún así, cuántos usuarios en casa lo hacen?), pero aplicar un workaround en una organización no es de “enchílame éstas”. Hay que probar estos workarounds para ver que no afecten gachamente la operación, posteriormente aplicar progresivamente el dichoso workaround en todas las computadoras (efectivamente, algunos pocos workarounds se pueden aplicar en controles perimetrales). Luego cuando sale el parche conviene hacerle “undo” al workaround.

Y siendo sinceros, varios de esos dichosos workarounds son peor que el exploit, por decirlo de alguna manera. Para los que los hemos tratado de aplicar, finalmente te das cuenta de que se pierde tanta funcionalidad que es mejor olvidarlos. Tendrías a N usuarios llamándote para ver por qué diablos no pueden ver páginas web normalmente o una imagen en un documento. Ah sí, cuando bien te va; una vez me tocó un workaround que al cambiar una llave del registro salía la pantalla azul de la muerte en Windows.

Seguirle el paso a los workarounds de los día cero (ubicar-> probar-> implementar-> undo cuando salga el parche) del software en una empresa es un dolor de cabeza (y fui amable). Que levante la mano el que ha implementado todos los workarounds de los días cero del 2010 al menos para el software de Microsoft y de Adobe. Sí, debe de ser una broma.

¿Qué puedes hacer? Volverte esclavo de los workarounds o tener controles preventivos: una buena hardenización, un IPS personal y un sandbox, por poner unos ejemplos. Otra medida es analizar primero si la debilidad de día cero realmente te afecta y por otro lado ver si no tienes ya controles que mitiguen el riesgo para poder olvidarte del workaround hasta que salga el parche.

Seamos sinceros, no vas a aplicar todos los workarounds habidos y por haber (y créeme, no te culpo), así es que debes de pensar en una estrategia que te permita sobrevivir a los día cero…y a sus workarounds.

Nota: Las debilidades de día cero y sus workarounds están a la orden del día. Por poner sólo un ejemplo, entre el 14 de diciembre y el 5 de enero, salieron 4 debilidades de día cero sólo para Microsoft. Al día 9 de enero siguen sin parche. Y para varias de ellas se proponen workarounds. Checa lo que implican. Y como ejercicio, durante el 2011 ve cuántos workarounds te estarán proponiendo los fabricantes y checa cuántos de ellos puedes implementar sin problema.

“Consejos” para Navegar Seguro.

Me encontré con una lista de consejos del nic para navegar seguro en Internet donde varios de ellos lejos de ayudarme me hicieron quedar con cara de “what?”. Analicemos algunos de ellos con la intención de criticarlos constructivamente.

Respecto a las contraseñas nos dicen: “Se recomienda hacer uso de contraseñas largas, con diferentes letras, números y símbolos que al mismo tiempo sean fáciles de recordar”. Por “largas” creo que podemos decir que 8 caracteres puede ser suficiente (el nic no lo especifica). Sin mencionar que cuando tenemos 10, 15 ó 20 sitios a los que entramos seguido, acordarnos de “n” contraseñas complejas, diferentes pero fáciles de recordar es algo que pocos hacemos y que el nic no toma en cuenta. Lo que yo hago es usar LastPass que me ayuda a “recordar” estos passwords; así podemos cumplir con eso de que sean diferentes para cada sitio y complejas (y sin necesidad de tenerlas en la mente).

De los sitios nos dicen: “Evitar sitios de origen dudoso. Es importante pensar dos veces antes de hacer click en uno de estos anuncios, pues pueden ser causa de virus o spam”. En su consejo no nos dicen qué es un “sitio de origen dudoso” y nos recomiendan que pensemos dos veces antes de hacer click en “uno de estos anuncios”. Es ambiguo y no del todo cierto: hoy en día hasta sitios legítimos pueden contener contenido malicioso en frames, por ejemplo. No sé cómo definir un “sitio de origen dudoso”, ya que hay unos que ciertamente intuimos que lo pueden ser (por ejemplo pornográficos) pero otros ni idea (como el malware que apareció en el sitio del New York Times). Yo uso NoScript en los sitios que visito para dejar de pensar en si es dudoso o no; puede ser una verdadera lata pero hace su trabajo…pruébenlo y me dicen qué les pareció.

Pongamos el extracto completo que nos ofrece el nic para que vean que no ando intencionalmente seleccionando extractos incompletos: “Cuidar datos personales: El mal uso de los datos personales no sólo se remite a lo que el usuario comparte en sus redes sociales, pues también es importante considerar que nunca hay que escribir nombres, apellidos, direcciones, teléfonos o cuentas bancarias en sitios que no sean seguros. Para saber si un sitio es seguro, basta con revisar que el inicio de su dirección incluya una letra s (https://)”. Me llama la atención la última parte en donde dicen que para saber si un sitio es seguro debemos de revisar que tenga “https” porque me es difícil ligar el tema de “datos personales” con el de TLS (https). Cuando un sitio cambia a https, lo que nos dice es que tiene un certificado válido; pero NO nos dice nada de qué harán con nuestros datos ni del cuidado de los mismos. El “https” crea un canal cifrado entre tú y el sitio, quien quiera que el sitio sea o pretenda ser. Nada más. Pueden intentar https://www.RoboTarjetasDeCredito.com y estarán tranquilos de saber que usa “https” y que aparece un candadito en su navegador, cierto?

Nos dicen: “No ejecutar archivos sospechosos” comentando que al navegar algunos sitios mal-intencionados nos pedirán descargar algún archivo aparentemente necesario. De nueva cuenta, eso de “archivos sospechosos” es ambiguo y poco claro, y por lo tanto poco útil. Sitios legítimos me piden también que descargue algún software (quítenle flash a su navegador y se sorprenderán) y me piden que habilite ActiveX o JavaScript (con NoScript se darán cuenta de esto último). ¿Entonces qué hacemos? Podemos usar un Sandbox, un firewall personal u otros controles (de preferencia preventivos como los ofrecidos) que le permitan al usuario común dejar de decidir si un archivo es “sospechoso”.

En fin, estos fueron algunos de los consejos que llamaron mi atención. La lección –creo- es que no debemos de aventar consejos ambiguos a los usuarios y sí usar nuestro sentido común para revisar bien lo que estamos diciendo; yo mismo he caído en esta trampa al asumir que el usuario a quien me dirijo es un CISSP.

Por otro lado, a algunos no les late poner “marcas” en su blog o artículo, pero las “marcas” pueden apoyar nuestras ideas o consejos. Tal vez se valga decir que no navegues en sitios inseguros y que puedes usar NoScript, por ejemplo. Así si no queda claro lo de “sitios inseguros”, al menos le estás dando un consejo claro y preciso de usar una herramienta. En fin, aquí siempre está el tema de “me pagan para poner marcas” que yo simplemente ignoro.

Si te das un tiempo de leer los consejos del nic, creo que coincidirás conmigo en que su concepto o lo que quisieron transmitir es valioso. Pero la ambigüedad y no ponerse en el lugar del usuario promedio a quien supuestamente van dirigidos los consejos, no fue muy atinado. ¿Tú qué opinas?