26 enero 2009

La trampa de ITIL

Hace algunos años era difícil encontrar organizaciones que supieran lo que era ITIL. Algunas habían oído hablar del tema, otras tenían un conocido cuyo amigo sabía de ITIL... pero en realidad nadie tenía muy claro qué era eso de ITIL, mas allá de que parecía algo bueno y que si lo implantabas en tu organización conseguías que el área de Ti funcionase mucho mejor.


Hoy en día la situación ha cambiado. Quien más quien menos conoce de qué va eso de ITIL, muchos tienen en su organización alguien certificado en ITIL, y todos son capaces de poner un par de ejemplos cercanos de organizaciones que se han metido a implantarlo. Incluso es posible que en su propia organización haya algún proyecto con las siglas ITIL en el nombre, si no uno de implantación de ITIL en toda regla en el que el propio interlocutor esté implicado. A día de hoy, ITIL está de moda.


¿Entonces, cuál es el problema? Teniendo en cuenta que esto de ITIL era algo bueno, sería lógico pensar que la situación de todas esas empresas haya mejorado significativamente, no? Pues... parece que no siempre. Al menos, esa es la sensación que produce hacer este tipo de preguntas y ver cómo tu interlocutor silba, mira para otro lado, o contesta con un "bueno, sí, algunas cosas sí que parece que están algo mejor, aunque la verdad es que en el fondo seguimos como siempre...". ¿Qué es lo que ha fallado?


El mayor error de ITIL suele ser la forma de encarar este tipo de proyectos. ITIL no es más (ni menos) que una recopilación de las mejores prácticas del sector en materia de gestión TIC. No es ni siquiera la mejor empresa real, sino la recopilación de las mejores partes de cada una de ellas. Como cuando alguien quiere "crear" al chico o la chica ideal y coge la boca de uno, los ojos de otro, la nariz del de más allá... El resultado es mejor todavía que cada uno de las referencias de partida, aunque con una pequeña pega: es irreal. ¿Qué ocurre ahora si queremos transformarnos a imagen y semejanza de ese modelo? Ya ni siquiera nos basta con ser como Angelina Jolie o Brad Pitt, ahora ya queremos los labios de Angelina y además las caderas de Shakira. ¿A qué precio? ¿Con qué consecuencias? Y quizás la pregunta más importante: ¿Realmente necesitamos esa "perfección"?


Demasiadas veces se puede ver cómo una organización trata de implantar ITIL. No de buscar en ITIL aspectos de mejora que pueda aplicar a sus necesidades, no. El objetivo no sele ser adaptar ITIL a la organización, sino adaptar la organización a ITIL. En muchas ocasiones, además, a costa de un importante gasto en consultoría y una inversión aún mayor en la super-herramienta de turno para poder automatizar todas las nuevas tareas que toca empezar a desarrollar. Y todo para poder decirle a tus clientes que ahora eres "ITIL compliance" y que van a "flipar" con las mejoras que vas a introducir en tus servicios... para que al final termines viendo que tus clientes te agradecen mucho los esfuerzos pero que te van a seguir pagando lo mismo por los servicios que ya antes les dabas con una relación calidad-precio aceptable para ellos. Y el sobre-esfuerzo que te ha costado la implantación de ITIL... finalmente habrá que amortizarlo por otras vías (si se puede).


La trampa, por si no había quedado claro, consiste en tratar de ser como un ideal inalcanzable. Primero por inalcanzable, y segundo porque el esfuerzo (económico y humano) que puede suponer el intento probablemente nunca compensará el resultado. Lamentablemente, demasiadas consultoras se olvidan de aclarar estos términos, por intereses obvios. Y cada vez es más frecuente encontrarse con organizaciones a las que el proyecto de implementación de ITIL les ha supuesto grandes quebraderos de cabeza, mucho trabajo... y pequeñas mejoras que no suelen justificar la inversión realizada.

En definitiva, sentido común. ITIL es un ideal, una referencia en la que encontrar mejoras aplicables a tu organización, pero en ningún caso un estándar. ITIL no son requisitos mínimos, sino ideales máximos. Ni todas las organizaciones necesitan implementar la seguridad del pentágono (que se supone que es muy elevada) ni todas las organizaciones van a tener el dinero necesario para hacerlo, aunque les viniera bien. Como se suele decir, ten cuidado con lo que deseas... no vaya a ser que se cumpla.

20 enero 2009

Obama y la tecnología

Hoy no podía ser menos: toca hablar de Obama. En realidad sólo quiero añadir unos simples comentarios al post que publiqué no hace demasiado tiempo sobre las implicaciones que puede tener la seguridad en el futuro tecnológico del presidente estadounidense, y que tengo la satisfacción de ver "ratificados" por bloggers mucho más conocidos que yo como Enrique Dans, incluso aunque su enfoque de partida sea tan distinto al mío. Y resulta que unos días más tarde aparece la noticia de que un hacker se ha conseguido hacer con la cuenta de twitter del presidente (electo, hasta dentro de unas horas). Afortunadamente, este hacker no ha sido muy creíble a la hora de hacerse pasar por él, pero... qué hubiera pasado con alguien con mayor predisposición a aprovecharse políticamente de esa cuenta? El primer incidente ya ha aparecido, y puede ser un buen aviso de que existe un riesgo real (y no despreciable) en este ámbito.

