Sistema de gestión de la seguridad unificada, ¿realidad o ficción?

prl¿Se han preguntado alguna vez cual es el activo más importante de una organización?

Creo que estaremos de acuerdo que el primero y más estratégico son las personas (sin ellas una organización no funcionaría), pero el segundo y unido a ellas de forma indivisible, es su conocimiento y experiencia, ya que sin ésta, la persona carece de valor estratégico y por lo tanto no es un activo crítico (duro pero real como la vida misma). ¿Qué es el conocimiento y la experiencia sino el conjunto de sucesos e información aprendidos y procesados por una persona a lo largo de su vida/carrera? Por algún motivo extraño, tanto los sistemas de la gestión de prevención de la seguridad y salud en el trabajo (SST), OHSAS 18002:2002, como el sistema de gestión de la seguridad de la información (ISO 27001:2005) contemplan de forma disociada esta realidad, siendo éstas disciplinas las únicas que velan por la seguridad en aras de minimizar los riesgo que afectan a la integridad de las personas y la información.

[Read more…]

No es una feature de Facebook. Es un problema de seguridad.

No me cabe duda de que todos ustedes conocen Facebook. Otra cosa es que lo utilicen de manera asidua; yo personalmente todavía no le acabo de encontrar el gusto. La cuestión es que como saben, si buscan ustedes a alguien dentro de esta red social, no es “amigo” suyo y el perfil de la persona no es público, sólo verán lo siguiente:

faceb

Esto significa, por ejemplo, que no tendrán acceso a las fotos de esta persona, que suele ser uno de los recursos más “codiciados” de este tipo de redes sociales. Eso, en teoría, porque al parecer, según nos enteramos por Mar Monsoriu, y tal y como comentan en Geek The Planet, sí existe una forma de acceder a esta información, a no ser que el usuario haya previsto esa posibilidad previamente (algo que muchos usuarios no hacen). Sigan leyendo.

El (posible) problema

Si le echan un vistazo a la página del usuario de la imagen anterior, verán que debajo de la foto hay un enlace, que dice “Agregar a Oscar a mis amigos”, y que está formado de la siguiente forma:

http://www.facebook.com/addfriend.php?id=XXXXXXXX

donde “XXXXXXXX” es el identificador de nuestro amigo Óscar en Facebook. Este identificador aparece también en otros enlaces, como en “Enviar un mensaje a Oscar”, “Ver todo” o “Denunciar a esta persona”. El caso es que, una vez hemos obtenido el identificador, vamos a la página web para desarrolladores de aplicaciones:

En esa página, seleccionamos “Facebook PHP Client” en Formato de Respuesta, y fql.query en el desplegable de los métodos. Debajo aparecerá un recuadro donde escribir la consulta SQL que queremos aplicar sobre el identificador que hemos obtenido. Aunque es posible obtener otro tipo de información, vamos a limitarnos a los álbumes de fotos. Así pues, escriban la siguiente consulta SQL:

SELECT name, link
FROM album
WHERE owner=XXXXXXXX

Con lo que obtendremos (cuando el usuario tenga álbumes de fotos) una serie de URLs con el siguiente formato:

http://www.facebook.com/album.php?aid=17614&id=XXXXXXXX

Que sólo tendremos que pegar en el navegador para acceder al álbum de fotos.

La (posible) solución

El problema viene motivado por el sistema que Facebook tiene para desarrolladores de aplicaciones, que permite que éstas puedan acceder a algunos datos de los usuarios, si éstos no se han tomado las suficientes molestias. Otra cosa es porqué este tipo de acceso se permite, pero dejemos las reflexiones para más adelante. ¿Cómo evitamos que nuestro perfil sea visible de esta forma?

Pues la solución no está demasiado clara, ya que aunque no es complicada, no tengo claro que sea definitiva. Dentro de nuestro perfil, vamos a “Configuración”, “Privacidad”, “Administrar”, donde tendremos las siguientes cuatro opciones:

faceb2

Si nuestro perfil es “típico” y no hemos cambiado demasiadas cosas, veremos que en las tres primeras opciones todo parece correcto. Aparecemos en búsquedas públicas, pero la información que se proporciona es básica, y en general, nuestra información sólo esta accesible a personas conocidas (“amigos”). Sólo nos queda por tanto ver la parte de “Aplicaciones”.

Al entrar, nos aparecerán cuatro puntos hablando de cómo y cuándo las aplicaciones pueden acceder a tus datos, aunque como hemos visto en el anterior paso, nosotros no somos aplicaciones y sí hemos podido acceder a los álbumes de algunas personas. A continuación vamos a la pestaña “Configuración” de esa misma página, donde nos aparecerá algo como lo siguiente:

faceb3

A partir de aquí les confieso que todo se vuelve algo “borroso”, ya que no he podido hacer bastantes pruebas para determinar la eficacia de los cambios, debido a razones que les expondré luego. Todo apunta a que lo ideal sería marcar “No compartir ninguna información sobre mí a través de la interfaz de programación de aplicaciones (API) de Facebook“, pero en general esa opción aparecerá sombreada debido a que

No puedes rechazar por completo compartir información a través de la Plataforma de Facebook porque actualmente estás usando aplicaciones construidas en esta plataforma. Para dejar de compartir información tendrás que eliminar las aplicaciones que has añadido y retirar los permisos a toda aplicación externa que hayas usado.

Por tanto, deberíamos revisar las aplicaciones que estamos usando, y eliminarlas, y entonces marcar dicha opción, aunque eso puede ser un proceso no sencillo ni trivial para cualquier persona con varios meses en Facebook y un uso medio de la red social. Otra opción sería desmarcar todas las casillas, y guardar cambios, aunque francamente, no tengo demasiado claro que eso vaya a solucionar algo.

