La (in)seguridad del software

Hace unos meses leía en la web de Bruce Schneier un artículo en el que hablaba de la responsabilidad -o irresponsabilidad- de los generadores de software (por “generadores” me refiero a programadores, empresas de desarrollo, analistas, etc.) en la seguridad de la información. Bajo mi punto de vista, el software -en especial las aplicaciones- fallan. Fallan y mucho. Y demasiado. No únicamente desde el punto de vista de seguridad -que también-, sino incluso desde el punto de vista de la funcionalidad. Y lo peor, es que todos lo asumimos como algo habitual, como lo más normal del mundo, y como decía Schneier, incluso parcheamos nosotros mismos las aplicaciones (algo impensable con un coche, por ejemplo).

¿Por qué falla el software? Mi opinión es que en términos generales el software falla por cuatro grandes motivos; los comento, sin ningún orden particular:

La incultura de la seguridad
Muchos programadores (por programadores no me refiero únicamente a los que pican código, por supuesto) carecen de una cultura de seguridad a la hora de trabajar; simplemente no se tienen en cuenta los requisitos de seguridad de una aplicación, de un producto, ni en sus fases iniciales, ni en su implementación, ni en sus pruebas, ni en nada. El único objetivo es que funcione (hoy en día, ni siquiera que funcione rápido), que sea bonito (recuerden aquello de programa=algoritmo+marketing) y, en ocasiones, que sea tecnológicamente interesante. Poco más. ¿Seguridad? ¿Yesoqués?

El desconocimiento técnico
Incluso teniendo en cuenta la seguridad en el diseño o en la especificación de un programa, a la hora de implementarlo el desconocimiento técnico del programador hace que se cometan fallos garrafales en el código que, si no son corregidos a tiempo, acaban comprometiendo la seguridad de la información con la que tratan. No creo que valga la pena ahora hablar de errores habituales como buffer overflows o condiciones de carrera, pero alguna pregunta: ¿cuántos desarrolladores conocen el término TOCTTOU? ¿cómo se comprueban los datos que devuelve una orden del sistema? ¿qué alternativas a system() existen?

Las empresas de desarrollo
Una empresa siempre busca beneficios, y la seguridad es algo que no se ve. En ocasiones, los beneficios generados por un desarrollo seguro no se perciben desde la Dirección, por lo que en muchas empresas únicamente se busca la funcionalidad de las aplicaciones para obtener beneficios de las mismas. Dicho de otra forma, no se invierten los recursos necesarios en garantizar la calidad del software generado, únicamente se busca que la aplicación funcione y que se pueda liberar una nueva versión cuanto antes. Adicionalmente, una empresa de desarrollo no suele decir que no a nada. ¿Reprogramar la página web para poner una zona privada que enlaza con una base de datos externa? Para mañana. ¿Cifrado? Bah, no hace falta… Imaginad que necesitáramos un coche anfibio, con alas, reforzado, blindado y capaz de transportar 20 toneladas consumiendo menos de cinco litros. En un concesionario nos tomarían por locos, pero en una empresa de desarrollo nos dirían “Para mañana”. Ojo, un programa open source no suele tener la presión comercial detrás, y tampoco está libre de errores (le afectan por supuesto el resto de factores comentados aquí).

El error residual
Finalmente, incluso evitando todos los problemas anteriores, hay un porcentaje de errores que es inevitable; ese porcentaje es, a día de hoy -y de nuevo bajo mi punto de vista- demasiado alto en el desarrollo de software, y por supuesto debe reducirse a toda costa si queremos hablar de desarrollo seguro. Mientras no consigamos minimizar ese porcentaje de errores residuales, estaremos hablando de un problema serio, inimaginable en otros productos de uso masivo y diario.

¿Cómo evitar los problemas anteriores? No vamos a descubrir nada nuevo, obviamente, pero con algo tan sencillo como aplicar lo que ya sabemos, podríamos reducir, en un porcentaje muy significativo, el número de problemas de seguridad de las aplicaciones. En primer lugar, requerimos de formación e información; parece vergonzoso que en muchas facultades y escuelas de informática se hagan pocas referencias a la seguridad (si nuestra especialidad es Software, sustituyan el “pocas” por “ninguna”). Siendo así, ¿qué esperamos? Ni cultura de seguridad, ni conocimiento técnico, por supuesto. Y cuando hablamos de la dirección de la empresa, peor aún: la falta de cultura de la seguridad hace -no siempre, afortunadamente- que no se vean los beneficios que genera un desarrollo seguro. Si todos fuéramos conscientes de tales beneficios, otro gallo nos cantaría.

