Opera 10 Beta “Turbo Experience”… no, gracias.

operaHace un rato he bajado la última versión del navegador Opera, concretamente Opera 10 Beta, en base a las noticias que dicen que es más rápido, más estándar, y más todo. Lo es, casi puedo asegurarlo. Incluida la parte del “todo”, y eso no siempre es bueno.

La cuestión es que dicho navegador tiene un modo “Turbo”, que se activa pinchando en un icono que hay en la esquina inferior izquierda. Quizá esto no sea nuevo para los usuarios habituales de Opera, pero sí lo es para mí. Accediendo al blog a través de Opera, me doy cuenta de que el acceso no aparece proveniente de mi IP privada, sino como procedente de la IP 94.246.126.147. Qué raro. Indagando lo mínimo, veo que:

[Read more…]

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…]

Nmap Scripting Engine (NSE)

insecurelogoEl Nmap Scripting Engine (NSE) es una potente funcionalidad del Nmap que permite la ejecución de scripts, que además permite que los usuarios puedan escribir y compartir scripts para realizar multitud de tareas. El propio Nmap en sus últimas versiones incorpora varios scripts, algunos de los cuales me han resultado muy útiles últimamente. Las tareas que se pueden realizar con el NSE se agrupan en:

  • Descubrimiento de red.
  • Detección de versiones de servicios mejorada.
  • Detección de vulnerabilidades.
  • Detección de gusanos y backdoors.
  • Explotación de vulnerabilidades.

[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.

Una cuestión de resiliencia

muelleEn una charla a la que asistí hace unos meses sobre continuidad de negocio, uno de los ponentes clasificaba los métodos que existían a la hora de afrontar la materialización de un escenario de siniestro en los siguientes:

  • Método israelí: atajar el problema como sea (“enemigo muerto, trabajo bien hecho”).
  • Método americano: desplazar a un técnico al campo de trabajo y hacer un procedimiento. A partir de ese momento el procedimiento es sagrado.
  • Método británico: el que se desplaza es un segundo del técnico (vestigios del Imperio…).
  • Método español: Vamos y lo intentamos arreglar. Después, si podemos, haremos el informe, y el procedimiento….uff, eso ya veremos.

[Read more…]

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.)