30 abril 2008

Privacidad en la web 2.0

La semana pasada participé en una interesante discusión acerca del uso y difusión de la web 2.0, con una visión orientada a analizar las consideraciones de seguridad y privacidad en la nueva Internet (blogs, nanoblogs, redes sociales, etc). La postura predominante era, en resumidas cuentas, ser cauto con la información personal que se suministra vía web, y tratar de reducir los riesgos de exposición pública de dicha información.



En relación a ese tema hoy he leído un interesante artículo acerca de los riesgos de participar en redes sociales. Un artículo que alerta sobre la necesidad de leer con atención la "letra pequeña" de las cláusulas que aceptamos cada vez que accedemos a sitios web, a ciertas funcionalidades avanzadas o a cualquier tipo de ventaja adicional cuyo uso tenemos que aceptar explícitamente. Porque el riesgo no es ya que ciertos plugins o aplicaciones adicionales puedan saltarse las restricciones que creemos tener, sino que nosotros hemos aceptado explícitamente esa posible vulneración de nuestra privacidad. Y todo por no pararnos a leer con detenimiento las cláusulas antes de hacer clic sobre el "acepto" de turno.



Y es que de fondo el problema que se plantea no es nuevo. Se trata, sencillamente, de confiar o no confiar en la empresa que provee el servicio que queremos utilizar. ¿Por qué la gente confía en eBay para proporcionarle los datos de su tarjeta de crédito, pero no lo hace cuando accede a estafas-on-line.com, si ambas webs funcionan bajo https con certificado reconocido? Sencillamente, porque de la primera se fían y de la segunda no. ¿Han leído las cláusulas de ambas webs antes de decidirse? Probablemente no. Pero como la empresa que hay detrás de dicha web está catalogada socialmente de "confiable", nadie teme por el uso que se vaya a hacer de los datos cedidos. Incluso aunque las cláusulas puedieran (no sé si es el caso) alertar de una cesión de datos a una empresa de desarrollo de perfiles de consumo, por ejemplo.



Un caso que va más allá de la confianza en el depositario de los datos personales es el uso que, de forma automática, puedan hacer terceras partes de los datos "públicamente" accesibles en la web. Ese es otro de los motivos aparentemente esgrimidos para que 8 de cada 10 europeos desconfíe de Internet. En este caso se desconfía de las empresas que disponen de medios para "rastrear" y consolidar los datos de individuos particulares. Ahora bien, ¿Cuántos de esos datos han sido obtenidos directamente por esa empresa, y cuántos "cedidos" por otras? ¿Cuántos de ellos deberían ser privados? Si presuponemos que la "cesión" de esos datos es correcta (el buscador de turno ha obtenido exclusivamente datos públicos, ya que en caso contrario la responsabilidad estaría en manos de la empresa que los ha dejado "accesibles" incumpliendo su política de privacidad), el problema ya no es la privacidad de esos datos, presuntamente públicos, sino de las consecuencias que puede tener su consolidación. Si una determinada persona publica en twitter que está visitando el evento euskalsex, y existe información pública de que dicha persona pertenece a una red social relacionada con la moda, y en concreto con ropa interior infantil... ¿Es posible que alguien pueda relacionar ambas fuentes y deducir algún tipo de asociación con pornografía infantil? ¿Debe el buscador "registrar" estas asociaciones? ¿Qué tipo de confianza debe depositarse en empresas cuyo negocio sea la consolidación de información personal? ¿La característica de pública de cierta información personal debe estar ligada exclusivamente a la finalidad para la que se ha hecho pública?



En definitiva, la privacidad se está viendo expuesta a nuevos riesgos cuya origen está, fundamentalmente, en la des-perimetrización (de-perimeterisation en inglés), o eliminación progresiva de las barreras para el flujo de información, independientemente de que dichas barreras sean necesarias o establecidas a propósito. ¿Nos llevará el futuro de la web 2.0 a un nuevo concepto de privacidad? ¿Seremos capaces de desarrollar soluciones que permitan su pervivencia tal y como hoy la conocemos en un mundo cada vez más interrelacionado? Ya lo iremos viendo...

16 abril 2008

Phishing y responsabilidades

Que los casos de phishing bancario están creciendo no es ninguna novedad. El problema es que sus dimensiones y sus consecuencias están alcanzando tales niveles que hemos llegado a un punto en el que desde distintos ámbitos parece que se considera necesario delimitar las responsabilidades asociadas. Y claro, aquí es donde los distintos interesados no se ponen de acuerdo.

Por una parte, tenemos el caso de los bancos británicos, que quieren que los usuarios de sistemas inseguros asuman su responsabilidad. De acuerdo con el código que han publicado, parece ser que los bancos no asumirán aquellas pérdidas en las que se pueda alegar incumplimiento, por parte de los usuarios, de medidas como tener un antivirus y antispyware actualizado.