Para acabar con esta sección, aparentemente sólo los álbumes que un usuario permite compartir con los amigos de sus amigos son accesibles mediante este procedimiento, y no los álbumes que están bajo las configuraciones de privacidad “Sólo yo” y “Sólo mis amigos”. No obstante, como he dicho antes, esto es una conclusión obtenida a partir de un par de pruebas simples, por lo que podría ser que no fuese cierta del todo. Personalmente, he hecho pruebas con usuarios aleatorios con los que no tengo ninguna relación, obteniendo todos sus álbumes (en otros casos, no he podido acceder a ninguno). Por tanto, les recomiendo no poner fotos que les comprometan en algún sentido, por simple precaución.

Conclusiones

Aunque inicialmente tendía a pensar que esto que les he comentado era una vulnerabilidad de Facebook, tras ver que hay configuraciones de privacidad que pueden evitar el acceso por parte de terceros a través del portal de desarrolladores, no estoy seguro de lo que es, o mejor dicho, de cómo considerarla; aunque sea una “feature” documentada, si viola políticas de privacidad, debería considerarse como un problema de seguridad. Hay varios aspectos que me gustaría destacar:

1. La entrada de Geek The Planet que trata este problema es del 23 de mayo. Han pasado 12 días, y el “problema” continúa, aunque es posible que Facebook no considere esto un problema, sino una herramienta para desarrolladores; lo cierto es que no he visto demasiado ruido al respecto. Esa es, por cierto, una de las razones de la publicación de esta entrada.

2. Aunque el defacement de una página web corporativa, o el robo de determinada información estratégica de una organización son problemas muy graves, pienso que en general, el robo de ciertos datos de carácter personal está en otro nivel. La razón es muy sencilla. Mientras que en los dos primeros casos las consecuencias pueden estar más o menos acotadas en el tiempo y tener un relativo impacto sobre la organización, los datos de carácter personal se caracterizan por su inherente vinculación a la persona, durante toda su vida. Si en una foto salgo yo, no hay manera de limitar temporalmente ese hecho; una página web o un plan estratégico se puede cambiar, pero la foto permanecerá mientras no se destruyan todas sus copias. Ese es uno de los aspectos que a) los usuarios de las redes sociales no acaban de entender cuando cuelgan fotos suyas en Internet, y b) las grandes redes sociales no quieren asumir como responsabilidad.

3. Me preocupa la siguiente afirmación, al respecto de aplicaciones y privacidad:

Todas las aplicaciones deben respetar la configuración de privacidad existente. Por ejemplo, si una aplicación crea una presentación de diapositivas de tus albumes de fotos, y un cierto albúm está configurado para “Sólo mis amigos”, puede mostrarse solamente esta presentación de diapositivas a tus amigos.

Si crees que una aplicación está violando la política de privacidad de Facebook, denúnciala inmediatamente. Puedes hacerlo yendo a la página “Acerca de” de la aplicación y haciendo clic en “Denunciar Aplicación” al final de la página, o haciendo clic en “Denunciar” al final de cualquier área de trabajo de una página dentro de la aplicación.

En concreto, la palabra “deben”. Esto parece implicar que la gestión de la privacidad se deja en manos de los desarrolladores, y que no es impuesta por los sistemas de control de privacidad de Facebook; me resulta bastante extraño, pero eso es lo que dice el párrafo anterior. Además, el hecho de que sea posible denunciar este tipo de violaciones de la política de privacidad por parte de las aplicaciones es la confirmación de que efectivamente, las aplicaciones pueden no respetar las políticas de privacidad de Facebook; porqué esto se permite sobrepasa mi comprensión.

4. Facebook, así como Tuenti, son redes sociales donde abunda los usuarios adolescentes y universitarios. Aunque muchos de ellos están acostumbrados de sobra a Internet, Facebook tiene una variedad enorme, en cantidad y complejidad, de configuraciones de privacidad. Me da la impresión de que las implicaciones de cada configuración no se están trasladando correctamente a los usuarios, intencionadamente o no; es imperativo simplificar, unificar, y explicar qué significa cada opción y quién exactamente va a tener acceso a tus fotos, notas, comentarios, etc. Y esto es generalizable a prácticamente todas las redes sociales.

5. Les decía antes que no sabía si esto era una vulnerabilidad o una feature, pero el caso es que durante la escritura de los puntos anteriores, estoy convencido de que es una vulnerabilidad, por una sencilla razón: he buscado aleatoriamente a alguien en Facebook, y desde la red social únicamente podía ver su foto de perfil; nada más, mientras no me hiciese “amigo” suyo. Entonces he ido a la web de los desarrolladores, y con el procedimiento anterior, he podido acceder a los álbumes (siete) de esa persona, que sin duda ignora que sus fotos son accesibles libremente desde Internet, sin más que aplicar un sencillo procedimiento fácilmente automatizable. No sé si es un problema de comunicación a los usuarios o de implementación, pero sin duda es un problema grave de privacidad, en el momento permite a usuarios externos acceder a información que no es (o no debería ser) pública. Quizá no funcione para todos los usuarios y para todas las configuraciones, pero si eso no es una vulnerabilidad, no sé lo que es.

6. Aunque las políticas de privacidad hablan de aplicaciones, en ningún momento se habla de desarrolladores. Es lógico que las aplicaciones, dentro del marco de privacidad de Facebook, requieran acceder a datos de los usuarios, y en efecto, las aplicaciones solicitan autorización para ello. Pero no es lógico que las propias aplicaciones puedan “saltarse” la configuración de privacidad del usuario y desde luego, eso no incluye a los desarrolladores de aplicaciones. Este punto no sólo no está claro, sino que no se indica en ningún lugar.