Finalmente, y hablando ya del error residual, creo que un factor decisivo para reducir el porcentaje de fallos es aplicar técnicas de ingeniería al desarrollo, algo que en la práctica se hace más bien poco (por mucho que en la carrera nos lo hayan explicado N veces). ¿Por qué? Eso sería seguramente material para muchos otros posts, más polémicos que este :)

La fiabilidad del proveedor de seguridad

Por todos es conocido el hecho de que el mejor producto que pueda fabricarse, o servicio que pueda proveerse, necesita de una gestión de marketing para su promoción en el mercado al que va dirigido; por bueno que sea, un producto o servicio no se vende si no se da a conocer. La labor del personal de este departamento, tantas veces infravalorada por otras áreas de la empresa es la que da vida a la misma, mediante la promoción de productos y servicios para la obtención de contratos y pedidos por parte de los clientes. Esta tarea es casi siempre callada y confidencial, con el objeto de evitar que otros competidores puedan estar informados de las posibilidades de negocio de la compañía, y sólo cuando una contratación se produce, se anuncia, anuncio que casi nunca transmite de manera evidente el esfuerzo que ha requerido la venta, y más aún en el caso de nuevos clientes.

Sin embargo, en todos los sectores existen factores que el personal de Marketing no ignora y que son decisivos a la hora de valorar las posibilidades de obtener un contrato con un cliente. En el caso que nos ocupa, los servicios de seguridad, hay una serie de componentes que facilitan o complican la presentación de ofertas y sus posibilidades de éxito, y que posteriormente serán los que condicionen la satisfacción del cliente y su fidelidad.

Inicialmente, el cliente valorará el producto o servicio ofrecido, y verá si satisface sus necesidades. En caso de ser así, pasará a valorar al proveedor que se lo ofrece, para lo cual evaluará la infraestructura de soporte de la que el proveedor dispone, las ventajas particulares que le aportaría dicho proveedor frente a otros (valor añadido), y considerará el nivel de satisfacción que otras empresas o clientes usuarios del mismo servicio puedan aportarle como referencia. En definitiva, lo que está haciendo es contrastar la fiabilidad del proveedor antes de realizar la contratación.

Es aquí donde la gestión interna del proveedor, su estructura, su eficacia y su coste van a jugar un papel importante para que el posible cliente juzgue conveniente o no depositar su confianza en él. Además, la información que un cliente satisfecho o insatisfecho puede aportar en estos casos es clave para la obtención de nuevos contratos, y podemos decir que en ese instante, se está valorando sobre todo la fiabilidad y actitud del personal que presta el servicio, mas que la marca o nombre de la empresa proveedora.

Entrando en materia, en lo que concierne a servicios de gestión y seguridad de la información, la actitud de los empleados que prestan el servicio, la calidad de los procesos que intervienen en el control de problemas y solución de los mismos, el tiempo de respuesta y duración de los incidentes, así como la posible repetición o desaparición de estos, son factores clave a la hora de valorar los servicios de un proveedor, y serán transmitidos por el cliente “experto” al “futurible” de una forma positiva o negativa, de acuerdo a su situación y nivel de satisfacción con dicho proveedor.

Por ello, el personal de soporte resulta, más en ocasiones que otras personas igualmente vitales pero menos visibles, un elemento crucial en el posible éxito o fracaso del área de servicios de una empresa, tanto por parte del proveedor de dichos servicios (fundamental) como por parte del equipo interno del cliente. Al fin y al cabo, ambos van a menudo de la mano, y el entendimiento y colaboración entre ambas partes llevará al éxito o fracaso del servicio, con independencia del nivel de gravedad de los incidentes que se produzcan; al respecto, suele ser más lesiva una permanencia repetitiva de incidencias de bajo nivel a la que nadie presta la debida atención, pero que comprometen a empleados del cliente, que un incidente de nivel alto solucionado con prontitud, ya que siempre pesará más el día a día que la situación excepcional, sin negar la importancia que tal hecho tenga.

