24 noviembre 2008

Crisis y seguridad

Hoy sencillamente quiero referenciar el último post del blog Eddasec sobre los efectos que puede tener la crisis económica sobre la postura de las organizaciones en torno a su seguridad (y a la consiguiente inversión en seguridad). Aprovecho para recomendar el blog, que después de 3 meses de andadura ha demostrado sobradamente la calidad de sus contenidos.

El post en cuestión se titula lo bueno y lo malo de la crisis, y como ya he dicho hace un análisis de las repercusiones que puede tener la crisis sobre la inversión en seguridad de las empresas. Es un planteamiento interesante, ya que analiza ventajas e inconvenientes y lo particulariza para empresas "compradoras" y "vendedoras" de seguridad, con lo que ofrece una visión bastante completa (y creo que acertada) de la situación que nos podemos encontrar en el sector. Un post sin duda interesante, y digno de un análisis con calma. ¿A alguien se le ocurren estretegias de comercialización a partir de este cuadro? ;-)

19 noviembre 2008

Priorizar controles de seguridad

A veces, aquello que nos parece más obvio es precisamente en lo que hace falta incidir. Al menos, a mí en ocasiones me ocurre que tiendo a presuponer unos ciertos conceptos de partida que utilizo para mis exposiciones, y más de una vez he caído en la cuenta de que los problemas de la audiencia son precisamente que no poseen esos conceptos, o que no los han entendido correctamente.

Uno de los casos más repetidos, y no sólo entre los profanos en materia de seguridad, es el de tratar de encontrar algún tipo de criterio estándar para priorizar unos controles sobre otros. Evidentemente, la ISO 27002 (antigua ISO 17799, guía de buenas prácticas en seguridad también conocida como catálogo de controles) tiene un listado extenso de controles de seguridad, y encontrar algún criterio (o alguna guía o ranking, a poder ser) para priorizar unos sobre otros sería una magnífica ayuda. ¿Cuál es el problema?

El problema es que cualquier guía estandarizada va a ser incorrecta. Es completamente imposible dar una respuesta universal a qué controles son más importantes que otros. Es cierto que el sentido común nos puede ayudar a encontrar algunos controles "prioritarios" desde un punto de vista genérico, y la propia ISO 27001 exige una serie de cumplimientos cuya traducción a controles de la ISO 27002 nos puede ayudar a encontrar un subconjunto de controles "preferentes", pero... Un ranking estándar? Imposible.

La razón es muy sencilla. El criterio para priorizar controles de seguridad debe ser el resultado del análisis de riesgos. Será en base a las principales carencias identificadas en materia de seguridad como tendremos que identificar aquellos controles que son prioritarios, ya que serán los que mitiguen los mayores riesgos identificados. Y lamentablemente los análisis de riesgos son distintos en cada organización, ya que los requerimientos y necesidades de seguridad varían enormemente. Por lo tanto, nunca encontraremos una regla general para priorizar los controles, ya que el criterio de priorización varía con cada organización.

Evidentemente, el resultado del análisis de riesgos no es el único criterio a aplicar. Para mitigar un riesgo concreto puede haber más de un control a aplicar. ¿Se puede en este caso usar una regla genérica de priorización? Pues me temo que tampoco, ya que tendremos que tener en cuenta la eficiencia y la eficacia de cada uno de ellos (o, dicho de otra forma, el coste y la disminución de riesgos que produce cada uno de ellos). De nuevo cada organización es quien va a determinar cuánto necesita reducir su riesgo y cuánta inversión está dispuesta a realizar para ello. Es más, un mismo riesgo puede ser mitigado por distintos controles que actúan en distintos ámbitos, y por lo tanto será cada organización quien decida en cuál de esos ámbitos prefiere actuar. Y eso por no hablar de que cada control puede ser implementado de múltiples formas (las que propone la ISO 27002 y muchas otras más), y que por lo tanto la eficiencia y eficacia de cada uno va a depender también del método de implementación que elijamos...

En definitiva, no podemos decir que exista ninguna regla general para priorizar unos controles sobre otros. Tiene que ser cada organización quien seleccione los que más le convienen, llegando a un compromiso final entre riesgo resultante e inversión requerida. Y más allá de la pura lógica sólo nos encontraremos con propuestas más o menos orientadas que lo único que nos garantizan es simplificar y reducir el trabajo de gestión de riesgos a costa de perder efectividad en nuestra gestión de riesgos. Y no querremos descubrir, después de haber hecho un determinado gasto en seguridad, que no hemos sido capaces de mitigar nuestros riesgos, verdad?