7. Por último, como podrán imaginar y seguramente hace un rato que estaban pensando, esto supone una violación del artículo 94.4 del Reglamento de Desarrollo de la LOPD:

4. Las pruebas anteriores a la implantación o modificación de los sistemas de información que traten ficheros con datos de carácter personal no se realizarán con datos reales, salvo que se asegure el nivel de seguridad correspondiente al tratamiento realizado y se anote su realización en el documento de seguridad.

Ya que como hemos podido comprobar, el nivel de seguridad al realizar pruebas con datos reales no se conserva.

Poco más. Mi opinión es que este es sólo el principio; como dijo ?caro Moyano en la XI Noche de las Telecomunicaciones Valencianas, la revolución está por llegar. Tuenti tuvo un episodio similar hace unos meses, en el que —a pesar de lo que decían—, era posible enlazar a imágenes internas desde fuera de la red social. Este problema se ha solucionado (según tengo entendido), pero aparecerán más, no tengan ninguna duda; los usuarios no sólo van adquiriendo destreza informática (sin ir más lejos, aunque en principio Tuenti no deja descargarse fotos, ya hay una extensión de Firefox para “saltarse” la “protección”, por llamarla algo, además de un montón de métodos alternativos), sino que demandan más funcionalidades que introducirán a su vez más vulnerabilidades.

Lo que no hay que olvidar en ningún momento es que estamos hablando de redes sociales con millones de usuarios que comparten datos reales de sus vidas: comentarios, opiniones, hábitos, fotos, etc. Gestionar todos esos datos exige una responsabilidad especial, admitir que son algo más que un montón de información que exprimir publicitariamente, y ser consciente de su importancia.

Personalmente, para serles sincero, no estoy nada seguro de que esa conciencia exista.

* * *

Les recuerdo que hoy finaliza el plazo para el envío de preguntas al consultorio LOPD, que serán contestadas el próximo viernes 12. Nos vemos el lunes.

V OWASP Spain Meeting

owaspEl pasado 15 de Mayo dos miembros del equipo de seguridad lógica de S2 Grupo nos desplazamos a Barcelona para asistir al V OWASP Spain Meeting, donde como siempre pudimos asistir a conferencias de gran interés con ponentes de muy alta calidad:

1. Sintonizar la función de seguridad con el negocio (PDF). Alberto Partida, miembro del Advisory Board de SANS Institute y poseedor de un impresionante curriculum de certificaciones GIAC (entidad de certificación del SANS Institute), nos explicó la manera de compatibilizar los requisitos de seguridad con las necesidades del negocio, y nos explicó algunos trucos para aprender a mostrar la información a los directivos no tecnólogos de tal manera que entiendan a que riesgos se exponen, y nada mejor que ejemplificarlo con ejemplos de incidentes “sonados”. Una charla muy útil para cualquiera que se encuentre en una empresa no tecnológica o que ofrezcan servicios a empresas no tecnológicas.

2. LDAP Injection & Blind LDAP Injection (PDF). Chema Alonso, Consultor de Seguridad en la empresa Informatica64, MVP Seguridad de Microsoft y autor del conocido blog “Un Informático en el Lado del Mal“, nos habló de las particularidades que tiene LDAP Injection con respecto a SQL Injection, que son básicamente el juego de caracteres especiales que se pueden utilizar y el lenguaje, pero que se basa en los mismos principios. Una pena que no pudieramos ver las demostraciones en directo, ya que una caida de su equipo dejó el disco duro inservible.

3. Gestión de Incidentes de Seguridad Web en la Brigada de Investigación Tecnológica (PDF). En esta charla, una de las que la gente mostró más interés con sus preguntas, Jorge Martín, Inspector Jefe del Grupo de Seguridad Lógica del Cuerpo Nacional de Policía, nos explicó como trabajan y a que se dedican en su departamento, una charla muy interesante que despertó la curiosidad de muchos de los asistentes.

4. Extensión de módulos de pruebas de seguridad de la herramienta Webgoat de OWASP (PDF). Daniel Cabezas, de la empresa Ernst & Young, nos mostró diversos módulos que han desarrollado como ampliación de la genial aplicación WebGoat de OWASP para entrenamiento sobre seguridad web, una herramienta imprescindible para cualquier persona que quiera realizar formación en seguridad o que quiera incorporarse al mundo de la seguridad en su vertiente web. Uno de los módulos que creó un poco de confusión consistía en practicar la realización de Buffers Overflow, algo que dada la naturaleza Java de WebGoat despertó las suspicacias de parte del auditorio. No obstante (y eso es una nota para los asistentes al curso que también sean lectores de este blog), cuando Java realiza llamadas a binarios externos para cualquier motivo sí es posible realizar un Buffer Overflow, ya que al realizar la llamada a la función esto sale de máquina virtual java y por tanto de sus restricciones de seguridad, por lo que es posible (y de hecho existen casos documentados) de explotación de vulnerabilidades de Buffer Overflow A TRAVÉS (mejor que “en”) de aplicaciones Java.

En conclusión, los OWASP Spain Meeting son una cita muy recomendable, convirtiéndose en un imprescindible en las conferencias de seguridad en España, algo esperable del excepcional Proyecto OWASP. ¿Nos vemos en la próxima edición? ;-)

Seguridad sectorial (I): banca

