28 agosto 2007

Gadget de seguridad

Después de descubrir lo fácil y rápido que se puede copiar una tarjeta, está bien que alguien le haya sacado una aplicación beneficiosa a dicha posibilidad. En concreto, hablo de un nuevo aparatito que he visto referenciado en algunos blogs. Se trata de un pequeño dispositivo compuesto de una tarjeta "virgen" con banda magnética y un lector/grabador de tarjetas con algunas funciones adicionales (pantalla, unos botones y un lector de huellas dactilares).

La idea es que, tras autenticarte a través de tu huella, ese aparato puede guardar en su memoria una "copia" de todas tus tarjetas, y grabar sobre la tarjeta virgen una réplica de aquella que necesites en cada momento (seleccionable a través de los botones y la pantalla). Luego, al volver a guardar la tarjeta dentro del dispositivo, los datos almacenados se borran.

A priori parece un dispositivo interesante. Sobre todo, porque según afirman en la web, también sirve para copiar tarjetas que funcionen con códigos de barras (que luego se visualizan en la pantalla) y tarjetas sin contacto. Vamos, que bastante completito. Pero claro, algunos detalles quizás se podrían mejorar...

El primero es el lector de huellas. Mis experiencias con ordenadores portátiles que incorporan dispositivos de ese tipo no son demasiado buenas. POr otra parte, existen cantidad de "tretas" para burlar este tipo de lectores biométricos... (y por lo que parece, funcionan). Por lo tanto, dos problemas: que el lector de huellas no funcione correctamente (indisponibilidad) o que alguien falsifique nuestra huella (no me paro a analizar los peligros de que te corten el dedo). Y claro, es el único control de acceso que se ha habilitado... Acaso es tan complicado la incorporación de un teclado numérico y el uso de un PIN como control de acceso adicional? Al fin y al cabo, todas nuestras tarjetas están almacenadas en ese dispositivo...

La segunda pega es, precisamente, el hecho de que todos los datos estén almacenados en un único dispositivo. Evidentemente, el riesgo de que te roben "todas" las tarjetas aumenta, ya que sólo tienen que robar un único aparato. Pero lo que me preocupa es que por el momento no he sido capaz de encontrar ningún dato que afirme que la memoria del dispositivo es segura. No vaya a ser que si el ladrón accede físicamente a la memoria del aparato sea capaz de leer la información almacenada...

Y la tercera es que, si nos ponemos quisquillosos, sería interesante que la tarjeta fuese una tarjeta inteligente, y contase con un chip de contacto programable. Al fin y al cabo, es una tecnología que en ciertos ámbitos se está extendiendo cada vez más, sobre todo en formato de tarjeta monedero.

Y por último, una duda. Más de una vez he tenido problemas con las bandas magnéticas de mis tarjetas, que por estar demasiado rayadas no se podían leer. Si esta tarjeta va a ser la única que utilicemos en todos los casos... cuántas veces al cabo del día va a ser leída? Cuál es la vida útil de la tarjeta virgen? Quiero pensar que habrán tenido este dato en cuenta, y que el aparato incluirá más de una...

27 agosto 2007

Gestionando con controles

Hoy toca la tercera (y última) entrega de la serie. Después de revisar las tres dimensiones de un SGSI, y analizar las dependencias entre el alcance y el SoA, hoy toca reflexionar sobre la relación entre la tercera dimensión, la profundidad, y las dos anteriores.

La relación entre la aplicación o no de los controles y su intensidad es obvia. Evidentemente, sólo hablaremos de la intensidad con la que se aplican los controles que sí están aplicados. Aunque también sería posible hablar de la intensidad de todos, si definimos como “intensidad 0” todos los no aplicados. Así podríamos “comernos” una de las dimensiones, y facilitar la representación gráfica…

La relación entre la fortaleza de cada control y el alcance no es directa, y sin embargo es clave en todo SGSI. Esta relación viene a través de una “segunda derivada”: el análisis y la gestión de los riesgos. Es evidente que el análisis de riesgos se va a llevar a cabo dentro del entorno definido por el alcance. Y su resultado son los riesgos que es necesario gestionar. Ahora bien: cómo se deben gestionar dichos riesgos?