18 noviembre 2008

ISO 9001:2008 publicada

Ocho años después ya tenemos una nueva versión de la ISO 9001. A partir de hoy, la nueva UNE - EN - ISO 9001:2008 ya está disponible para su descarga (por supuesto, en español). Sólo 5 días más tarde que la fecha de publicación oficial en ISO, ya podemos consultar la nueva versión de la norma.

No he tenido tiempo de revisar a fondo los cambios, pero aparentemente no son muchos (o al menos no son muy significativos). Distintas referencias en las que se indicaban los cambios entre la versión de 2000 y la versión de 2008 ya estaban disponibles desde hace algún tiempo, y si echamos un vistazo a los mismos podemos ver que son cambios de forma más que de fondo. Aunque seguro que si los miramos con un poco más de detenimiento se les puede sacar bastante más jugo del que parece...

En definitiva, creo que esta nueva versión no hace otra cosa que ratificar el avanzado estado de madurez de la norma, que entra en una etapa de estabilidad en el que probablemente se mantenga durante un largo periodo de tiempo. No obstante, como ya dije en el post anterior, tendremos que estar atentos a otro tipo de referencias capaces de complementar y ampliar (e incluso de reemplazar) el status quo de la gestión de la calidad vigente en la actualidad.

17 noviembre 2008

Que es Calidad

Es muy habitual oir hablar de que las cosas se hacen (o no) "con calidad", y que siempre nos quedemos con la sensación de que el término calidad es algo abstracto, que significa que algo es bueno, pero sin que seamos totalmente capaces de argumentar por qué decimos eso, o cómo de bueno es.

Quien quiera gestionar adecuadamente esa calidad tiene una norma, la ISO 9001, para ayudarle a mantener y mejorar esos "niveles" de calidad. Claro, que si no somos capaces de definir completamente esos "niveles", difícilmente podremos tener claro si los mantenemos o no, o cuánto somos capaces de mejorarlos, no?

La lucha contra esa indefinición es uno de los motivos por los que me gusta el planteamiento de la ISO 20000. Sí, es una norma para gestionar la calidad de los servicios TI, pero... por qué no pueden esos planteamientos ser extrapolables a cualquier tipo de servicios? Yo creo que la filosofía es perfectamente aplicable. Veamos por qué.

La base de la filosofía de esta norma son los acuerdos de nivel de servicio. Es decir, que prestar un servicio con calidad quiere decir lo siguiente:
  1. Definir un servicio
  2. Caracterizarlo en base a parámetros cuantificables
  3. Acordar con el cliente qué nivel va a tener mi servicio (definir un valor a cumplir en relación a cada uno de los parámetros).
  4. Cumplir con los niveles establecidos

Es decir, que la calidad tiene que ser un parámetro medible y prestar un servicio con calidad quiere decir que ese parámetro mantenga el valor dentro de los límites acordados con el cliente. ¿Es esto algo propio de los servicios TI? ¿No, verdad? Por lo tanto, la referencia es totalmente reutilizable.

Pero vamos un poco más allá. Sin que nadie nos diga cuáles deben ser esos parámetros que caracterizan el servicio, la norma sí que nos da una serie de procesos que tenemos que desarrollar. Y cada uno de esos procesos lo que persigue es "cuidar" un aspecto distinto del servicio. ¿Somos capaces de encontrar parámetros de servicio entre esos aspectos? Algunos de los aspectos que tratan son:

  • Disponibilidad
  • Capacidad
  • Coste
  • Seguridad
  • Incidentes
  • Cambios

Es decir, que al menos estos aspectos de los servicios los tenemos que "cuidar" si queremos prestar un servicio "de calidad". ¿No sigue siendo esto aplicable a cualquier tipo de servicio? ¿No podríamos decir que estos aspectos son parámetros mínimos que caracterizan la calidad de cualquier tipo de servicio?