Para que el equipo de soporte alcance el nivel de prestaciones y desempeño que de él se espera, será también necesario organizar internamente el equipo, definiendo roles y responsabilidades (job descriptions), medios de medición de cumplimiento, etc., pero también facilitando herramientas eficaces y claras a los responsables del servicio, de modo que cada cuál sepa qué debe hacer en cada caso, y cuales son las soluciones que puede aportar. Para ello, métodos, procedimientos y políticas serán fundamentales, no bastando con redactarlas y publicarlas sino que será necesario un entrenamiento y puesta al día periódicamente, para alcanzar una alta fiabilidad. En este asunto, el trabajo planificado, los controles de errores, la inspección y test preventivos son fundamentales, pero también la permanencia del personal en su puesto (baja rotación), preservando la experiencia y el conocimiento necesario, tanto sobre su entorno de trabajo como sobre el de los clientes a los cuales presta el servicio. Todo ello proporcionará un importante incremento en la eficacia del servicio.

Es pues necesario recalcar que la labor de venta de un servicio y la contratación del mismo no son artes que una empresa pueda desarrollar sin tener una base de soporte bien asentada y un personal eficaz y responsable que conozca la importancia de su trabajo y lo crucial de sus relaciones con los clientes. La seguridad de los servicios, como en tantos otros negocios, no es solamente un tema técnico sino que está influenciada por un factor humano que los condiciona enormemente.

En 37 años como proveedor y cliente de servicios de seguridad y gestión de la información, he visto toda clase de problemas, graves y menos graves, resueltos con prontitud o con dificultad, pero siempre el factor de confianza en el equipo humano que daba el soporte ha sido crucial en la toma de decisiones posteriores y en la valoración de nuevos contratos. Formación y titulación de los técnicos son factores que generalmente no están al alcance del posible cliente, pero eficacia, disponibilidad y confianza son términos que se manejan con claridad a la hora de que un responsable de contratar un servicio haga una propuesta a la dirección de su empresa. Para ello, siempre contrastará otras experiencias antes de decidir y por ello, de nuevo el personal que presta el servicio es una de las claves de éxito.

La pirámide de Maslow de la Seguridad

Como se puede leer en la Wikipedia, la Pirámide de Maslow es una teoría psicológica propuesta por Abraham Maslow en su obra de 1943 “Una teoría sobre la motivación humana” (A Theory of Human Motivation). Maslow formula en su teoría una jerarquía de necesidades humanas y defiende que conforme se satisfacen las necesidades más básicas, los seres humanos desarrollan necesidades y deseos más elevados; en esta jerarquía, en el segundo escalón -justo por encima de las necesidades básicas para sobrevivir-, aparecía el concepto de seguridad en todos sus ámbitos: lo que necesitamos, una vez sobrevivimos, es tranquilidad.

Según Maslow, en la jerarquía propuesta, las necesidades más altas ocupan nuestra atención sólo cuando se han satisfecho las necesidades inferiores de la pirámide; las fuerzas de crecimiento dan lugar a un movimiento ascendente en la jerarquía, mientras que las fuerzas regresivas empujan las necesidades prepotentes hacia abajo en la jerarquía (algo a tener especialmente en cuenta en estos tiempos de crisis).

Con el tiempo, la pirámide de Maslow se ha extrapolado a ámbitos mucho más amplios que la psicología humana. En concreto, en el mundo de la seguridad, hay algunos artículos que tratan de asimilar la pirámide a niveles de seguridad o de confortabilidad conseguidos en la organización (focalizados muchos casos en la seguridad informática), únicamente bajo la perspectiva del grado de seguridad implantado. En este post hablaremos de la pirámide de Maslow de la SEGURIDAD global en las organizaciones, pero desde un punto de vista diferente: nos centraremos, como hizo Maslow, en las necesidades o deseos en cada una de las fases jerárquicas de la pirámide.

Asimilando esta pirámide a la seguridad, podemos definir un primer escalafón -la base de todo- que podríamos denominar AUTOPROTECCIÓN. En el mismo, nos interesa la seguridad y la protección de nuestros activos, pero no invertimos recursos en dicha protección; dicho de otra forma, nos dejamos llevar, aplicando las salvaguardas mímimas para sobrevivir: no cruzamos la calle cuando hay tráfico, no introducimos virus en nuestros ordenadores, cerramos nuestra oficina con llave…

Por encima de la autoprotección encontramos el DESCONTROL; en esta fase ya “sobrevivimos”, y nuestra necesidad o nuestro deseo es cubrir los aspectos de seguridad que van más allá de la mera supervivencia. Para conseguir este deseo, implantamos -o mejor dicho, permitimos que se implanten- unos controles mínimos en base al criterio personal de miembros de nuestra organización, sin mayor estructura ni coordinación. Así, nuestra seguridad depende por completo de las personas que tenemos en nuestra organización, de su buen hacer y de sus intenciones; en muchos casos, si esas personas dejan de trabajar con nosotros, sus actividades sencillamente se pierden.