En primer lugar, debemos tener claro cual es el máximo nivel de riesgo que admite nuestra organización. A partir de ahí, si existen riesgos que superen dicho umbral, tendremos que seleccionar los controles a aplicar para reducirlos. Estos controles, por supuesto, pueden ser “nuevos” (previamente no estaban aplicados) o pueden estar ya aplicados. Diferencia entre ambos casos? A nivel teórico, ninguna: en las dos situaciones se trata de intensificar un control (de nivel 0 a nivel x o de nivel y a nivel y+x), con el fin de que la reducción del nivel de riesgo sea tal que el riesgo residual quede por debajo del umbral máximo definido.

Cuál es, entonces, la clave para seleccionar una u otra opción? La eficiencia y eficacia de cada una de ellas. De entre todas las opciones (aplicar un nuevo control a, intensificar otro b, o modificar un tercero c, por ejemplo) siempre va a haber una que sea la más barata, y una cuyos resultados sean los mejores. Y lo más habitual es que nunca coincidan. Así que habrá que valorar tanto el nivel de beneficio (reducción de riesgos) obtenido como los costes (inicial, de mantenimiento, de intensificación del control en caso de que se decidiera, …) asociados a cada uno de ellos.

Respecto a la selección de controles, un consejillo. En muchos casos suele ser más barato (y más sencillo) adoptar un nuevo control con “poca profundidad” (de forma manual en muchos casos y/o artesana en la mayoría) que intensificar uno ya aplicado (que habitualmente pasa por la adopción o mejora de soluciones tecnológicas, normalmente más caras). Y en muchos casos puede ser suficiente, sobre todo si tenemos en cuenta que el objetivo debe ser reducir el nivel de riesgo, no “eliminarlo”.

En resumen, vemos que una pieza clave sobre la que se articula la relación entre las dimensiones de un SGSI es el análisis de riesgos, y que su adecuada gestión va a ser un punto clave para conseguir un SGSI que se adecue a nuestras expectativas. No es una conclusión sorprendente, verdad? Al fin y al cabo, por algo es uno de los requisitos de la ISO 27001.

Y es que, en el fondo, todo se resume en lo mismo: conoce tu entorno, analiza y gestiona sus riesgos, y aplica el sentido común.

21 agosto 2007

Alcances globales

En el anterior post dejaba pendiente analizar las dependencias entre las dimensiones de un SGSI. Hoy me voy a poner con ello, analizando sobre todo una de estas dependencias, y haciendo un pequeño alegato contra-corriente: la apuesta por alcances “globales” para un SGSI.

Las dependencias naturales entre el alcance y los controles implementados son muchas. Es cierto que es posible definir un alcance “a medida” en el que pasemos por alto estas dependencias “naturales”, y librarnos en gran medida de dichas dependencias, pero es a fuerza de “inventar” límites y de poner puertas al campo. Y claro, el resultado más habitual suele ser la aparición de una burocracia exagerada y, sobre todo, antinatural ligada a estas fronteras artificiales.

Pero… de qué estoy hablando exactamente? Veamos:

  • Los controles relativos a la seguridad del personal (A.8) normalmente suelen ser actividades desarrolladas por el área de recursos humanos.
  • Los controles relacionados con la gestión de terceras partes (A.6.2, A.10.2) normalmente suelen recaer en las actividades que lleva a cabo el departamento de compras.
  • La seguridad física (A.9) en muchas ocasiones corre a cargo del departamento de recursos generales.
  • Las tareas que tienen que ver con controles técnicos (A.10 – A.12) suelen quedar en manos del área de informática interna, y repartidos entre los distintos departamentos en los que se suele subdividir (sistemas, redes, microinformática, …).
  • La verificación de todo lo relacionado con los aspectos de cumplimiento (A.15) suele quedar en manos del departamento de auditoría interna.
  • Y el resto de los controles (si es que se llevan a cabo) normalmente son actividades globales, comunes a toda la compañía, y cuya responsabilidad no suele estar demasiado bien definida.

Y qué ocurre cuando queremos implementar un SGSI cuyo alcance sea únicamente un solo proceso productivo, por ejemplo? Pues que los controles aplicables son, a priori, los del último punto… y todos los demás, ya que en ese proceso también tenemos personas, servicios subcontratados, ubicaciones físicas, sistemas informáticos… Y claro, nos encontramos con el problema de que tenemos que aplicar un montón de controles cuyos responsables “habituales” quedan fuera del alcance.

Cómo se resuelve este problema? La solución más habitual suele ser la creación de una serie de SLAs internos (quizás alguien los conozca como OLAs o MoUs) en los que se regulen las condiciones de seguridad en las que el resto de las áreas prestan servicios al proceso cubierto por el alcance, con una trazabilidad mínima que garantice que dichas condiciones puedan ser verificadas. Y claro, es aquí donde aparece el trabajo “en balde” y la burocratización, ya que hay que mantener unos “contratos” totalmente artificiales, que han aparecido simplemente por la necesidad de regular unos límites virtuales.