En definitiva, creo que la ISO 20000 lo que permite es llevar a cabo una aproximación específica al concepto de calidad de un servicio, y que por lo tanto puede ser una buena referencia para gestionar la calidad de cualquier tipo de servicio en el que queramos pensar. Ahora ya podemos tener un poco más claro qué es eso de la calidad...

12 noviembre 2008

Metodologias de Analisis de Riesgos

Hoy simplemente quiero hacer un repaso de las distintas metodologías específicas de análisis y/o gestión de riesgos que existen actualmente. No va a ser una lista exhaustiva, pero creo que servirá para la reflexión.


En primer lugar tenemos las normas que versan sobre el análisis de riesgos. Entre las más conocidas podemos encontrar:
  • AS/NZS 4360:2004: Norma australiana para la gestión de riesgos (en general).
  • BS7799-3:2006: Norma británica para la gestión de los riesgos de seguridad de la información.
  • ISO/IEC 27005:2008: Norma internacional sobre la gestión de los riesgos de seguridad de la información. Distinta a la anterior, aunque también sirve para dar cumplimiento a la ISO 27001.
  • UNE 71504:2008: Norma española que recoge una metodología de análisis y gestión de riesgos para los sistemas de información. No es equivalente a las anteriores, ya que esas eran para seguridad de la información.

Pero no sólo disponemos de normas de análisis de riesgos, también existen metodologías ampliamente reconocidas y de uso generalizado. Las principales son:

  • MAGERIT, metodología española de análisis y gestión de riesgos para los sistemas de información, promovida por el MAP y diferente a la UNE 71504.
  • EBIOS, metodología francesa de análisis y gestión de riesgos de seguridad de sistemas de información.
  • CRAMM, metodología de análisis y gestión de riesgos desarrollada por el CCTA inglés.
  • OCTAVE, metodología de evaluación de riesgos desarrollada por el SEI (Software Engineering Institute) de la Carnegie Mellon University.
Y no son las únicas. Para el que quiera conocer alguna más, tanto en la web de ENISA como en la web de ISO27000.es podéis encontrar más información sobre metodologías de análisis de riesgos.

En definitiva, existe una gran variedad de metodologías, muchas de ellas con reconocimiento internacional, pero lamentablemente todas distintas. Es cierto que, como metodologías de análisis de riesgos que son, todas se parecen, pero no se puede decir que sean compatibles de entrada. Cada una tiene sus particularidades, sus puntos fuertes... y será trabajo de quien quiera utilizarlas el saber sacar lo mejor de cada una de ellas.

10 noviembre 2008

El catalogo de servicios

Parece mentira que algo tan aparentemente sencillo como contar "a qué te dedicas" suponga, en la práctica, tantos problemas. No sé si en todos los ámbitos pasará lo mismo, pero en concreto en el sector de TI es algo realmente complicado.

Con el fin de aclarar un poco esto del catálogo de servicios TI y cómo se elabora encontré hace algún tiempo este enlace que quiero compartir con vosotros. Habla del menú de TI, y cuenta cómo se parece un catálogo de servicios al menú de un restaurante. Las claves que me gustan son:
  • El restaurante publica el menú. Yo añadiría que es un menú con platos del tipo "alta cocina", de 4 líneas por plato en el que figuran todos los ingredientes, incluso los decorativos.
  • No se explican ni la receta ni los utensilios utilizados para elaborar cada plato.
  • El cliente tiene cierto margen para personalizar el plato. Yo añadiría que este margen debe estar acotado e incluso estipulados los costes de cada variación, en caso de que los tenga. Y hago una pregunta capciosa: un plato de carne con una salsa o con otra es el mismo plato, o son dos platos distintos?
  • Se permite llamar al chef si algo no va bien (y claro, el chef sale y atiende al comensal, tanto para una queja como para una felicitación).
  • Y sobre todo, no olvidar que el menú hay que desarrollarlo pensando en el cliente, no en el cocinero. Lo importante no es si son platos de preparación rápida o si se requiere más o menos pericia para prepararlos, lo que importa es que el cliente tenga claro qué quiere y cómo elegirlo (entrantes o platos fuertes, carnes o pescados, calóricos o "sanos", o cualquier cosa que le pueda interesar al cliente, no al cocinero).

En definitiva, que si la cocina es un arte, y comer un placer... habrá que empezar a aprender de los grandes chefs, y preparar "alta cocina" en los departamentos de TI.

05 noviembre 2008