Más allá de la anterior, encontramos la fase de CONTROL; aquí ya no dejamos nuestra seguridad en manos de un grupo de personas sin coordinación, sino que velamos para que el trabajo de estas personas sea correcto y reproducible, y para que esté correctamente identificado y coordinado. En la fase anterior necesitábamos cierto control para coordinar las actividades que, relativas a seguridad, se venían ejecutando en nuestra organización, y eso es lo que hemos introducido en esta fase de la jerarquía; ya no permitimos que las tareas de seguridad se hagan “porque sí”, o porque un técnico decide en un determinado momento que nos hace falta un sistema de CCTV, sino que todas siguen un hilo conductor coordinado relativamente y con un fin concreto: la protección del negocio.

Por encima de la fase de control, tenemos la de AUDITABILIDAD; en nuestra seguridad hemos superado el control, y nuestro próxima necesidad es por tanto garantizar, aparte de que las cosas se hacen bien y de forma organizada, que son trazables y un tercero (o nosotros mismos) puede analizarlas para comprobar su eficacia y su eficiencia. Así, estamos consiguiendo no sólo hacer las cosas bien, sino que los demás puedan comprobar que las hacemos bien (y con esto no nos referimos únicamente a la certificación de un sistema de gestión por parte de un tercero, sino que nos referimos a cumplimiento de estándares de auditoría interna, financiera, etc.).

Finalmente, como cúspide de esta pirámide de Maslow que nos hemos inventado, encontramos la GESTIÓN de la seguridad. No sólo garantizamos el control y la trazabilidad de nuestra seguridad, sino que además la gestionamos de forma correcta y buscamos siempre la mejora continua, por ejemplo siguiendo un ciclo de Deming; si nos centráramos en seguridad de la información, esto significaría un SGSI correctamente implantado y mantenido, pero viendo más allá de esta seguridad, la etapa de Gestión significa que invertimos los recursos necesarios en gestionar de forma correcta nuestra seguridad corporativa, tanto física como lógica, legal u organizativa.

Pirámide de Maslow de la Seguridad

Como vemos en nuestra pirámide, nuestro estado en materias de seguridad podemos ubicarlo en alguno de los escalones anteriores, y en función de donde nos encontremos, planificar el ascenso de forma ordenada, por supuesto en base a los recursos de los que dispongamos y de los plazos que necesitemos cumplir.

Para acabar, una pregunta: ¿en qué escalón de la pirámide os ubicaríais?

Herramientas de acceso remoto por conexión inversa

Dentro de las herramientas ciertamente peligrosas (aunque muy útiles en algunas ocasiones), durante estos últimos años se están popularizando las de acceso remoto a los PCs de escritorio, a pesar de que en realidad son muy antiguas y desde siempre han traido importantes problemas de seguridad, como por ejemplo, el Back Orifice (cuyo nombre estarán de acuerdo conmigo que es bastante descriptivo).

Las últimas versiones de estas herramientas que les comento están diseñadas para saltarse todas las políticas de seguridad perimetral implantadas en las organizaciones; por supuesto, el uso de dichas herramientas puede ser perfectamente lícito, pero puede también no serlo (y en ese caso, convertirse en un riesgo de seguridad) si no son controladas y validadas por la normativa de la organización.

La manera de funcionar de estas herramientas es mediante conexiones inversas, de modo que es el equipo interno a la organización el que inicia la conexión hacia el exterior, para luego pasar el control al sistema externo. La manera que tienen de realizar esto es iniciando la conexión, algo que suele estar más abierto o si quieren “permitido” en los cortafuegos. No obstante, en aquellos casos (debería ser en la mayoría) en que las conexiones estén cerradas y sólo se permita la conexión a navegación a través de un proxy, estos programas son capaces de utilizar una tunelización http, saltándose virtualmente cualquier protección perimetral.

Algunas de estas herramientas, que en algunos casos hemos tenido la ocasión de ver en pleno “uso y abuso”, son las siguientes:

Webex: Esta herramienta es utilizada por muchos grandes proveedores de cabinas de disco, de BBDD, etc. Se utiliza mucho en grandes catástrofes en sistemas críticos, ya que permite al especialista que se conecte directamente para resolver la incidencia sin que medie una persona intermedia. En muchas organizaciones grandes con este tipo de equipamiento, y ante la aparición de problemas no siempre críticos, los administradores de estos equipos tienden a habilitan el acceso remoto al proveedor para que le arregle el problema, sin que este acceso se encuentre auditado, controlado y registrado en ningún sitio.