Existe otra solución? Yo creo que sí. Sencillamente, ampliar el alcance. De ese modo nos ahorramos la creación y mantenimiento de estos SLAs, y manejamos un alcance más completo y lógico. Evidentemente, la contrapartida es la necesidad de analizar los riesgos de nuevos procesos desarrollados por estas áreas, con el consiguiente aumento de recursos y tiempo necesario, pero creo que el diferencial final no es excesivamente grande, y además estamos cubriendo una serie de procesos en los que la información normalmente suele ser un activo de elevado valor.

Y con esto y un bizcocho… hasta el próximo post. Que todavía queda analizar el resto de dependencias, y este está quedando muy extenso.

17 agosto 2007

Dimensiones de un SGSI

Podemos decir que un SGSI tiene 3 dimensiones. Esto quiere decir que, a la hora de implementarlo, tenemos 3 grados de libertad para definir su "tamaño". Esto nos daría un abanico realmente amplio a la hora de definir su implementación... si no fuera porque, lamentablemente, estas 3 dimensiones no son independientes (ortogonales se llamaba en matemáticas?).

La primera de las dimensiones de un SGSI es el alcance. Tenemos la libertad de decidir el número de procesos (o mejor llamarlos procesos de negocio?) que van a estar cubiertos por el SGSI. Seleccionarlos no es fácil, y en muchos casos es la clave para conseguir un SGSI realmente útil y efectivo. Como se puede comprobar aquí, casi existen tantos ejemplos de alcances como SGSIs... y no todos tienen por qué ser igual de efectivos. En su día ya dejé algunos consejos sobre cómo seleccionar el alcance, que creo que siguen siendo válidos. Es la dimensión "principal", hasta el punto de que debe ser pública, de modo que cualquiera sea capaz de verificar realmente qué partes de la organización están "protegidas" con una gestión segura de la información.

La segunda de las dimensiones de un SGSI es la relación de controles que vamos a implementar. Es una dimensión que aparece reflejada en el SoA (Statement of Applicability, o Declaración de Aplicabilidad), donde se indica al menos la relación de controles aplicados y descartados, junto con su justificación. Su importancia es tal que incluso aparece en las propias certificaciones, aunque en este caso sólo referenciada, ya que se considera que no debe ser una información pública. Pese a ello, yo creo que esta información debería ser accesible para clientes y/o proveedores que nos exijan requisitos de seguridad, ya que es un modo sencillo de que puedan verificar qué medidas de seguridad está teniendo en cuenta nuestra organización (y cuáles no).

La tercera dimensión es el grado de "fortaleza" de cada uno de los controles, el grado de intensidad (profundidad) con el que se está aplicando. No es lo mismo plantear un control de acceso físico visual que uno mediante tarjeta electrónica o que otro que además utilice reconocimiento de retina. Y está claro que es más efectivo disponer de un gestor de incidencias automatizado que mantener un registro manual en papel. Y sin embargo, todas las opciones estarían implementando el control correspondiente. Sin embargo, esta es una dimensión que no sólo no se suele identificar explícitamente, sino que en muchos casos es incluso difícil de evaluar. Y el problema es que es una dimensión clave para optimizar la eficiencia de un SGSI, ya que en muchos casos la inversión requerida para cubrir cada control depende directamente de la intensidad con la que se quiera cubrir...

En resumen, estas 3 dimensiones creo que pueden servir para reflejar de forma sencilla e intuitiva el "tamaño" de un SGSI. Lamentablemente, la representación gráfica del alcance suele hacerse en 2 dimensiones, así que si añadimos las 2 que nos faltan, el resultado puede no ser tan sencillo de interpretar (aunque siempre se podría incorporar una cuarta dimensión en forma de mapa de calor, por ejemplo). Podría ser su representación gráfica uno de los componentes del tan famoso cuadro de mando de seguridad? Quizás la segunda dimensión sea demasiado amplia, pero como propuesta, ahí queda...



P.D.: Y alguien pensará... A qué viene la referencia inicial de que las 3 dimensiones no son independientes, si luego no desarrolla la idea? Es cierto, me queda ese tema pendiente. Pero prefiero dejarlo para otro post, que este ya esta quedando lo suficientemente extenso... y el tema lo merece.

14 agosto 2007

Robos de datos