Invertir en seguridad

La semana pasada también leía una noticia acerca de una presentación de un conocido fabricante de seguridad en la que se animaba a las empresas a replantearse las líneas de inversión en materia de seguridad. Según dicho artículo, las líneas que deben guiar la inversión en seguridad son:
  • Centrarse en maximizar la ecuación coste-beneficio en relación a la gestión del riesgo.
  • Integrar la seguridad con la innovación, incorporándola a la fórmula del éxito.
  • Implementar soluciones de seguridad transparentes e intuitivas, de modo que sean lo menos intrusivas posible y permitan a los usuarios centrarse en su actividad de negocio.
  • Orientar las soluciones de seguridad a las amenazas reales en lugar de dejarse guiar por factores como el miedo o el cumplimiento normativo.
  • Centrar el foco de la seguridad en la propia información y su nivel de sensibilidad, en lugar de hacerlo en los sistemas.
  • Orientar la seguridad de forma dinámica en lugar de estática, orientándola por tanto al comportamiento del usuario.

En general estoy de acuerdo con los planteamientos realizados, y la única objeción sería quizás que el cumplimiento normativo no me parece una mala orientación, ya que se puede entender tanto desde el punto de vista del cumplimiento legal o regulatorio, en cuyo caso sería una orientación "obligada", como desde el punto de vista de consecución de un "premio" a la seguridad (certificación u otro tipo), en cuyo caso puede ser una orientación válida desde el punto de vista de beneficios para el negocio derivados del marketing en seguridad.

¿Estais de acuerdo con estas líneas de actuación? ¿Añadiríais o eliminaríais alguna?

04 noviembre 2008

Transacciones seguras

La semana pasada leí una reseña sobre un dispositivo para asegurar las transacciones bancarias que me gustó. El dispositivo en cuestión es un llavero USB cuyo cometido básico es establecer un canal de comunicación seguro entre el propio dispositivo y el banco, a través del cual se visualizan y validan manualmente las transacciones que realicemos, si realmente la información visualizada se corresponde con la transacción que queremos realizar.

Me gusta el planteamiento por varios motivos. El primero de ellos es que coincido con el planteamiento de partida, que supone la utilización, en el extremo del usuario, de un recurso proporcionado por la entidad bancaria que permite garantizar la seguridad de las transacciones. El hecho de que sea la entidad bancaria la que trate de garantizar la seguridad extremo a extremo me parece algo fundamental, ya que supone un incremento en la responsabilidad que el banco está dispuesto a asumir en términos de la seguridad global del servicio proporcionado.

El segundo motivo es que este planteamiento sigue la premisa de que la forma de garantizar esa seguridad extremo a extremo sea mediante el uso de un elemento seguro "per se" y que proporciona toda la funcionalidad necesaria para esa seguridad. En este caso estamos ante un dispositivo hardware externo, pero el mismo planteamiento sería válido con otro tipo de módulo de usuario que fuese capaz de ofrecer las mismas garantías: ser un entorno cerrado y sólo accesible en un extremo por el canal de comunicaciones seguro y en el otro por el usuario. Esto supone, sencillamente, que sea el propio interfaz de usuario el que incorpore todas las funcionalidades de seguridad precisas y que además dicha interfaz sea cerrada al resto de elementos que intervienen en la comunicación, ya que en este caso el equipo de usuario es un simple elemento de comunicación sobre el que opera el dispositivo.

Y el tercero de los motivos es que este planteamiento supone una nueva forma de afrontar este tipo de problemas. Se puede estar o no de acuerdo en si la mejor forma de asegurar una transacción electrónica es validarla manualmente, pero al menos supone una forma distinta de afrontar este problema. Además, en este caso tenemos la ventaja de que no es necesario utilizar un canal de comunicación alternativo como puede ser la telefonía móvil para llevar a cabo esta tarea de validación, lo cual creo que favorece la penetración de esta solución.

En definitiva, un dispositivo interesante. A diferencia del autor del post no tengo muy claro el futuro de su implantación generalizada, aunque al menos espero que sirva de inspiración a los diseñadores de soluciones de seguridad en este tipo de entornos para empezar a pensar en otro tipo de soluciones que realmente sean capaces de resolver de forma más efectiva todas las problemáticas que deben resolver este tipo de soluciones.