Logmein: Esta herramienta, que recientemente se ha popularizado, hemos tenido la ocasión de verla instalada por algun usuario “espabilado” en su propio PC de oficina para conectarse en remoto (según él, para adelantar trabajo). Este servicio/herramienta tiene grandes funcionalidades, es sencilla de instalar, se pueden realizar conexiones bajo demanda (con lo que se puede uno conectar cuando quiera), pero tiene como riesgo adicional que la empresa que da el servicio también tendria la posibilidad teórica de conectarse.

Zebedee server: Este aplicativo es un tunelizador de IP opensource, con capacidad de tunelizar por http, que permite el redireccionamiento de cualquier puerto, para que sea accesible desde el otro extremo, lo que lo hace prácticamente “a prueba” de cortafuegos.

Por supuesto, existen configuraciones de los proxys, y restricción en los permisos de instalación de software que pueden evitar este tipo de software malicioso, pero no siempre están presentes o se controlan correctamente, y este tipo de aplicaciones de acceso remoto es algo que hay que tener muy en cuenta. ¿Está usted seguro de quien tiene acceso remoto a su organización?

Seguridad y riesgos en las TIC (II)

Seguimos en esta segunda entrada de la serie (ver primera parte) definiendo e introduciendo algunos conceptos básicos relacionados con la gestión del riesgo y la seguridad. Como estrella de la serie, tenemos por supuesto el riesgo, que podemos definirlo como aquella eventualidad que imposibilita el cumplimiento de un objetivo. De manera cuantitativa, el riesgo es una medición de las posibilidades de incumplimiento del objetivo planteado, y en lo relacionado con tecnología, generalmente determina el grado de exposición a la ocurrencia de una pérdida (por ejemplo el riesgo de perder datos debido a avería de disco, virus informáticos, etc.).

La Organización Internacional por la Normalización (ISO) define el riesgo tecnológico (Guías para la gestión de la seguridad de TI /TEC TR 13335-1, 1996) como:

“La probabilidad de que una amenaza se materialice, utilizando vulnerabilidades existentes de un activo o un grupo de activos, generándole perdidas o daños”.

[Read more…]

¡Esto es un escándalo!

Hoy he desayunado leyendo la última entrada de Enrique Dans en su blog, llamada “Trucos para quien depende de Gmail“. En la línea de sus aportaciones habituales, con las que se puede estar más o menos de acuerdo, Enrique aboga por el uso de Gmail para el usuario corporativo, diciendo que:

En las empresas, Gmail ha provocado más de una discusión: no son pocos los directivos y trabajadores que, hartos de las limitaciones de su correo corporativo (de tamaño, usabilidad, acceso remoto, etc.) deciden un día redireccionarlo a una cuenta de Gmail y gestionarlo desde ahí, lo que provoca no pocos escándalos entre responsables de tecnología preocupados por la seguridad y la confidencialidad (escándalos, desde mi punto de vista, completamente estériles e injustificados… desde mi experiencia, es una práctica que recomiendo a cualquiera: Google siempre será capaz de gestionar tu correo mejor de como lo gestiona tu empresa, que no se dedica a esos menesteres como actividad principal).

Creo que no hay nada que añadir al respecto; se siente uno como una pequeña rata de laboratorio paranoica, aunque le queda el consuelo de saber que no lo es. Es razonable que algunas personas piensen, por ejemplo, que la LOPD es excesiva, pero el Reino Unido está empeñada en darnos la razón a los que decimos que no lo es, cuando millones de datos van y “se pierden”. También es razonable pensar que los webmails de Hotmail, Gmail o Yahoo! son sistemas seguros, pero casos como el de Sarah Palin nos dan la razón de que no lo es. Tampoco hay que olvidar las repercusiones de la LOPD en este tipo de servicios; el correo electrónico hoy en día no es sólo un sistema de comunicación electrónica: es también (y cada vez más) un repositorio de documentación. Documentación que incluye datos de carácter personal, informes confidenciales, contratos, ofertas, y muchos otros contenidos de todo tipo. Entiendo la motivación de Enrique Dans, pero es obvio que no la comparto y para ser sincero, me parece una insensatez y jamás la recomendaría a nadie, por muchas razones.