También he leído que finalmente Obama no se va a quedar sin conectividad móvil, aunque va a tener que sustituir su BlackBerry por otro dispositivo más seguro, de acuerdo con los criterios de la NSA. Algo previsible y totalmente lógico, desde mi punto de vista. Si no se está dispuesto a eliminar el riesgo (si no hay dispositivo móvil, no hay nada de lo que preocuparse), al menos habrá que establecer las medidas necesarias para mitigarlo. Y seamos sinceros... ¿Alguien considera asumible que la seguridad nacional en USA pueda estar en manos de RIM, una empresa privada, y del nivel de seguridad que sea capaz de proporcionar al servicio que le ofrece a Obama? Nadie que realice un mínimo análisis de riesgos creo que esté dispuesto a que la seguridad de información tan confidencial como la que puede manejar el presidente de Estados Unidos en su terminal móvil pueda ser gestionada mediante una simple transferencia del riesgo a un proveedor de servicios que sea quien la almacena. Lo previsible es bastionar consecuentemente el terminal con las medidas de seguridad que se definan después de realizar dicho análisis, que presumiblemente es lo que han hecho los "chicos" de la NSA. ¿O alguien cree que van a permitir que el terminal que utilice Obama sea un terminal "de mercado" con la configuración por defecto? Por eso me hace gracia ver cómo en algunos entornos se pone el grito en el cielo por pensar que el sistema operativo de ese nuevo terminal pueda parecer a priori más vulnerable. Es como juzgar la seguridad de los coches oficiales por su marca y olvidarse de las medidas de seguridad que les hayan incorporado (blindajes, inhibidores, etc.). Así que no tiene por qué ser tan grave que a Obama le sustituyan su "pamperri", aunque personalmente dudo que le vayan a permitir usar mucho el messenger... y tampoco creo que le vaya a quedar demasiado tiempo para ello.

12 enero 2009

Funcionan los analisis de riesgos?

Desde hace algún tiempo tenía marcado este link, ya que una lectura rápida lo había catalogado como interesante, aunque todavía no había tenido tiempo de leerlo. Un artículo en cuatro partes (I, II, III y IV) donde se cuestiona la validez real de los análisis de riesgos que tanto defendemos en foros como éste.

Al final, el artículo no es tan "transgresor" como parece. Realmente, bajo la premisa de que un análisis de riesgos "bien hecho" sí que es útil, lleva a cabo una explicación completa y con ejemplos de cómo se realiza uno de esos análisis de riesgos. No obstante, sí que hace algunas puntualizaciones que me han gustado mucho, y que paso a enunciar por si en una primera lectura del artículo pueden pasar algo desapercibidas:
  • El objetivo del análisis de riesgos es conocer realmente el nivel de riesgo aceptable con el cual puede vivir una organización, y el de la gestión de riesgos consiste en conocer los riesgos y las alternativas para poder manejarlos.
  • La alta dirección de cualquier empresa tiene la responsabilidad de atender y facilitar lo necesario para llevar a cabo un análisis y evaluación de riesgos (“Due Diligence”).
  • La causa principal por la que fallan los análisis de riesgos es porque su alcance está limitado a las áreas de sistemas y no se extiende a las áreas de negocio o funcionales.
  • Un análisis y evaluación de riesgos debe completarse en semanas, no en meses o años.
  • Un proceso de análisis y evaluación de riesgos efectivo buscará atender las necesidades reales de la organización, e involucrará a los dueños de la información.
  • Después de identificar todos los controles posibles y evaluar su viabilidad y efectividad se debe realizar un análisis coste-beneficio. Este proceso debe ser realizado para cada control, para determinar si el control recomendado es apropiado para la organización.
  • Será necesario crear una lista de definiciones de amenazas, con el fin de que todos los integrantes del equipo estén totalmente homogenizados en la definición de las amenazas.
  • El equipo analizará las amenazas identificadas con un factor de riesgo alto y seleccionará los controles técnicos, administrativos, y operacionales que ofrecerán un nivel rentable y aceptable de protección a los activos.
  • Es importante listar todos los controles considerados y clasificarlos, ya que esto permitirá a la dirección ver lo que fue considerado y lo que el equipo está recomendando como un control adecuado y rentable. También es importante conocer que un control puede reducir la exposición de riesgo de más de una amenaza, aumentando así su costo-beneficio.

Son sólo una serie de pequeños consejos a la hora de realizar un análisis de riesgos, pero si se siguen seguro que es más fácil obtener el éxito en una tarea a veces tan poco agradecida como puede llegar a ser un análisis de riesgos "bien hecho". Eso sí, el resultado merecerá la pena.