dineroCon este post me gustaría comenzar una serie sobre seguridad (problemas, situación, etc.) en sectores específicos de negocio: telcos, museos, espectáculos deportivos… Para empezar, he elegido el sector financiero por varios motivos: en primer lugar, es un sector que creo conocer -más o menos- debido a diferentes proyectos en los que he participado, de problemáticas y tipos diversos (seguridad lógica, convergencia, consultoría…). En segundo lugar, considero que el sector bancario -y por tanto su seguridad- es algo que nos afecta a todos y cada uno de nosotros: el que no sea cliente de un banco o caja, vaya de vez en cuando a una sucursal, saque dinero de un cajero, o acceda a sus cuentas a través de internet, que tire la primera piedra.

El departamento de Seguridad de un banco o caja debe enfrentarse a una problemática muy diversa, que va desde la seguridad del papel moneda o la protección del efectivo a la seguridad en la documentación (cheques, órdenes de pago…), pasando por la seguridad informática, en nuevos canales, en medios de pago, la protección de edificios y personas o el blanqueo de capitales. El sector bancario está además fuertemente regulado en materias de seguridad; a diferencia de otros sectores, en banca es obligatoria, por ejemplo, la figura del Director de Seguridad en cada entidad con la responsabilidad, entre otras, de canalizar las relaciones de la entidad con FFCCSE. De la misma forma, son de obligado cumplimiento diferentes normas relativas a cajas de caudales, cámaras acorazadas o blanqueo de capitales que en otros sectores -con excepciones- ni siquiera nos planteamos.

Con el paso del tiempo, el panorama de la seguridad en banca ha cambiado de forma radical, seguramente más de lo que ha cambiado la seguridad en otros sectores. Hasta los años ochenta,el principal problema de las entidades eran los atracos, en una época dura a todos los niveles (salíamos de una transición, las actividades terroristas eran abundantes y virulentas…); con el tiempo -y el esfuerzo de mucha gente de los departamentos de seguridad de los bancos y cajas- este problema se ha minimizado, y hoy en día me atrevería a decir que un atraco, por supuesto siempre que no haya víctimas, no deja de ser uno más de los problemas de seguridad de la banca, pero no el principal. Bajo mi punto de vista, en la actualidad son mucho más preocupantes los delitos relacionados con blanqueo, medios de pago (skimming, lazos…) o nuevos canales (phishing, pharming…), entornos que pueden causar más perjuicios (tanto en dinero robado como en imagen) a cualquier entidad.

Tanto las amenazas e impactos a considerar en el sector, definiendo riesgos que de una forma u otra debemos mitigar y que afectan al negocio desde puntos muy diferentes, como la situación actual de la seguridad en bancos y cajas, motivan que nos encontremos ante un panorama que hace de la banca un sector en el que la seguridad debería converger por uebos. No obstante, esto no siempre se consigue, y solemos encontrarnos tres situaciones en cuanto a convergencia en las entidades españolas:

  1. Seguridad global, en la que se gestionan todos los ámbitos de la protección del negocio por igual, delegando evidentemente cada operativa particular en grupos de trabajo determinados.
  2. Seguridades aisladas, en las que diferentes grupos se preocupan únicamente por los problemas que les afectan de forma directa; dicho de otra forma, Nuevos Canales no considera que un atraco sea un problema para ellos, y Medios de Pago no quiere ni oir hablar de los problemas de la banca por Internet.
  3. Seguridades colaborativas: diferentes “áreas de seguridad” con responsables independientes, pero con un paraguas común a todas ellas, por ejemplo un subdirector general que es capaz de aglutinar a dichas áreas bajo su mando.

Sin duda, el primer punto es -IMHO- el deseable y al que todos tratamos o tratan de llegar; no obstante, las cosas no se suelen hacer de hoy para mañana y, como siempre que se habla de convergencia, nos encontramos barreras muchas veces insalvables: guerras de Taifas en la organización, sensaciones de pérdida de control, estructuras rígidas que no pueden ser modificadas… problemas que sin duda se acabarán resolviendo, pero que motivan que en banca muchas veces se hable de “miniseguridades” y no de Seguridad.

(Imagen original de Roby© en Flickr)

1er Consultorio LOPD

Hasta el próximo viernes 5 de junio a las 15h, Security Art Work inicia el primer consultorio online sobre la LOPD y su Reglamento de Desarrollo, a cuyas cuestiones el equipo de consultoría y auditoría de S2 Grupo contestará en la entrada del próximo viernes 12 de junio.

En ningún caso se publicarán datos de carácter personal (correos electrónicos, nombres de empresas, etc.), ni se contactará con los remitentes de las preguntas, salvo que éstos lo autoricen expresamente. Pueden remitir las preguntas a openlopd@argopolis.es o indicarlas en los comentarios.

Temeridad, ignorancia o ambas cosas.

monoEsta mañana, cuando he abierto el correo, tenía en el buzón personal una propaganda de KIA enviada desde la dirección “net@netaselot.com”. La imagen que contenía redireccionaba a la URL “http://www.netfilia.com/contenidos/ redirect.html?img=1& contenido=16986&web=40426&id=hiDsTT1z4FrUQ“, que redirecciona automáticamente a la página “http://www.pruebakia.es/?CAM=ANTEV3”. Es decir, KIA.

El pasado viernes recibí una propaganda exactamente igual, pero esta vez anunciaba a iBanesto. Enviada desde la misma dirección, la imagen que contenía apuntaba directamente a “http://www.netfilia.com/contenidos/redirect.html? img=1&contenido=11684&web=40426& id=hi4MOp9u5Wopw“, que es una redirección para “https://www.ibanestocambiodehipoteca.com/?idm=5uss-y8mj”. Es decir, Banesto.