Para acabar con esto, me resulta curioso la mención de que Google gestionará tu correo mejor de lo que lo gestiona tu empresa, cuando un servidor de correo de tamaño medio no es algo tan difícil de gestionar, pero dejémoslo ahí. Si van a la entrada original, encontrarán opiniones a favor y en contra. Aquí (y allí) tienen la mía, ahora háganse la suya.

* * *

En relación con la anterior entrada, el “problema LOPD” de los Palotes de Chiclana, admito que no he dado demasiado tiempo para posibles respuestas, pero creo que el problema no era demasiado complejo. Primero he de decir que la recepcionista, María Antonia Ruíz Pérez, es empleada de Palotes, para no complicar las cosas, y no meternos en rollos de encargados del tratamiento y similares. Y en segundo lugar tengo que decir que el problema admite diversas interpretaciones, y probablemente tenga más de una solución válida; yo personalmente no me siento legitimado para decir que una solución es más correcta que otra, por lo que deberán considerar esta “solución” como mi opinión personal, y en este caso coincido con Javier Cao. Si hubiese alguna discrepancia o error con lo que sigue, les ruego que me lo digan.

Como indicaba Javier, existe una resolución específica en relación con el control de acceso a edificios, la 1/1996 [pdf], que en su norma quinta, “Cancelación de los datos”, especifica que “Los datos de carácter personal deberán ser destruidos cuando haya transcurrido el plazo de un mes, contado a partir del momento en que fueron recabados“. Aunque ésta hace referencia a la LORTAD, y existe una cierta concurrencia de instrucciones con la 1/2006 sobre videovigilancia (pdf) (ver Félix Haro), no se encuentra derogada, y ha sido referenciada en resoluciones de la AEPD posteriores a la LOPD.

Por tanto, tenemos que disponemos de un fichero con una finalidad muy clara (control de acceso) y para el que existe una directiva específica de la AEPD, y al que queremos darle otra finalidad adicional (confirmación de la firma del compromiso de confidencialidad), pero cuyos plazos de conservación son claramente incompatibles. Yo, como Javier, me inclino por un segundo fichero, dado que al mantener el mismo fichero con ambas finalidades, estaríamos incumpliendo la citada directiva. Y esa es, en mi modesta opinión, la solución más apropiada.

En cualquier caso, se admiten correcciones, recursos, y quejas; sólo me queda dar gracias a los participantes y aunque no hay premio, quizá un día les pueda invitar a una cerveza.

“Problemas LOPD” (I): Palotes de Chiclana

Con esta entrada damos comienzo a una serie de posts mediante los que intentaremos presentar situaciones que representan un “problema” (en el sentido más de “examen” del término) para el lector, y que a mi modo de entender pueden aportar luz sobre algunos aspectos de la LOPD. Nada complicado; realmente triviales para cualquiera que esté un poco metido en el tema.

Algunos de dichos “ejercicios” (no puedo evitar ponerlo entre comillas) estarán basados muy vagamente en ejemplos reales, y otros serán simplemente inventados; cualquier nombre de empresa que pueda aparecer es ficticio, como no puede ser de otra manera. Por último, y para finalizar este disclaimer, la solución que se propondrá (no sé aún si en el propio cuerpo pasados un par de días, en una entrada posterior o en el siguiente post de la serie) se facilita según nuestro mejor entender, sin que de ello pueda derivarse ningún tipo de responsabilidad. Dicho esto, vamos con el “problema”.

La empresa Palotes de Chiclana tiene sus oficinas en un quinto piso de la calle Lope de Vega. Para acceder a las oficinas es necesario pasar delante de una recepcionista, que pregunta al visitante sus datos, los almacena en un registro de visitas en papel, y le informa adecuadamente de sus derechos ARCO. Dicho fichero está inscrito en el registro general de la Agencia con el nombre de “Registro de visitas”, y las medidas de seguridad son adecuadas.

Como parte de la obtención de una certificación ISO 27001, la empresa está estudiando hacer firmar a sus visitantes un compromiso de confidencialidad, que se conservaría indefinidamente, por el que éstos se comprometen a no difundir ningún tipo de información a la que tengan acceso, y cuya firma se realizaría en el momento de informarles de sus derechos ARCO. Para ello, han pensado en informatizar el registro de visitas de modo que además del registro habitual de las visitas, un campo adicional indique si ese visitante ha firmado el compromiso de confidencialidad en alguna visita previa, evitando de este modo que tenga que firmarlo de nuevo.

Puesto que los datos de los visitantes y de los firmantes del citado compromiso vienen a ser los mismos, la empresa ha considerado que no existe necesidad de declarar un fichero adicional, ni de modificar el existente. ¿Es correcto?