Por otra parte, tenemos la postura que expone Julián Inza, que refleja que desde distintos ámbitos se acusa a las entidades financieras de lavarse las manos ante los casos de fraudes electrónicos. Este post afirma que la principal responsabilidad en relación al phishing bancario (y otros delitos electrónicos parecidos) debería quedar en manos de las entidades financieras por no utilizar sistemas de autenticación suficientemente fiables (no sólo técnicamente sino también en relación a su utilización práctica).

Desde mi punto de vista ambas posturas tienen su parte de razón. Es cierto que los bancos deberían desarrollar mejores soluciones de seguridad, y sobre todo hacer un especial esfuerzo en desplegar soluciones utilizables por clientes con muy poco conocimiento informático (y previsiblemente nulo en materia de seguridad informática), pero también es cierto que si no se hace nada por evitar que los equipos de este tipo de clientes se expongan a los principales riesgos automatizados que pululan hoy en día por Internet es casi seguro que tarde o temprano esos equipos acabarán bajo el control absoluto de los "malos" de Internet, y por consiguiente también sus cuentas bancarias. Es por eso que en distintos post he abogado tanto por un mayor esfuerzo en la concienciación pública en torno a la seguridad informática como por el desarrollo de soluciones de seguridad centradas en extremo del usuario, con el fin de potenciar el ya conocido eslabón más débil de la cadena.

Y en relación a estas reflexiones siempre se me plantea una duda. ¿Sería posible aunar una solución para el usuario final proporcionada por la propia entidad bancaria? ¿Sería posible desarrollar un "entorno de trabajo" tipo sandbox, por ejemplo, que se tuviera que descargar el usuario para poder acceder a la banca electrónica, y dentro del cual se pudiera certificar la seguridad de todas las operaciones desarrolladas? Sería una forma de que los bancos no sólo fueran capaces de garantizar la seguridad de las operaciones, sino de que también pudieran asumir las responsabilidades asociadas, ya que el entorno de operación de los clientes sería seguro y más allá sólo quedaría el propio usuario, de cuyas acciones siempre sería responsable. ¿Existen soluciones de este tipo? ¿Hay alguna en desarrollo? Si alguien tiene alguna respuesta para mis preguntas, tiene a su disposición los comentarios.

14 abril 2008

Certificarse en ISO 20000

La verdad es que, desde que se publicó oficialmente la convocatoria para el plan Avanza, el sector no para de moverse. Quien más quien menos ya se ha buscado sus compañeros de viaje, y todo el mundo vislumbra en un futuro más o menos próximo una importante oleada de nuevas certificaciones en CMMI, ISO 27001... e incluso en ISO 20000.

La verdad es que la certificación en ISO 20000 parece la más complicada. Sencillamente, por lo exigente que es su cumplimiento: un completo sistema de gestión, 13 procesos a cumplir, incertidumbre en relación a las herramientas de soporte, muchas trazas que generar... y un máximo de 20000 euros de subvención. No parece un panorama muy halagüeño para que las pequeñas empresas se animen. Y no quedan demasiadas variables con las que jugar.

El principal parámetro para reducir el esfuerzo de implantación de cualquier sistema de gestión certificable es el alcance. En el caso que nos ocupa, su amplitud vendrá marcada por la cantidad de servicios IT (aunque el estándar no defina qué es un servicio IT) que queramos incorporar a nuestro ITSMS. El problema es que la variable principal que condiciona el esfuerzo no suele ser la cantidad de ámbitos sobre los que aplicas la gestión, sino el desarrollo de los procesos de gestión propiamente dichos. En definitiva, que lo costoso es desarrollar correctamente el proceso de gestión de incidencias, y que ese proceso lo apliques sólo a las incidencias del correo electrónico o a las de todos tus servicios IT no supone tanta diferencia.

El segundo problema es que la certificación no nos permite implementar sólo alguno de los procesos. El estándar no ha contemplado que se pueda prescindir de alguno de ellos (lo cual es bastante lógico, ya que difícilmente encontraremos una justificación para no gestionar los cambios o los niveles de servicio, por poner un par de ejemplos), y por lo tanto si queremos certificar que cumplimos una norma tendremos que cumplirla enterita (que yo sepa no hay medias certificaciones para medio estándar, y la norma no define niveles). En este caso los procesos son parte del cuerpo de la norma, y no podemos entenderlos como un catálogo de procesos para seleccionar los que más nos interesen (al estilo controles de seguridad de la ISO 27001). Y son requisitos mínimos, así que no nos vale el recurso de ITIL de implementar sólo las partes que más nos interesan. O cumples la norma, o no la cumples.

¿Cuál es el resultado final? Mucho esfuerzo necesario para cumplir con todos los requisitos. ¿El problema? Que una pyme difícilmente va a ver justificado todo el esfuerzo necesario como para cumplir con una norma tan completa. Y la cuantía de la subvención tampoco es que anime demasiado, ya que aparentemente no responde (al menos, comparativamente) a las exigencias que supone su implementación.