Ambos correos contienen al pie una leyenda que dice lo siguiente:

Si no quiere recibir más información clic aquí

El tratamiento de los datos de carácter personal, así como el envío de boletines o comunicaciones comerciales realizadas por medios electrónicos, son conformes a la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal (B.O.E. de 14 de diciembre de 1999) y a la Ley 34/2002, de 11 de julio, de servicios de la Sociedad de Información y de Comercio Electrónico (B.O.E. de 12 de julio de 2002).

Me sorprende que empresas de la talla y reputación de KIA y Banesto utilicen el envío de spam para captar clientes, pero aun me sorprende más que lo hagan a través de empresas que no conocen ni respetan —a pesar de lo que dicen— la LOPD. Supongo que alguien en KIA y en Banesto pensó que si el correo no lo mandan directamente ellos, no pasa nada. O quizá el responsable que gestionó, compró o encargó la campaña con Netfilia se dejó aconsejar, convencer, o directamente se desentendió de cómo la empresa de publicidad iba a tratar su marca. Mal hecho, en cualquier caso.

La cuestión, que no nos cansamos de repetir, es que Internet no es una fuente de acceso público, y por tanto no puede ser utilizada para recolectar correos a los que enviar publicidad. Estas son el tipo de cosas por las que en mi opinión la LOPD impone sanciones tan fuertes; no se trata de desproporcionalidad, sino de efecto disuasorio; de evitar que las empresas hagan el balance de lo que gano (clientes) y lo que pierdo (sanción de la LOPD). Ahora bien, el que decida saltarse las reglas, ignorarlas, u obviarlas, que se atenga a las consecuencias, porque como saben el desconocimiento de la ley no exime de su cumplimiento y a estas alturas de la película ya no vale hacerse el tonto.

Los enemigos de los parches

parchehuevoEl parcheado de los sistemas informáticos es una de las medidas mas importantes de seguridad que deben seguirse e implantarse en cualquier organización. Recientemente hemos podido ver como grandes organizaciones gubernamentales han sufrido incidentes de seguridad por propagación de gusanos, que podían haberse evitado en gran parte de una manera sencilla simplemente aplicando los parches. Si están pensando lo mismo que yo, se preguntarán cómo es posible que cualquier usuario domestico mantenga actualizado su equipo siempre que sale una vulnerabilidad y en estas organizaciones no apliquen el parcheado de manera correcta.

Francamente, no tengo la respuesta a la pregunta, pero en esta entrada pretendo hablar de cuáles son los problemas a los que los administradores TIC se deben enfrentar cuando tratan de implantar políticas de parcheado. A estos problemas los voy a llamar “Los enemigos de los parches”, que les detallo a continuación:

Ausencia de política de parcheado. Si una organización no se plantea de manera consciente que debe actualizar sus sistemas, es muy posible que no se actualicen, o se actualicen sólo las cosas que sean automáticas. E incluso en este último caso, las actualizaciones automáticas si no se controlan pueden dar lugar a problemas de funcionamiento, compatibilidad y reinicios no programados.

Solución: Instáurese una política de parcheado y actualización de los sistemas, que contemple horarios, personal, procedimiento, y que como siempre deberá de venir aprobada por dirección.

No disponer de herramienta de inventario. Obviamente, si no se sabe lo que se tiene es difícil mantenerlo actualizado.

Solución: Adquiera e instale un software de inventario automatizado, y no permita la instalación de nada que no se gestione con las actualizaciones automáticas del sistema (o que no venga autorizado por el Departamento de TI).

No disponer de herramienta de alerta por parches. Los actualizadores automáticos, como los de Microsoft, cada vez están mas implantados, pero no cubren todo el software. En estos casos, ¿quién esta al tanto de que no aparezca una nueva vulnerabilidad en la BBDD Oracle o PostreSQL? ¿O en el plugin de foros instalado en el portal?

Solución: Debe enlazarse el inventario de software con las alertas de los fabricantes, si no es posible de una manera automática, de una manera manual.

Software que no es base del sistema operativo. Todos los sistemas operativos disponen de un sistema de paquetes con los que es relativamente sencillo saber si hay actualizaciones, pero ¿qué pasa con otros productos instalados que no están en esa lista? ¿Alguien se preocupa por ellos?

Solución: Disponer de inventario automatizado de software, que incluya no sólo los paquetes del sistema, sino también otros paquetes adicionales. Asumo y reconozco que esto no siempre es sencillo, pero vale la pena hacer el esfuerzo; por ejemplo, piensen ustedes de como tener un inventario automatizado de BBDD Oracle en entorno Unix. Para entornos Microsoft, es especialmente recomendable utilizar WSUS (Windows Server Update Services), que facilita las actualizaciones distribuidas y la aplicación de políticas progresivas de instalación de parches.

Productos de terceros incompatibles con los parches o sin soporte. Dicho de otra forma: tengo que poner el Service Pack 2 en un servidor Windows que tiene ademas una aplicación crítica del Call Center de la cual no tengo ni soporte ni el contacto de la empresa, y que si actualizo igual deja de funcionar. Cosas terribles como “Ese equipo no lo parchees que lleva el SCADA”.

Solución: Es necesario disponer de un contrato de soporte con todos los aplicativos que tenga, no sólo por los parches sino por cualquier problema que pueda tener; este aspecto debería contemplarse contractualmente y formalmente en el momento de la compra. Esto puede implicar que debido a una actualización se deba contratar los servicios de productos de terceros.