Todos tenemos claro que, si hablamos de seguridad de la información, nadie está a salvo de tener un incidente de seguridad. Todos nos sabemos de carrerilla el famoso dicho de que la seguridad 100% no existe... Y sin embargo, cuando aparecen noticias como esta, la mayoría nos preocupamos.

En este caso, parece que lo que han robado es un servidor con datos secretos de la policía británica. Y lo han hecho cuando dicho servidor estaba en manos de una tercera empresa. ¿Qué análisis se podría hacer de este hecho en términos de seguridad de la información? Unos cuantos, desde mi punto de vista.

En primer lugar, está el hecho de que exista una subcontratación. No es problemático en sí mismo, siempre que se tomen las medidas adecuadas. Aunque está claro que un secreto lo es menos cuantas más personas/entidades participen en él... Se supone que la policía debería obligar a la empresa subcontratista a cumplir unos estrictos requisitos de seguridad, y del tono del artículo se desprende que esto se cumple, así que primer escollo superado. ¿Se cumplirán todas las premisas y recomendaciones de la 27002 en los apartados de acuerdos con terceras partes? Contemplará el SLA correspondiente las penalizaciones y consecuencias derivadas de este tipo de incidentes?

El segundo aspecto a destacar es el reparto de responsabilidades no sólo por el incidente en sí mismo, sino también de cara a su resolución. La empresa subcontratista parece que ha cumplido su parte (datos protegidos (cifrados?) y copia restaurada), y la policía aparentemente también, como responsable de los propios datos (del artículo original parece desprenderse una asunción de responsabilidades). Aunque... hasta qué punto estaría esto regulado en el contrato?

Y sin conocer nada más que la información que aporta el artículo oficial, me aventuro a pensar que el principal fallo no ha estado en las medidas preventivas, sino en su verificación. La verdad es que no es habitual el realizar "tests físicos de intrusión", pero si estamos hablando de datos de tal sensibilidad, y de una subcontratación por medio, creo que la auditoría por parte del subcontratista de las medidas reales de seguridad que está implementando la empresa subcontratada debe ser obligatorio por contrato. Y sin embargo, es una práctica anecdótica (si es que existe) en la casi totalidad de las organizaciones que conozco...

En resumen, la noticia tiene pinta de ser uno de los pocos casos en los que aparentemente se ha explotado el riesgo residual una vez tratado, ese % restante para llegar al 100% de seguridad. Quiere decir esto que hay que "perdonar" el incidente? Realmente, no. Habrá que vigilar que las medidas de resolución de problemas realmente se llevan a cabo (se corrige la causa subyacente, revisando tal y como afirman toda la seguridad de la compañía), habrá que solicitar la depuración de responsabilidades ante los organismos apropiados (que ya decidirán si el castigo es o no necesario, y cuál debe ser si lo es) y sobre todo habrá que abrir una vía de actuación encaminada a resolver los problemas que pueda causar el uso de los datos robados. El incidente ya se ha producido, pero la diferencia entre una buena gestión de la seguridad y una mala se verá a la hora de verificar el cumplimiento de estos aspectos...

13 agosto 2007

De vuelta

Ha pasado más de un mes desde el último post. La verdad es que tenía pensado escribir un post de despedida pre-vacacional, pero el comienzo del verano se me complicó lo suficiente como para pasarlo por alto... Así que habrá que conformarse con uno de bienvenida post-vacacional.

Tengo que reconocer que me gusta la sensación de que durante las vacaciones "hayan pasado cosas". Saber que el sector se mueve siempre es gratificante, y es una sensación positiva que ayuda a luchar contra la depresión post-vacacional (que probablemente vaya in-crescendo a lo largo de la semana, que hoy lo que realmente sufro son las consecuencias de volver a madrugar).

Así que la ventaja es que hay bastantes temas de los que hablar. De la conversión de ISO17799 a ISO 27002 (por fín!), de la publicación oficial (también al fin) por parte de ENAC de que Applus LGAI ya está acreditada para certificar SGSIs (gracias, Carlos, por tu recordatorio), de que ya se está organizando la II Jornada Internacional del ISMS Forum Spain, ...

Hay muchos temas de actualidad, pero tampoco quiero dejar de lado otros post más "filosóficos", ya que tengo algunos comentarios pendientes sobre gestión de riesgos, integración de sistemas de gestión o continuidad de negocio que me gustaría publicar en este blog. En fin, un poco de todo... Espero que las expectativas se vayan viendo cumplidas poco a poco.

Un saludo a todos,

Joseba Enjuto.