Seguridad y riesgos en las TIC (I)

Del mismo modo en que para mí fue una novedad entrar en otro nivel del mundo de la seguridad informática, ya que los aspectos de mis anteriores ocupaciones estaban sobre todo orientados a solucionar los problemas que ya hubiesen surgido en los sistemas, periferia y redes, también puede serlo para algunas de las personas que leen el contenido de Security Art Work. Me refiero a responsables financieros, gerentes, directores de departamentos, o simples curiosos por saber de qué hablamos cuándo nos referimos a Seguridad Informática.

Para el resto, los expertos en SI, mis disculpas por entrar en niveles tan básicos, pero a veces se echa de menos un lenguaje más llano, o una definición sencilla que explique aquello en lo que nosotros estamos especializados. También se proporciona una visión global de aquellos aspectos en que la seguridad incide directamente a nivel económico. Lo que publicaré a lo largo de esta serie está extraído en parte de apuntes cuya trazabilidad es imposible resolver, por lo que no menciono autores de los párrafos extractados.

El crecimiento de la tecnología de la información (TI) (También se suele referir en plural: “Tecnologías de la Información”, aunque es mejor referirse a las Tecnologías de la Información y las Comunicaciones (TIC)) en los últimos 20 años ha generado un creciente número de oportunidades así como no menos creciente número de amenazas. Un alto nivel de inversión en tecnología, tal cual existe hoy en día, produce un efecto multiplicador importante en caso que dichas amenazas se materialicen, dado que las pérdidas posibles se ven incrementadas en igual proporción al aumento de la inversión.

Pero no solamente ha cambiado el volumen del uso de la tecnología. También ha cambiado la forma de su utilización. Hoy en día el acceso a los recursos de TIC no está restringido a los profesionales en informática, sino que es accesible para la casi totalidad de la población. A su vez, el acceso a las TIC no se realiza únicamente a los recursos propios, sino que se extiende a otros organismos, sin que exista una frontera física, todo ello gracias a Internet y a la apertura de las redes corporativas, en una magnitud inimaginable años atrás. A su vez, como condición necesaria de todo ello, el grado de complejidad de la tecnología utilizada ha aumentado considerablemente, tornándola cada vez más difícil de administrar adecuadamente, lo cual incluye el control de riesgo para proteger la seguridad.

En este entorno creciente y complejo es dónde los responsables de gestionar las herramientas tecnológicas deben poder diagnosticar adecuadamente los riesgos a los cuales se ven expuestos para poder mitigar de manera oportuna las pérdidas que puedan generarse (que como se ha dicho están relacionadas a la cuantía de la inversión, pudiendo superarla).

Anteriormente, los responsables de manejar los recursos de tecnología eran solamente profesionales de tecnología. Actualmente esto ha cambiado, llevando a profesionales en otras áreas a tener que comprender razonablemente las herramientas y recursos tecnológicos con los cuales cuentan, dado que pueden ser responsables tanto por la gestión integral de las TIC en su organización, como por la gestión de algún componente específico que soporta el proceso de negocio del cual ellos son responsables. Y tras esta breve introducción, es donde comienza, en el siguiente post de la serie, el verdadero meollo de la cuestión: el Análisis de Riesgos.

Rentabilizando los problemas de seguridad

Después de leer lo que hace unos días publicaba Hispasec en relación con la particular forma de Adobe de sacar rédito a los problemas de seguridad, me parece indignante que algunos gigantes de software tengan, dicho en pocas palabras, “la cara tan dura”.

El caso es que en lugar de corregir los bugs de la versión 9, lanzan la versión 10, con algunas vulnerabilidades corrregidas y con alguna “funcionalidad aka vulnerabilidad” nueva. Estando en boga una serie de malware que se beneficia de una “función” (setClipboard) que permite modificar el portapapeles de tu sistema, la compañía libera la versión 10, que además incorpora otra función que permite leerlo. Vivir para ver.

Migren señores, migren. Pero sepan que su seguridad ni mejora ni empeora, simplemente se mantiene (igual de mal).

La LOPD está (aún) muy “verde”

Ya lo dice el título: la LOPD está aún muy verde. Con esto no quiero decir que la LOPD o el RDLOPD necesiten cambios significativos, aunque sí, a pesar de la publicación del nuevo reglamento, siguen existiendo ciertas lagunas, indeterminaciones y ligeras contradicciones; no obstante, a eso ya nos tiene acostumbrados desde hace tiempo la Agencia. Por decirlo de alguna forma, es parte de su idiosincrasia; tiene sus cosas buenas y sus cosas malas, pero la aceptamos con cariño y resignación.