¿Existe alguna solución para "facilitar" y generalizar la adopción de esta norma? Podría ser, aunque en este caso no es inmediata, ya que quedaría en manos de las autoridades de normalización, certificación y/o acreditación y podría no ser del gusto de todos. Como opciones, se me ocurren las de "aligerar" la norma, ser más "permisivos" en su certificación, desarrollar nuevos esquemas de certificación (por ejemplo, por niveles), crear normas derivadas más adaptadas a las características de una pyme... Quizás cualquiera de ellas pueda parecer viable a priori, pero en cualquier caso siempre hay muchos intereses en juego y demasiados protocolos a respetar como para que cualquiera de esas opciones sea factible a corto plazo. Y es una pena, porque creo que si se facilitase de algún modo la certificación de los ITSMS todo el sector saldría beneficiado. ¿Será ese el argumento capaz de acelerar la adopción de alguna solución válida? Espero que sí.

07 abril 2008

Seguridad y salud

En la actualidad existen una gran cantidad de profesionales dedicados a la seguridad de la información. La importancia de su trabajo es alta, sobre todo desde el punto de vista de la salud de la empresa: al fin y al cabo, no hacen sino gestionar parte de los riesgos que pueden poner en peligro la "vida" de una organización. Sin embargo, la trascendencia de una actividad siempre depende de la escala en la que nos movemos, y a la hora de comparar la trascendencia de cuidar la "vida" de una empresa con la importancia que podamos dar a cuidar la "vida" de otros pacientes (la sociedad, el planeta, las personas, etc.), es posible que el resultado no sea tan gratificante como desearíamos (no hay más que echar un vistazo a la pirámide de maslow para darse cuenta de que un médico probablemente sea más valorado que un experto en seguridad de la información).

Sin embargo, el desarrollo de la sociedad moderna ha llegado a tal punto que hay ocasiones en los que ambos mundos llegan a fusionarse. A veces, incluso la seguridad de la información cobra una especial trascendencia para la vida. Sólo hace falta que existan dispositivos electrónicos que condicionen la vida humana, y los marcapasos son un claro ejemplo.

Hace unos días nos enterábamos de que, afortunadamente, los ipods no alteran el funcionamiento de los marcapasos. Parece ser que había dudas de que los reproductores digitales de música pudieran interferir en el funcionamiento de estos dispositivos, y el estudio parece demostrar que esto no es así. Lo que sí que parece demostrar otro estudio es que los marcapasos pueden ser intervenidos vía radio. Las funcionalidades de información y configuración vía radio que incluyen algunos de estos aparatos parece ser que no han sido diseñadas con todas las características de seguridad que serían deseables, lo que según el artículo hace que puedan aparecer riesgos de seguridad que puedan llegar a afectar directamente a la salud del paciente.

Estos son sólo dos ejemplos recientes de que mundos tan distintos como el de la seguridad (security) y el de la salud (health) están empezando a tocarse, de modo que amenazas de uno de los mundos puedan llegar a afectar al otro. Por supuesto que no es el momento de alarmarse, ya que estos dos casos son más anecdóticos que otra cosa, pero... ¿No sería el momento de empezar a pensar en cómo protegerse de este tipo de riesgos antes de que sean realmente significativos?

02 abril 2008

Gobierno de la seguridad

De vez en cuando, y sin tener muy claro cómo, llego a artículos realmente interesantes. Unos por su profundiad, otros por su concreción, otros por la claridad de ideas que presentan... El artículo de hoy es uno de ellos: Hacia un gobierno de seguridad de información. Un artículo no muy extenso pero muy claro en el que se explican los principios del gobierno de la seguridad, y cómo desarrollarlo.

El punto de partida del artículo es que el gobierno de la seguridad se basa en la gestión de riesgos, y que su éxito radica en alcanzar y mantener un nivel aceptable de riesgo. Y para ello, el gobierno de la seguridad debe basarse en 4 principios básicos: alineación estratégica, reducción de riesgos, uso eficiente de recursos y mediciones para verificar los resultados obtenidos.

Según el artículo, el gobierno de la seguridad empieza por el desarrollo de un plan estratégico de seguridad y la articulación funcional de las responsabilidades de seguridad. Una vez desarrollada esta parte, se indica que hay que desarrollar el modelo de gestión asociado, y se propone como referencia el modelo de SGSI que presenta la ISO 27001. Una vez establecido el modelo de gestión, el artículo pasa a analizar la tarea de análisis y gestión de riesgos propiamente dicha , y por último el artículo señala como necesario el desarrollo del SGSI y por tanto el consiguiente desarrollo de indicadores y métricas que permitan desarrollar la gestión de riesgos en forma de ciclo de Demming. Y por último, por supuesto, mantener este funcionamiento.

Así leído la verdad es que parece un proceso lógico y sencillo. Y realmente no tiene por qué dejar de serlo: al fin y al cabo, todo el mundo gestiona riesgos de forma habitual en su vida cotidiana sin prácticamente percatarse, pero cumpliendo perfectamente con todos los pasos que aquí se identifican. ¿Alguien es capaz de poner algún ejemplo? El mío queda pendiente para un próximo post...