07 enero 2009

Publicada la norma BS 25777:2008 sobre continuidad TIC

El pasado Diciembre se publicaba la norma BS 25777:2008, un código de buenas prácticas sobre gestión de la continuidad TIC. Una norma que, emparentada con la ya conocida BS 25999 sobre continuidad de negocio, define un código de buenas prácticas sobre continuidad centrado en las infraestructuras TIC de las organizaciones, a sabiendas de que en la actualidad una gran parte de la continuidad del negocio de muchas organizaciones se basa en la continuidad de sus infraestructuras TIC.

La aparición de una norma de estas características me parece muy importante por dos motivos. El primero de ellos es que va a servir para separar formalmente la continuidad TIC de la continuidad de negocio, de modo que a nadie le den gato por liebre cuando hablemos de esta última. La continuidad del negocio es algo más que la continuidad de los servicios TIC, aunque tengan mucha interrelación. Por eso yo a veces prefiero el término "continuidad de la actividad comercial" que he visto utilizado en algunos sitios, porque aunque pueda ser un término menos exacto sí que da la sensación de que la informática no es lo fundamental. Que se caiga nuestro sistema CRM no equivale a que nuestros comerciales dejen de vender, y lo importante para el negocio es esto último. La continuidad de negocio debe estar orientada hacia los procesos de negocio, valga la redundancia, hacia los servicios prestados a cliente final y las actividades productivas, y el hecho de que dichas actividades utilicen en mayor o menor medida infraestructuras TIC sólo debería determinar la forma de abordar el problema. ¿De qué serviría tener garantizada la continuidad de nuestros sistemas informáticos si no tenemos garantizada la continuidad del know-how asociado a su uso y explotación? En el fondo, la gestión de la continuidad del negocio tiene mucho más que ver con la gestión del conocimiento que con la gestión TIC, y sin embargo es muy habitual que, al hablar de ella, la cantidad de veces que se mencione esta última sea abrumadoramente superior al número de veces que se habla de la primera...

El segundo motivo por el que me alegro de la aparición de esta norma es porque plantea un marco mucho más definido de actuación en materia de continuidad TIC. Obviamente, al querer entender la BS 25999 como una referencia para la continuidad de los sistemas nos encontrábamos con muchas vaguedades y conceptos excesivamente amplios que luego era necesario acotar y "traducir" artificialmente. En cambio, creo que con esta nueva norma, centrada en el ámbito tecnológico, estaremos en condiciones de disponer de una referencia mucho más útil a la hora de hablar de continuidad en entornos TI.

Por último, creo que otro de los aspectos a los que habrá que prestar atención a partir de ahora es a los movimientos en el sector en torno a esta nueva norma. Sobre todo porque, siguiendo la filosofía clásica de las normas BS, se prevé que para finales de este año aparezca la parte 2 de la norma, que ya será una especificación de los mínimos necesarios para desarrollar un Sistema de Gestión de la Continuidad TIC, y por tanto un esquema certificable específico para la continuidad TIC, con el interés que estos temas pueden despertar. Y tampoco sería descabellado pensar en que BSI pueda publicar una traducción oficial en castellano de estas normas, como ya hizo en su momento con la BS 25999, con el fin de incrementar el nivel de penetración en el mercado hispano-hablante...

05 enero 2009

Todo cambia, nada cambia

Vuelta de vacaciones y revisión de los hechos más destacados del sector. Una nueva noticia de phishing, en este caso a raíz de una campaña contra clientes de Vodafone; otra relativa al "golpe" recibido por la infraestructura PKI a causa de la enésima ruptura del algoritmo MD5 en certificados SSL, esta vez utilizando unas cuantas PS3 (otra nueva forma de jugar con ellas, supongo), ... En definitiva, más de lo mismo. Nuevas vulnerabilidades, más amenazas, ... Como diría alguno: esto de la seguridad es un no parar!

Precisamente por eso, porque no dejan de aparecer nuevos riesgos, es por lo que la gestión de la seguridad es tan importante. Podríamos pensar, recordando el famoso libro del queso, que la seguridad es nuestro queso. Un queso que se acaba rápidamente, que continuamente tenemos que estar buscando, racionando,... Un queso que debemos gestionar.

Porque lo único que es constante es el cambio, y para superarlo con éxito tenemos que aprender a gestionar. Gestionar el cambio también es gestionar la seguridad, gestionar un entorno de riesgo cambiante (y generalmente creciente), gestionar nuestras contramedidas de forma eficiente y eficaz... y, como se suele decir, no morir en el intento. Tarea nada sencilla, sin duda. Pero algún reto había que tener para el nuevo año, no? Qué tal mantener nuestra seguridad bajo control? Tratar de controlar lo incontrolable?

Año nuevo, vida nueva. Nuevas ilusiones, nuevos retos... ¿Os apetece participar? Os estaré esperando.