Software hecho a medida. Este es un caso especial del anterior, pero que tiene más complejidad si cabe, ya que es relativamente sencillo contratar a una empresa para que te dé soporte de un producto comercial, pero es más complicado el disponer de soporte de desarrollos (si no se tienen en un primero momento).

Solución: Deben tenerse ese contacto, ya que si no es por el parcheado, en algún otro momento tambien lo necesitará. Esto obviamente tendrá un coste económico asociado, y debería contemplarse contractualmente y de manera formal en el momento de la compra.

Ausencia de entornos de preproducción. Por muy inocuo que te diga el fabricante que es un parche, lo mejor es probarlo antes de implantarlo en producción. El problema es que en muchas ocasiones este entorno de preproducción ni esta, ni se le espera. Después de todo, ¿quién tiene un entorno de preproducción del servidor de Call Center? ¿Y del SCADA?

Solución: Para aquellas aplicaciones críticas de negocio, defina y adquiera un entorno de preproducción, o utilice para la aplicación de parches aquellos sistemas menos críticos cuyo entorno es similar.

Equipos con escasa conectividad. Un problema frecuente a la hora de parchear son aquellos equipos que no disponen de una buena conectividad. Por ejemplo ¿cómo se parchean los equipos portátiles de los comerciales que solo se conectan por 3G y VPN? ¿O cómo se parchean los portátiles que nunca se usan porque están guardados siempre en un armario? ¿Y esos sistemas que carecen de salida a Internet?

Solución: La gestión de inventario y parches debe ser capaz de detectar equipos que no se hayan conectado y no estén actualizados, forzando la actualización, aunque sea acercándolos al servicio de soporte. Asimismo, en algunos casos puede ser necesario descargar los parches del fabricante desde una máquina con conectividad y aplicarlos manualmente.

Islas o Reinos de Taifas. Todos conocemos algún caso: “las políticas de parches se aplican en todos los equipos, menos en los del departamento de I+D, que se lo gestionan ellos mismos por su idiosincrasia particular”.

Solución: Implántese la política de manera que cubra todos los casos y excepciones posibles, dado que no hay que olvidar que un equipo infectado en el departamento de I+D puede afectar a toda la organización, y eso no será “culpa” de I+D.

Ausencia de administración centralizada. No va a ser posible gestionar los parches de equipos que no estén administrados de una manera centralizada. Esto parece de perogrullo, pero es uno de los principales problemas en entornos pequeños o medianos, o en organizaciones en las que tienen delegaciones pequeñas que son gestionadas de manera independiente por la ausencia de personal técnico especializado en cada una de ellas.

Solución: Deben implantarse herramientas de gestión centralizadas, inventario, distribución de software, acceso remoto, etc…

Estas y muchas otras cosas más deben de tenerse en cuenta cuando se implantan políticas de parcheado en las organizaciones, por lo que queda claro que, lejos de lo algunos puedan pensar no es una tarea estrictamente técnica, sino que viene apoyada por procedimientos, políticas y a veces, mucha mano izquierda.

(N.d.E.: La foto está sacada de Sociedadanonima.org, un extravagante blog donde estuve escribiendo un tiempo.)

Premio a Blog promotor de las TIC

valenciasiComo ya les he dicho alguna que otra vez, cualquier blog que se precie tiene derecho a una dosis periódica de autobombo, ombliguismo o como quieran llamarlo. Al fin y al cabo, los blogs, o las bitácoras si prefieren el término castellano, no serían lo mismo si no sirviesen para alimentar el ego de su autor. Si además sirven para algo más, tanto mejor. Y si hay una razón de peso para hablar de uno mismo, entonces es todavía mejor, porque no es necesario justificarse, algo que acostumbro a hacer a menudo. En breve verán cuál es esa razón de peso; sigan leyendo.

Comencé en esto de los blogs hace aproximadamente cinco años y medio, con un blog personal que aunque empezó tímidamente, en ciertas épocas tuvo una frecuencia de actualización más que decente. No obstante, Security Art Work, en la mitad de tiempo, blog del que soy editor y principal colaborador, ha conseguido muchos más lectores y suscriptores de los que yo aspiraba para el mio personal. Eso me hace sospechar que quizá algo o alguien me esté sugiriendo que lo que tengo que contar de mí no resulta tan interesante como lo que tengo que contar de mi trabajo, al menos para el resto del mundo. Por si los números no fueran evidencia suficiente, hoy hemos recibido el premio al Blog promotor de las TIC de la 11ª Noche de las Telecomunicaciones Valencianas 2009, lo que es la razón de peso de la que les hablaba al principio y algo que, como diría aquél, me llena de orgullo y satisfacción.

Este blog comenzó a gestarse a comienzos de 2007, cuando algunas personas de S2 Grupo empezamos a pensar que podría estar bien montar un blog corporativo que hablase de seguridad. Digamos que el nacimiento no fue coser y cantar, dado que como es bien sabido por cualquier blogger, los contenidos no surgen de la nada y requieren un esfuerzo nada despreciable, pero lo cierto es que el parto no fue particularmente doloroso, y no hizo falta ni siquiera tirar de epidural. Todo fue bastante suave, lo que no significa que fuese fácil; buscar tiempo para escribir entradas en una agenda ya de por sí bastante apretada no es fácil, y si no, que se lo pregunten a muchos de mis compañeros. No hubo lágrimas ni crujir de dientes, pero sí sudor.

