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?

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?