Lo que quiero decir es que casi 9 años después de la publicación de la Ley Orgánica de Protección de Datos (vamos a dejarlo en que la LORTAD, cuyo reglamento salió siete años más tarde de su publicación y fue utilizado como el reglamento de facto de una ley que no tenía reglamento, no cuenta) la adaptación de las empresas a ella es cuando menos relativa. Por supuesto, es significativo el incremento de regularizaciones y adaptaciones en los últimos años, que se reflejan al menos en el aumento del número de ficheros declarados ante el registro general de la AEPD (por algo se empieza). Tampoco hay que dejar de lado el aspecto “motivador” que supone la creciente actividad inspeccionadora y sancionadora de la Agencia; como una vez lo expresó un cliente, la decisión de adaptar o no una empresa a la LOPD puede valorarse en términos de riesgo, y es evidente que la probabilidad de sufrir una inspección ha aumentado en los últimos tiempos, bien sea por inspecciones de oficio, o mayor concienciamiento de la gente, recelosa de sus datos.

No obstante, aunque desconozco cuál es el período de “asimilación social” en el caso de otras leyes, mi experiencia me indica que en general, siguen existiendo bastantes aspectos que exige la ley que se pasan por alto, tanto a nivel de la ley como del reglamento: uso de cifrado, autorizaciones del Responsable del Fichero, registro de accesos en aplicaciones, derecho de información a empleados, firma de contratos con proveedores, envío de publicidad, etc. Muchos de estos puntos se perciben hoy en día como excesivos, y la empresa ni siquiera se llega a plantear su implantación; siguen habiendo empresas (e incluso proveedores con no poca gestión de datos de carácter personal) para las que, sin ningún tipo de mala intención, un contrato de acceso a datos o una cláusula de confidencialidad les parece un innecesario y sobre todo excesivo artificio legal (en la vertiente peyorativa del término).

Pero uno de los puntos en los que aún se percibe con evidente facilidad la falta de autoridad que tiene aún la “invocación” de la LOPD es a la hora de aplicarla a filiales españolas de grupos multinacionales, donde muchas de las políticas, aplicaciones y proveedores emanan y son escogidos por la empresa matriz, sin que las delegaciones nacionales tengan mucho que decir al respecto. A lo largo de mi experiencia profesional he podido comprobar que medidas propuestas como la firma de contratos de confidencialidad o contratos de acceso a datos con determinados proveedores suele ser considerado (si es que llega a considerarse factible) como algo “difícil”, incluso teniendo en cuenta que el ámbito principal de la mayoría de dichas organizaciones es la Unión Europea. Tampoco hay que perder de vista que la LOPD no entiende de grupos de empresas, por lo que si la empresa matriz presta servicios horizontales a la delegación española, deberá firmar un contrato de prestación de servicios y acceso a datos; imaginen por un momento las dificultades de llevar a cabo esa idea o siquiera plantearla en muchos casos. Por último, aunque podría sacar más ejemplos, en muchas ocasiones las aplicaciones escogidas por la matriz para su utilización a nivel global no cumplen las exigencias de la LOPD, una de las leyes más estrictas de la Unión Europea en este ámbito; como es lógico las cosas son como son, y hay habitualmente mucho que rascar al respecto.

Por comparación, mientras que ninguna filial nacional de una gran corporación multinacional se permitiría cometer irregularidades en el ámbito fiscal, en el caso de la LOPD algunos aspectos no insignificantes quedan a menudo abandonados, por falta de autoridad y competencias en unos casos (contratos firmados al más alto nivel, servicios horizontales prestados por la matriz, o aplicaciones globales), y por falta de “interés” o conocimiento en otros: es lógico que la matriz no se preocupe de todos los aspectos legislativos de cada una de sus delegaciones nacionales. Así que en definitiva, uno por el otro la casa sin barrer.

Estoy seguro de que muchas de estas cuestiones se resolverán a medida que la LOPD y sus respectivas leyes europeas vayan cogiendo madurez y los usuarios (clientes, proveedores, personal propio, etc.) vayan adquiriendo conocimiento y conciencia de sus derechos y obligaciones, pero a día de hoy, la complejidad y restricciones impuestas por la LOPD plantea un reto a superar en muchas organizaciones multinacionales con presencia nacional. Afortunadamente, en los casos que he visto, un reto que aceptan gustosas.