Cabe decir, en honor a la verdad, que la dirección de S2 Grupo apoyó en todo momento una propuesta que, cómo negarlo, tiene un retorno de inversión extremadamente difícil de cuantificar, hasta el punto de que la publicación de un blog puede considerarse en la mayoría de los casos casi una tarea altruista. Por supuesto que cualquier blog que sea respaldado por una empresa tiene sin duda una componente clara de marketing, pero creo que evidente que siempre hemos intentado (y creemos que conseguido) que Security Art Work se mantenga libre de contenido publicitario y comercialmente independiente de la empresa que lo respalda con medios tecnológicos y humanos. Más allá de un puñado de menciones esporádicas y siempre pertinentes, casi podría decirse que, desde el punto de vista de una teórica finalidad comercial, Security Art Work no es más que el blog de un grupo de personas que trabajan para S2 Grupo, y en efecto, parte de las entradas son elaboradas por sus autores en su tiempo libre; porque no pensarán que los fines de semana estoy en la oficina, ¿verdad?

Security Art Work es, como bien indica su nombre, un blog sobre seguridad; qué les voy a contar a estas alturas de la película… Sobre seguridad entendida como convergencia de aspectos lógicos, físicos, organizativos, y legales, lo que ineludiblemente lo lleva más allá de lo que muchos consideran “Seguridad”, porque no sería lógico limitar el ámbito del blog a una única temática, a un único ámbito de la seguridad, siendo que la seguridad es, sin duda alguna, un “meta-ámbito” con presencia en prácticamente cualquier proceso que quieran pensar, en cualquier ámbito que se les ocurra. No es necesario mirar muy lejos para darse cuenta de que la seguridad, entendida como tener un conocimiento consciente de los riesgos de Internet, es un aspecto que es necesario fomentar en nuestra sociedad, donde cada vez más Internet tiene un lugar preferente.

No se trata de engañar a nadie; en aspectos técnicos, Security Art Work no pretende (ni puede) ser el último recurso informativo para una empresa que, por ejemplo, quiera virtualizar sus servidores corporativos; al respecto, existen infinidad de fuentes especializadas cuya información es mucho más precisa y detallada que la que nuestro blog podría contener. No obstante, eso no quita que podamos servir de punta de lanza, de “primer vistazo” a diferentes tecnologías que pueden no ser conocidas para el lector. Más allá de estos aspectos técnicos, es en las entradas de opinión y gestión donde consideramos que aportamos una información y visión que no es común en los blogs que existen sobre seguridad, aunque por supuesto, siempre hay excepciones (Javier Cao, entre otros, es una buena muestra de que las hay). Por ello, aunque la publicación en Security Art Work está, como en cualquier otro blog y por razones obvias, restringida al personal de S2 Grupo, contamos con la presencia periódica (aunque irregular y menos de la que me gustaría) de “artistas invitados”, que forman parte de la comunidad de interés común en Seguridad de la Información en la que S2 Grupo se desenvuelve. Hasta el momento, hemos contado con las colaboraciones de Dña. Ana Marzo, socio fundador del bufete de abogados que lleva su nombre, y de gran prestigio a escala nacional en el ámbito del derecho en nuevas tecnologías, D. José Ignacio Ruiz, IT Manager de Aviva Servicios Compartidos, y con amplia experiencia en la gestión TIC, o Francisco Benet, consultor técnico con amplia experiencia en el campo de las tecnologías.

Cuando Guardiola ganó ayer la Champions League, parecía que todos los años ganase una, e insiste una y otra vez en que el mérito no es suyo, sino del equipo; las malas lenguas dicen que es falsa modestia, pero francamente, yo no me lo creo. Por supuesto, afortunadamente para H&M, el Barcelona no gana todos los años la Champions League, y eso lo sé yo que soy culé. Nosotros tampoco ganamos todos los días premios por este blog, pero aun sabiendo que —y esta es mi pequeña galletita para el ego— este blog es lo que es en gran parte gracias a mí, lo cierto es que sin las personas que colaboran día tras día, tampoco sería posible. Y eso, de verdad, tampoco es falsa modestia.

No hay mucho más que contar. Lo que ven es lo que hay, y lo que hay es lo que ven. Si vienen de vez en cuando, ya nos conocen; y si no nos visitan, están invitados a hacerlo. Mañana, como no podría ser de otra manera, retomaremos la programación habitual.

(No se pierdan, si pueden, la charla de �?caro Moyano, uno de los fundadores de Tuenti. Ha sido absolutamente deliciosa.)

Seguridad en tiempos de crisis

En estos meses, en los que la crisis (o la desaceleración) planea sobre nuestras cabezas, y a diario vemos cómo empresas de todos los sectores realizan ajustes de plantilla, abren expedientes de regulación de empleo, o incluso echan el cierre, la seguridad juega un papel fundamental para garantizar que el negocio -o lo que quede de él- sobrevive a las vacas flacas… IMHO, la seguridad debe ser una de las cosas en las que el presupuesto de una organización no se reduzca, o se reduzca lo mínimo posible, para garantizar la protección del negocio; de todos es sabido que cuando las cosas van mal, la delincuencia aumenta, y por tanto debemos protegernos mejor. La probabilidad de que en esta época que corremos tengamos un empleado que nos roba información, a la competencia viéndonos como un enemigo a eliminar -en el sentido figurado-, o a una mafia tratando de hacernos un phishing, es muy alta, con lo cual no podemos descuidar nuestra seguridad; es más, yo trataría de incrementarla.

