Seguridad y reputacion

Hace dos meses nos enterábamos de que una compañía de antivirus, Symantec, había sido hackeada. Aunque inicialmente la organización sólo reconoció haber sufrido un ataque menor, finalmente reconocieron que parte del código fuente de algunos de sus productos había sido robado.

La semana pasada era otra compañía de antivirus, Panda Security, la que había sido hackeada. En este caso parece que el objetivo ha sido una plataforma externa desde la que se prestan algunos servicios específicos, y el comunicado oficial indica que ningún servicio relacionado con productos, código fuente o actualizaciones se ha visto afectado.

Sea como sea, la realidad es que el daño ya está hecho. La imagen de ambas compañías se ha visto afectada, su reputación como marcas de referencia en materia de seguridad ha sido dañada. Aunque sólo sea de manera colateral, hay servicios (como PandaLabs) que desde el ataque siguen sin ofrecerse. Quizás ninguno de los dos incidentes ha sido portada en medios generalistas, pero dentro del sector, donde quien más quien menos ha accedido a noticias un poco más detalladas, es inevitable que surjan las dudas. ¿Qué grado de aislamiento real tenían los servidores aparentemente "core" del negocio de Symantec? ¿Qué política de claves usa Panda?

Lo difícil no es deducir que la imagen de ambas compañías se ha visto afectada, sino cuantificar el daño sufrido. ¿Cuántos antivirus van a dejar de vender ambas compañías a causa de los incidentes sufridos? Supongo que es una pregunta difícil de responder incluso para estas compañías. ¿Serán capaces de cuantificar económicamente el daño sufrido?

Y ahora pensemos en el mundo mayoritario, en la mayor parte de las empresas del mundo, que no se dedican al sector de la seguridad TIC. ¿Cuántas empresas "normales" son capaces de cuantificar el daño sufrido por un incidente de seguridad? Por mucho que la nueva directiva europea de protección de datos pudiese llegar a exigir el anuncio público de los incidentes de seguridad sufridos (cosa que personalmente dudo que vaya a acabar sucediendo)... ¿Cuántas compañías serían capaces de estimar económicamente el daño sufrido por tener que realizar dicho anuncio? Y si no lo saben hacer... ¿Cómo van a calcular el ROSI? ¿A efectos prácticos, les servirá para algo positivo ese anuncio?

Seguridad y sostenibilidad

El pasado lunes publiqué un post en el Blog de Seguridad de INTECO, en el que introducía brevemente un concepto que creo que en un futuro puede ser una de las estrellas del mundo de la seguridad: la sostenibilidad aplicada a la seguridad de la información. ¿Qué os parece el planteamiento? ¿Qué fallos le veis? Espero vuestros comentarios.

Spanair, malware y gestión del servicio

Aunque a estas alturas seguro que ya habéis oido hablar del tema, parece ser que ha saltado la noticia sobre un troyano que pudo intervenir en el accidente aéreo de Spanair, infectando el sistema que gestionaba los registros sobre incidencias técnicas en los aviones e impidiendo a los técnicos de mantenimiento percatarse de que existían incidencias repetitivas asociadas a uno de los dispositivos que, según parece, intervino en la causa del accidente.

Más allá de los titulares sensacionalistas que hemos podido ver en algunos medios, que poco menos que afirman que el virus fue el causante del accidente, es evidente que cuanto mayor es la dependencia que tiene la actividad humana diaria de los sistemas de información más probabilidades habrá de que un virus informático acabe afectando a dicha actividad, con consecuencias cada vez más imprevisibles. No es la primera vez que en este blog hablo del tema, y de hecho hay una etiqueta específica, seguridad y salud, bajo la que se agrupan esos post. Sin embargo, hoy no tengo intención de profundizar en este caso en cuestión, ya que creo que el nivel de incidencia que pudo tener es bastante relativo (puede contribuir al desastre, por supuesto, pero no creo que sea uno de los factores más importantes, al menos por la información a la que he podido acceder).