No obstante, cuando una empresa tiene que ajustar al máximo su presupuesto global, la partida destinada a seguridad tiende a reducirse a una mínima expresión. ¿Y qué es esa mínima expresión? Como siempre, depende… Volviendo al post de la Pirámide de Maslow de la Seguridad, la mínima expresión de la seguridad consistirá, posiblemente, en mantenerse en el nivel en el que nos encontrábamos con anterioridad. Nada de mejorar, nada de incrementar nuestros niveles… supervivencia pura y dura. Es más, en muchas ocasiones, si no retrocedemos en el nivel que teníamos, ya podemos estar contentos… Pero, ¿qué es preferible en estos tiempos, tratar de avanzar, o reforzar lo que hemos conseguido? Creo que depende de muchos factores, y en el equilibrio está la virtud… Bajo mi punto de vista, no tiene sentido tratar de avanzar si no podemos reforzar lo que vamos consiguiendo; así, la seguridad sería una especie de galería minera: mucho más importante que alargar el túnel es apuntalar lo que ya hemos avanzado, para evitar un derrumbe. Ojo, con esto no quiero decir -sigan leyendo- que no tratemos de mejorar permanentemente nuestra seguridad con la excusa de la crisis; simplemente que lo hagamos con cabeza (más de la habitual), sabiendo dónde invertimos nuestros recursos, y por supuesto -ahora más que nunca- sin dejar de mirar para atrás, garantizando que la galería está bien apuntalada. Innovemos y busquemos soluciones creativas a nuestros problemas.

Bajo mi punto de vista, uno de los principales errores que en tiempos de crisis todos tendemos a cometer, es limitarnos a aguantar el chaparrón… Si las cosas van mal, es posible que nuestro presupuesto -estemos o no de acuerdo- se reduzca, como el del resto de departamentos de la organización. Pero ese no suele ser el problema: en seguridad hay soluciones para casi todo, y es una obligación del Director de Seguridad obtener la mayor protección posible con el presupuesto del que dispone, innovando cuanto sea necesario, buscando siempre nuevas soluciones, incluso a los problemas de siempre, e identificando correctamente los riesgos asumidos. Hay un proverbio que viene a decir que cuando soplan huracanes, unos construyen refugios y otros construyen molinos. Apliquémoslo a la seguridad, y pensemos qué construimos ante la crisis… quizás nos demos cuenta que, con un presupuesto X en el bolsillo, tomamos unos caminos determinados (mejores o peores) simplemente porque son los habituales o los esperados por todos, sin llegar a plantearnos una alternativa. Para mí, esto es construir refugios, aguantar el chaparrón, y en este mundo si nos limitamos a eso, antes o después fracasaremos.

Finalmente, un apunte: si en nuestra organización estamos notando la crisis… ¿no es un riesgo que deberíamos haber considerado en nuestro último análisis? Llegar a una situación como la actual no es algo que suceda de la noche a la mañana, de forma imprevista, sino que es la consecuencia de múltiples factores económicos, sociales, organizativos…¿Teníamos esta posibilidad contemplada? ¿Teníamos planificado cómo actuar, o en estos momentos nos guiamos por intuición -y presupuesto-? Tengámoslo en cuenta, si no lo hemos hecho ya, para la próxima ocasión (y no duden que la habrá).

Personalidades enredadas

dimHasta hace poco, se preocupaban por su identidad pública sólo los personajes públicos: artistas, políticos, celebridades en general, disponen muchas veces de sus asesores de imagen, sus relaciones públicas, puestos cuya responsabilidad incluye cuidar de la imagen de sus clientes, asegurándose la construcción de un “personaje” que sirva a los fines económicos o al ego de la persona.

No tengo muy claro si, con la proliferación de famosos, el negocio de los asesores ha aumentado o simplemente se las arreglan por sí mismos, pero esto de la identidad pública sigue sin afectar a la mayoría de las personas “normales”, porque nos relacionamos con personas en nuestro entorno físico más próximo y controlamos bastante bien quién tiene acceso a qué información sobre nosotros y qué cara queremos poner ante diferentes personas y en diferentes entornos.

Pero el mundo digital es diferente. Poco a poco, nos estamos construyendo una identidad en la red. Participamos en redes sociales como Facebook, Linkedin o Xing, donde tenemos perfiles públicos y privados. Aparecemos en noticias en medios cuando participamos en algún evento, aunque solo sea en los sitios Web de la organización. Nuestras multas se publican en el boletín de nuestra provincia. ¿Pertenecemos a alguna asociación? ¿Hemos escrito algún artículo? ¿Participado en un foro de nuestra especialidad? Todo ello deja huella en la red y, una vez allí, es muy probable que permanezca durante años, aun en contra de nuestros deseos. Y las nuevas generaciones lo van a tener más crudo, ya que han empezado a tener presencia digital desde bien jóvenes.

Y no tenemos demasiado control sobre toda esa información. Ni planificamos el contenido, ni le prestamos demasiada atención, dejando aparte el puntito de narcisismo que nos hace “googlear” nuestro nombre de vez en cuando.

Sin embargo, esta información construye un perfil en la red que, cada vez más frecuentemente, es consultado por otras personas. Empieza a ser una práctica común buscar información sobre un candidato a un puesto de trabajo o una posible relación personal. ¿Deberíamos empezar a preocuparnos de ese perfil? ¿Qué impacto puede tener una información inapropiada sobre nuestra persona en nuestras relaciones profesionales o en la marcha de nuestro negocio? Puesto que, en mi opinión, es inevitable tener una identidad digital, ¿no debemos ser conscientes de ella y empezar a cuidarla?

(Al respecto, son interesantes los libros de Daniel J. Solove, publicados gratuitamente y que ya hemos mencionado en alguna otra ocasión: The digital person. Technology and privacy in the information age, y The future of reputation: gossip, rumor and privacy on the internet).

(Imagen por FredCavazza.net)