Lo que sí que quiero destacar es el concepto ITILero que subyace en el funcionamiento del sistema de gestión de incidencias técnicas de Spanair, y que según parece computa automáticamente una incidencia repetitiva de manera especial (mediante una "alarma"). El funcionamiento es bastante similar a la gestión de incidentes (o alguien prefiere hablar de incidencias?) y su escalado a "problemas" que se utiliza en el mundo de la gestión de servicios TI. También parece que la práctica habitual a la hora de registrar los incidentes permitía demorar dicho registro durante 24 horas, lo que implica que la catalogación como problema puede retrasarse 24 horas. ¿Son esas 24 horas un tiempo aceptable para la detección de problemas originados por incidentes repetitivos? O dicho de otro modo... ¿Debería haberse fijado un SLA asociado al tiempo de generación de una alarma provocada por un incidente repetitivo? Y si Spanair considerase que el tiempo es insuficiente, y que los incidentes deberían registrarse en tiempo real... ¿Cuál sería el coste de la infraestructura necesaria para que los técnicos pudieran registrar los incidentes de forma inmediata?

Con estas dos preguntas lo que quiero destacar es el hecho de que muchas veces, cuando pensamos en gestión de servicios TI, nos limitamos a seguir las prácticas comúnmente aceptadas, sobre todo a la hora de fijar indicadores y SLAs, sin pararnos a reflexionar en las necesidades específicas que puede tener nuestra organización a causa de la actividad que realiza. Sencillamente, el indicador que le conveniene a nuestro negocio no tiene por qué ser un indicador "clásico". Pero tampoco podemos "perder el norte" y subir los niveles de exigencia de los SLAs a valores hiper-exigentes, a riesgo de que el coste asociado a su consecución sea inasumible. Lo que sí debería ser exigible es que las organizaciones estuvieran obligadas a hacer esa reflexión, y que en este caso Spanair pudiera justificar el motivo por el cual sus protocolos de actuación funcionaban de ese modo. ¿Habrá hecho la compañía este ejercicio? Seguiremos atentos a la evolución de los acontecimientos...

Seguridad móvil y percepciones

Hoy quiero reseñar el último de los estudios realizados por el Observatorio de Seguridad de la Información de INTECO, referente a la seguridad y privacidad en el uso de los teléfonos móviles por los menores en España. La verdad es que es uno de los estudios más interesantes que he leído en estos últimos tiempos, tanto por los temas analizados como por la diferenciación de resultados que hacen entre respuestas de padres y de hijos.

El estudio, además de analizar los hábitos de los menores en el uso de los teléfonos móviles, ha analizado la percepción de ambos colectivos frente a 7 riesgos concretos:

1. Uso excesivo y adicción al teléfono móvil
2. Amenazas a la privacidad del menor (como el sexting, o envío de contenidos de carácter erótico/sexual con el menor como protagonista)
3. Acceso a contenidos inapropiados (de carácter sexual o violento)
4. Ciberbullying o acoso entre menores
5. Grooming o acoso de un adulto a un menor con intención sexual
6. Riesgo económico (gasto excesivo, pérdidas económicas, fraude)
7. Riesgos de carácter técnico (virus y spam)

En general, uno de los resultados más significativos es que en todos los casos la gravedad percibida por los padres siempre es bastante más alta que la percibida por los hijos. Tanto padres como hijos perciben como más graves más o menos los mismos tipos de amenazas(ciberbullying, grooming y acceso/uso de contenidos inapropiados), aunque los más frecuentes son, precisamente, los identificados como menos graves. Además, ocurren con más frecuencia de la que creen los padres, y normalmente los hijos no se lo cuentan, a no ser que sean incapaces de resolver la situación por su cuenta.

Viendo las diferencias entre la gravedad percibida, normalmente asociada al impacto, y la frecuencia de materialización de cada riesgo, echo de menos un análisis de riesgos un poco más formal, con el fin de obtener un valor de riesgo final que hubiera permitido compararlos. Por lo tanto, haciendo uso de la licencia con la que está publicado el informe, y utilizando los datos de las tablas 8 y 9, he decido hacer un cálculo sencillo con dichos datos, "calculando el riesgo" como el producto de la incidencia percibida y el porcentaje de personas que atribuyen a cada amenaza una gravedad alta (he tomado sólo los valores correspondientes a las valoraciones dadas por los hijos). Haciendo ese simple cálculo, el resultado sería el siguiente:

Viendo los resultados de la tabla, hay algunos resultados que llaman la atención. El primero de ellos es que el Spam y el gasto excesivo pasarían a ser las amenazas de mayor riesgo, ascendiendo desde las últimas posiciones en la tabla de "gravedad relativa", pero junto a ellas se mantendría el ciberbullying como una de las amenazas de mayor riesgo. También llama la atención el hecho de que los virus para teléfonos móviles, que es la amenaza para la que más soluciones tecnológicas existen en la actualidad, sea precisamente la amenaza de menor riesgo resultante después de este cálculo. ¿Hay algún otro resultado que os llame la atención? ¿Alguien se anima a seguir "procesando" los resultados del estudio? Seguro que todavía se pueden sacar un montón de conclusiones útiles para evaluar el "nivel de seguridad" existente en torno al uso de la telefonía móvil por parte de los menores...

Que medimos?

Esa pregunta es una de las más habituales a la hora de plantearse la posibilidad (o necesidad, en algunos casos) de medir. Y el resultado de esa pregunta es que se acaba midiendo por medir, estableciendo cantidades ingentes de métricas e indicadores que al final no sirven, en muchos casos, para nada. Cuál es el problema? Que la pregunta es incorrecta. La buena debería ser: ¿Por qué medimos?

Muchas veces la gente se olvida del objetivo de la medida. Se intenta medir símplemente porque alguien (un jefe, un cliente) o algo (un sistema de gestión, por ejemplo) nos dice que tenemos que medir. Y claro, cuando las cosas se han "por hacer"... los resultados no siempre son los ideales. Tan difícil es medir "con sentido"? No lo creo. Basta con saber qué resultados queremos obtener de la actividad.

Pensemos en cualquier actividad. ¿Cuáles son los parámetros generales? Primero, obvio pero útil, es si realizamos o no dicha actividad. Una vez que la realicemos, 3 serán los principales parámetros a evaluar: tiempo empleado, recursos dedicados y resultados obtenidos. Fácil, no? Pues a partir de ahí podemos sacar los parámetros básicos a medir.

Primero, si hacemos o no algo, es un parámetro fundamental. Quizás no tanto si es para una sola tarea, pero sí para un conjunto de tareas. ¿Cuántas de las tareas que deberíamos hacer llevamos a la práctica? La implantación es un parámetro básico, pero importante en la realidad. Al menos, si no siempre hacemos todo lo que la teoría dice...

El segundo parámetro es el tiempo. Muy fácil de medir, quizás demasiado fácil. Es un buen parámetro a utilizar, pero a veces se abusa de él. ¿Para qué nos sirve saber cuánto tiempo se tarda en hacer algo? Evidentemente, para compararlo con el tiempo teórico, con lo tardado previamente en hacer la misma tarea y ver la evolución... Útil, sí, pero insuficiente por sí solo. Usemos este parámetro con cuidado.

Los recursos utilizados es un factor clave. La eficiencia es un indicador muy útil, sobre todo si lo usamos combinado con el tiempo (que lo podríamos considerar otro recurso más). Útil pero también insuficiente: necesitamos conocer el resultado de las tareas.

La eficacia es el factor clave a medir. Por sí solo tampoco es suficiente, ya que necesitamos conocer los anteriores, pero es el aspecto diferencial. Conocer el resultado de nuestras tareas contrastado con los objetivos que se deben obtener. ¿Cuáles son estos objetivos? Pueden ser muy variados, pero seguro que hay alguno en cada uno de estos ámbitos: calidad, seguridad, ...

Qué quiere decir esto? Sencillamente, que lo que hay que medir es lo que hacemos. Si queremos conocer la calidad de nuestras actividades, nuestros procesos tendrán que tener indicadores de la calidad de esas actividades. Si queremos conocer la seguridad de nuestras actividades, nuestros procesos tendrán que tener indicadores de la seguridad de esas actividades. Si tenemos un proceso de gestión de riesgos y uno de producción... de cuál de los dos me interesa conocer su seguridad? De ambos. De cuál obtiene beneficio directo mi negocio? Del segundo. ¿De cuál se suelen obtener indicadores de seguridad? Del primero. Y es que a veces la lógica funciona de forma tan ilógica...

En definitiva, si medimos es porque queremos conocer. Y la necesidad de conocer es debida al negocio. Así que no permitamos que nadie convierta esa necesidad de conocer en su propio "negocio" particular...

Desarrollando Métricas

El objetivo de este post es ampliar un poco mi comentario en relación al post de Antonio Valle sobre métricas en su blog.

Como bien dice el citado post, las métricas están de moda. Sin embargo, a la hora de la verdad es difícil encontrar a alguien que tenga claro qué medir y cómo medirlo. Ni siquiera los propios estándares se ponen de acuerdo entre ellos, y hay diversos modelos de métricas. Esta pretende ser una breve guía sobre un modelo flexible y sencillo (espero), que creo que puede ser efectivo:

1. En primer lugar, tenemos que identificar los procesos cubiertos y, sobre todo, qué hace cada uno (para una mayor aclaración sobre procesos, os recomiendo este post, de Jose Manuel Fernández).
2. Una vez que tengamos claro el funcionamiento de cada proceso, tenemos que identificar aquellas situaciones en las que el proceso funciona bien. ¿Por qué decimos que funciona bien? Qué variable estamos identificando como correcta? Aquí tenemos los primeros candidatos a métricas.
3. Cuando ya tenemos las primeras variables identificadas, tenemos que analizarlas. Ver sus interrelaciones, el significado de cada una, su composición y los parámetros que evalúa. ¿Cuáles son los que más nos interesan? ¿Cuáles reflejan de forma clara el principal objetivo del proceso? Tendremos que seleccionar los más adecuados, y ya tendremos las métricas operativas, de cada proceso.
4. A continuación, pensemos en los procesos trabajando de forma conjunta para ofrecer servicios. Si cada proceso viene parametrizado por sus métricas, con los servicios va a suceder algo similar. El proceso a seguir es parecido, aunque con un elemento adicional a tener en cuenta. Van a aparecer métricas compuestas, derivadas de la interrelación de las anteriores, y otras propias del servicio, como entidad de nivel superior.
5. Siguiendo el citado proceso de identificación y selección, llegaremos a escoger las métricas tácticas, que parametrizarán los servicios. Estas métricas serán más generales, estarán más cerca del nivel de negocio que las anteriores. Y si los servicios están estandarizados, algo necesario para el benchmarking, las métricas también lo estarán. Por tanto, aquí ya podemos hacer uso de estándares y guías que nos ayuden en esta identificación.
6. Por último, y si queremos disponer de un juego de métricas completo, tendremos que desarrollar (o integrar) las métricas estratégicas. En este punto no sólo tendremos que identificar los parámetros de nuestros servicios, sino identificarlos y relacionarlos con parámetros de negocio como el rendimiento económico o la productividad. De nuevo, a este nivel nos ayudan los estándares, así como todo el conjunto de indicadores de negocio que, en mayor o menor medida, todas las organizaciones tienen desarrollado.

Por último, sólo señalar que esta es una aproximación botton-up, que parte de la ausencia de métricas para desarrollar el juego completo, de abajo hacia arriba. Sin embargo, en muchas organizaciones ya se cuenta, como he señalado, con indicadores estratégicos, y por lo tanto se puede tratar de usar una aproximación top-down. Para estos casos, mi consejo es que se siga una metodología compuesta, y que sea en el nivel táctico de parametrización de servicios donde se integren ambas aproximaciones. De este modo, será más sencillo identificar los indicadores de negocio con indicadores tácticos, y a partir de ahí encajar las métricas desarrolladas a nivel de proceso. Aunque esto sólo es un consejo...

Saludos

Indicadores y metricas de seguridad

La web ISO27000.es publicó ayer un artículo muy interesante sobre métricas de seguridad. En resumidas cuentas, plantea los conceptos de "madurez" y "calidad de la seguridad" como parámetros principales para la definición de indicadores y métricas. En concreto, los pasos que se deben seguir para implantar un conjunto de métricas de acuerdo a dicho artículo se resume en:

1. Identificar los elementos a medir a partir del índice de la ISO 17799
2. Definir los niveles de madurez para cada uno de los elementos medidos
3. Definir los niveles de calidad para cada uno de los niveles de madurez de cada elemento

De esta forma, tendremos una pareja de valores que, por cada elemento medido, nos informarán del grado de evolución del control y de la calidad con la que lo hemos implementado. Unos valores que, en conjunto, nos pueden dar una imagen REAL del nivel de seguridad de la organización. Métricas que se convierten en indicadores de seguridad. Muy sencillo de entender... aunque me temo que no tan fácil de implantar. Así que lo mejor en estos casos es, como se suele decir, menos hablar y más trabajar. Manos a la obra, y ya veremos cuál es el resultado...