Búsqueda


27 de abril de 2007

Top Secret DrumCorps

Lo acabo de ver en CPI (Curioso pero Inútil), y no he dudado ni un segundo en querer ponerlo aquí tambien. No soy amigo del corta-pinta-y-colorea, pero esto se lo merece.

Activa el altavoz, y... con ustedes, los únicos, los inimitables...

¡¡¡ Top Secret DrumCorps !!!

24 de abril de 2007

Publicado COBIT 4.1

Hoy me ha llegado el mail de notificación desde ISACA comentando que se ha puesto a disposición de los miembros de ISACA y de forma anticipada la descarga oficial de COBIT 4.1, incluyendo todo un paquete de documentación adicional.

The new and updated publications are as follows; (D) indicates downloadable:

  • COBIT 4.1 (D)
  • IT Governance Implementation Guide: Using COBIT and VAL IT, 2nd Edition (D)
  • COBIT Control Practices: Guidance to Achieve Control Objectives for Successful IT Governance, 2nd Edition
  • IT Assurance Guide: Using COBIT (D)
  • COBIT Security Baseline, 2nd Edition (D)

In addition to the above publications, members will also benefit by being able to download:

  • IT Governance Implementation Guide toolkit files (D)
  • IT Assurance Guide detailed content as an electronic file (D)

Yo ya me lo he descargado todo. Habrá que ponerse a estudiar ya mismo!!

Estadísticas y ANS (III)

En el post anterior de esta serie terminamos concluyendo que desde el punto de vista del cliente es recomendable conocer el histograma acumulado de los valores de Tiempo de Logon para la aplicación Web que estamos usando como ejemplo, de tal forma que se pudiera llegar a plantear un SLO del tipo "tiempo de logon a la aplicación inferior a 5sg. para el 90% de los casos". El caso es que para que el proveedor pueda acordar este tipo de objetivo de nivel de servicio es necesario que se haya comprobado si efectivamente lo podrá cumplir o no. ¿Qué herramientas puede utilizar el proveedor para estar seguro de cumplir con este compromiso?

Siempre que me toca dictar un curso de Fundamentos ITIL insisto mucho en que "antes de comprometernos debemos haber medido", pero si sólo me baso en las mediciones puntuales y no realizo ningín tipo de cálculo estadístico al respecto del comportamiento de lo que estoy midiendo puedo caer fácilmente en el error de afirmar que "mi tiempo de logon medio es de 4,1 sg. y eso está por debajo del SLO pactado". Pero nuestro cliente ha cambiado las reglas del juego: ya no estamos midiendo estrictamente el tiempo medio de logon, sino que ahora queremos, además, una estabilidad de esa variable.

Para enfrentarnos a este reto vamos a utilizar una herramienta que todos hemos oido nombrar, incluso la hemos estudiado más de una vez y que los matemáticos llevan utilizando desde principios del Siglo XVIII: la distribución Normal, o "campana de Gauss". Esta distribución tiene toda una serie de características que la hacen especialmente interesante para el estudio estadístico, siempre y cuando los datos que estamos analizando cumplan con la hipótesis de normalidad (de la que ya hablaremos en futuros posts).

Dada una distribución con media μ y desviación estándard σ , la función de densidad para esta distribución será

 de tal forma que vemos que la función de densidad es directamente dependiente de estos dos parámetros: la media y la desviación estandard.  La distribución normal se corresponde con esta curva cuando la media vale 0 y la distribución estándard vale 1. Cuando la desviación estándard se hace mayor, la curva se "aplana" y cuando la desviación se hace menor, la curva se hace cada vez más estrecha y "puntiaguda".

¿Y qué tiene que ver todo esto con la estabilidad de nuestro servicio?

Bueno, pues ocurre que en aquellos casos en que el fenómeno que estamos analizando se ajusta a una distribución normal, veremos que la gran mayoría de casos se agrupan en las zonas próximas a la media y, cuanto menor sea la dispersion de los datos analizados (osea, cuanto menor sea la desviación estándard) veremos que los valores de la frecuencia son cada vez mayores en las zonas próximas a la media. Supongo que si lo vemos en una gráfica todo será más claro.

En la primera gráfica, la que en nuestro ejemplo se corresponde con las muestras que nos dan una desviación estándard de 1,22 vemos que la curva normal es más puntiaguda, y la diferencia que hay entre el histograma y la curva normal es relativamente poca (ya hablaremos de la hipótesis de normalidad... no tengas prisa!) mientras que en la segunda, aquella que tenía como desviación estándard 3,02 la curva es más baja y más ancha.

Así, podemos ver de una forma gráfica que cuanto menor sea la desviación estándard, más se agrupan los valores en torno a la media y, por lo tanto, las frecuencias son mayores en el histograma para esos valores.

Puede ser que nuestra distribución de tiempos de respuesta no se acabe de ajustar claramente a una curva de distribución normal, pero la Naturaleza es muy sabia y sucede una de esas cosas casi mágicas: el Teorema Central del Límite. Sea como sea nuestra distribución, si tomamos un número suficientemente grande de muestras comprobaríamos que la media de estas muestras tiende a ser la media de la distribución y que la desviación estándard de estas muestras tiende a ser y que los valores observados se ajustan a una distribución normal de características .

Basándonos en esto, le pedimos al SPSS las estadísticas descriptivas de nuestras muestras y vemos que en el primer caso, el valor de  es  0,072 y en el segundo caso es de 0,18.

 

Así, en el primer caso podemos afirmar que con un 95% de probabilidad, la media del tiempo de logon de la aplicación va a estar situada entre 4,1 y 4,4 segundos, mientras que en el segundo caso la media estará situada entre 3,9 y 4,6 segundos (mucho más acotado en el primer ejemplo) y por lo tanto el proveedor ya puede empezar a fiarse de sus afirmaciones de una forma más científica que hasta ahora.

Si lo representamos gráficamente, se puede observar claramente cómo en el primer caso el intervalo de confianza está mucho más acotado que en el segundo, precisamente debido a la menor variabilidad del servicio (mostrada por el menor valor de su desviación estándard).

De la misma forma que hemos podido establecer un intervalo de confianza para la media, podremos establecer un intervalo de confianza para el valor del tiempo de logon de nuestra aplicación siempre y cuando podamos concluir que este valor se ajusta a una Normal, pero eso será tema de investigación para el próximo artículo.

PS:: Para corregir y mejorar esta serie de artículos he contado con la inestimable ayuda de Carme Duque, estadística  de estudios, informática de profesión y persona de gran valor que nos dará alguna que otra sorpresa en el futuro. Desde aquí, ¡Gracias!

 

 

16 de abril de 2007

Cobit 4.0 en Castellano

Recientemente la ISACA ha publicado la traducción oficial del Cobit 4.0 al castellano. Le he estado echando un ojo por encima, y realmente se ha hecho un trabajo considerable, bastante mejor que las traducciones (por ejemplo) de los manuales CISA. Aún así, estéticamente creo que les ha faltado un poco de esfuerzo, ya que hay errores de maquetación que enturbian el resultado final.

Personalmente, prefiero trabajar con la fuente en inglés, ya que es la original y me permite "olfatear" un poco mejor lo que podía tener en mente la persona/equipo que escribió el trocito que esté utilizando en cada momento, pero estoy seguro que de cara a la difusión y enseñanza de este magnífico marco de trabajo esto va a ser una muy buena noticia.

Aún así, hay que permanecer atentos: en menos de 3 semanas tendremos aquí Cobit 4.1 e ITIL 3.0... este va a ser un verano movidito!

10 de abril de 2007

Estadísticas y ANS (II)

En el artículo anterior comenzaba a aparecer el concepto de plantilla y de rango de valores.

... por lo tanto, podemos empezar a intuir que en el primer ejemplo hablamos de que aproximadamente el tiempo de respuesta oscila entre 3,06  y 5,5 segundos, mientras que en el segundo caso la horquilla va desde los 1,22 hasta los 7,26 segundos.

Lo interesante ahora es conseguir saber cuál es el grado de validez de esta aproximación que hemos hecho... esa "horquilla" que comentábamos, ¿se refiere al 60% de los casos o al 99,9% ?.

Habíamos visto que si representamos la secuencia de muestras en una gráfica lineal no conseguiremos demasiada información, salvo, quizás, una visión general de la tendencia que podemos observar en la evolución del tiempo de respueta a lo largo del tiempo. Ahora bien, si cambiamos esta representación lineal (donde el eje X se corresponde con el número de muestra o el tiempo y el eje Y muestra el tiempo de respuesta observado) por un histograma donde en el eje de las X tenemos los valores para el tiempo de respuesta y en el eje de las Y el número de veces (la frecuencia) que hemos obtenido valores para ese tiempo de respuesta, obtenemos una gráfica que es mucho más representativa de la estabilidad de nuestro proceso:

Ahora podemos comprobar que en el primer caso, aquel que tiene una menor desviación estándard tiene la gran mayoría de los casos agrupados alrededor del 4, mientras que, a pesar de que en el segundo gráfico vemos gran cantidad de casos alrededor del 4, tambien se observan muestras en valores como el 20 o el 25, que no estan presentes en el primer ejemplo.

Es precisamente esta ausencia de "extremos" o "outlayers" lo  que da mayor estabilidad al comportamiento del primer caso frente al comportamiento del segundo caso.

Como decíamos al principio, lo que buscamos es saber el grado de fiabilidad de las afirmaciones al respecto de la horquilla en la que podemos encontrar a la mayoría de los valores. La primera herramienta que podemos utilizar para esto es un histograma acumulado, que nos vaya mostrando el porcentaje acumulado que representan los tiempos de respuesta observados:

Asi, podemos ver claramente que, a pesar de que ambas situaciones cumplen con aquel requisito de ANS que mostrábamos en el primer artículo de la serie, ninguna de las dos situaciones acaba de ser satisfactoria desde el punto de vista de un cliente: en ambos casos el porcentaje de valores que está situado por debajo del umbral de ANS no llega al 85%.

Así, con este segundo post podemos llegar a concluir que, desde el punto de vista de cliente no sólo debemos exigir información relativa a las medias y las desviaciones estándard de nuestros indicadores, sino que tambien debemos tratar de conseguir información relativa al porcentaje de veces que se cumple el ANS:

 

SLO: Tiempo de logon inferior a 5sg. en el 90% de los casos.

 

En los siguientes artículos iremos desgranando si  estas afirmaciones tienen o no sentido y cuáles deben ser las medidas a tomar por parte del proveedor de cara a poder asegurar unos SLOs como los anteriormente mencionados con ciertas garantías (porque en este momento, el proveedor sólo dispone de información "a posteriori", no puede hacer una predicción de si cumplirá o no el ANS firmado).

5 de abril de 2007

El mentiroso y el cojo

Tomás Roy es uno de esos expertos en hacerte pensar. Su trabajo como Director de Calidad y Seguridad en una gran organización le hace enfrentarse diariamente a situaciones especialmente complejas y le permite ver el mundo de las TIC desde una perspectiva interesante. Después de estar comentando con él algunos aspectos del Gobierno de la Seguridad, redactó este artículo que me gusto tanto que le pedí permiso para publicarlo aquí como el primer artículo contribuido de Gobierno de las TIC.

------------------------------------------------------

Axioma 1: En general, el Negocio y los Sistemas de Gestión deberían estar soportados e implantados de forma tal que la toma de decisiones se realice al nivel más bajo posible.

Axioma 2: La toma de decisiones debe garantizar que las TIC proporcionen valor al Negocio, resultando un alineamiento estratégico entre el Negocio y las TIC.

Axioma 3: Se pilla antes a un mentiroso que a un cojo.

Los tres axiomas anteriores están bien redactados y el último de ellos está avalado por la sabiduría popular, por lo que se le presupone haber superado una larga fase de “testing” que garantiza su validación y verificación.

Según ISACA, organismo impulsor del IT Governance Institute y de Val IT, en el “IT Governance Global Status Report—2006” encargado a PwC y realizado mediante entrevistas a 695 C-suite (CIO y CEO) en 22 países, podemos observar cómo los principales problemas son los Incidentes Operacionales, la falta de recursos IT adecuados y los costes incurridos en TI.

Curiosamente seguridad y cumplimiento no preocupan probablemente debido a las inversiones ya realizadas.

Si combinamos esta apreciación con un modelo de madurez como el Staged Maturity Model de KPMG (que se focaliza en la posición de las TIC dentro de la cadena de valor diferenciando entre 5 niveles), podemos ver que claramente las TIC se encuentran situadas actualmente en el foco de menor valor: tenemos problemas con la operación, dependemos de recursos IT difíciles de encontrar y esto provoca que incurramos en elevados costes por la falta de eficiencia y el elevado precio de los servicios (provocados por la carencia de recursos especializados).

Luego, de los tres axiomas, observamos que sólo el tercero es verdadero: No podemos hablar de alineamiento con el negocio de las TIC ni de Gobierno o toma de decisiones como un hecho, sino como mucho como un objetivo a cumplir.

Y en la seguridad, ¡peor!. Como se desprende del mismo informe, no damos problemas, solo miedo.

Es decir, fracasamos totalmente en definir cómo la función de la Seguridad de la Información contribuye a ganar Negocio, aunque su culpabilidad en las pérdidas del mismo están muy bien identificadas.

Con un panorama como el descrito la única esperanza que tiene la Seguridad es la severidad del impacto y el medio irracional que se deriva.

De esta forma, necesitaremos definir una ciencia en si misma: Seguridad de Informaciones, con un negocio propio y con su Gobierno de la Seguridad y su toma de decisiones, y sus herramientas. Cuanto peor lo hagamos mejor, ya que cada ataque demostrará cómo son de malos de fuera y cuán necesarios somos los que sabemos cómo defendernos.

Ahora bien… si el tercer axioma es verdadero, entonces tenemos de 2 a 5 años de vida profesional interesante. Nos descubrirán, y acabaran poniendo a otro “amuleto de la suerte” más económico.

Pues va a ser que no.

Recuerden por qué les eligieron para hacer sus trabajos: por sus capacidades. Hace 15 años, para gestionar un router y un servidor se necesitaba a un telecos. Hace 25 años, para programar se necesitaba un ingeniero o informático (si existía). Hoy no, está claro. Y mañana … menos.

Pero aún nos queda una cosa: nuestra capacidad para entender problemas complejos.

Si hoy nos seleccionaran por nuestras capacidades… que nos pedirían?

  • Que resolviéramos el problema de la gestión de los servicios TIC
  • Que optimizáramos sus costes y tiempos y garantizáramos el valor de la inversión
  • Que definiéramos un marco de gestión de riesgo global
  • Que realizáramos planes de negocio reales
  • Que alineáramos las TIC al negocio, que permitiéramos el Gobierno TIC.
  • Que entendiéramos la arquitectura de la empresa: del negocio, de las informaciones, de las aplicaciones y de la tecnología.

El único problema es que nuestras empresas no saben lo que tienen que pedir o que nos lo pueden pedir a nosotros. Trabajemos con el Negocio para hacer realidad el axioma 1 y 2 e intentemos que nuestras herramientas también lo hagan.

La Seguridad de las Informaciones tiene un pie en el negocio, se especializa en proteger lo que tiene valor, tenemos una visión global. Propongámonos como impulsores de la madurez del negocio y de las TIC; que entiendan que hay interlocutores capaces al otro lado, hablemos de CAPEX, OPEX y de lo que haga falta.

No es la situación ideal sustituir las funciones del negocio, iremos cojos durante una temporada, hasta que tire el negocio por si mismo.

Pero como dice el tercer axioma, se coge antes al mentiroso que al cojo

4 de abril de 2007

Estadísticas y ANS (I)

La semana pasada estuve en un cliente realizando unas pruebas previas a la puesta en producción de un nuevo servicio. Mientras se iban realizando las pruebas de todo tipo, me llamó la atención que el tiempo de logon al nuevo aplicativo era muy variable, a veces un segundo y a veces 10 segundos y eso me hizo pensar en cuál era la sensación que podía tener un usuario ante esta situación.

Idealmente, cualquier usuario desea que las aplicaciones que utiliza vayan “rápido”, pero eso es un concepto totalmente subjetivo: ¿cuánto es rápido? Si toda tu vida has ido en un SEAT 127, rápido son 80Km/h… hasta que te subes a un Porsche y conoces lo que es circular a 120Km/h (claro, a más no puedes porque estarías violando la ley)… entonces tu 127 nunca más vuelve a ser rápido.

Siguiendo con la analogía, si a un usuario le dejas conocer la velocidad de logon de un segundo, nunca más pensará que 5 segundos es “rápido”, así que llegamos a la conclusión de que más que rápido o lento, lo ideal es que el rendimiento del servicio sea estable, con pocas variaciones, predecible.

Esta misma situación se da en los procesos, donde al margen de que el tiempo de respuesta o de la velocidad de ejecución de las actividades sea especialmente bueno, el cliente desea (aunque sea de una forma inconsciente) un comportamiento estable, predecible y con poca variabilidad, porque cuando las cosas son predecibles nos hacen sentir más cómodos.

Desde un punto de vista tradicional, tanto los procesos como los servicios son evaluados según un paquete de métricas y es el análisis de estas métricas lo que nos debe llevar a concluir si estos comportamientos son estables o no; pero desde un punto de vista estadístico tanto procesos como servicios son evaluados a partir de una serie de observaciones a partir de las cuales se obtienen las métricas que nos servirán para analizarlos: hay una sutil diferencia entre la verdad absoluta y la verdad estadística.

Tomemos como ejemplo el tiempo de logon de esta aplicación que fue la que disparó esta línea de pensamiento, pero en dos momentos distintos de su historia: como buenos itileros que somos, tenemos montados unos mecanismos de monitorización que nos permiten sondear estos tiempos de respuesta; una medición cada cinco minutos nos genera la nada despreciable cifra de 288 observaciones por día y tenemos dos columnas para representar los dos periodos de medición diferentes. (Para ir experimentando con las nuevas tecnologías, he colgado los dos paquetes de datos que usaremos como ejemplos aqui)

Normalmente, nos encontraremos que la métrica principal sobre un sistema como este sería la media de tiempo de logon, valor que para ambos casos es de 4,2 sg, y que podríamos entender como razonable e incluso se podría haber marcado como objetivo de nivel de servicio en un ANS.

SLO: Tiempo medio de logon para el servicio inferior a 5sg.

Ahora bien, ¿cuán estable es el comportamiento del tiempo de logon?

Con una media únicamente no es suficiente para poder asegurar con rigor que los resultados obtenidos son los definitivos y correctos para definir nuestro valor de la SLO. Necesitamos tener más información y es por ello que nuestro siguiente paso es representar el comportamiento de las observaciones TlogonA y TlogonB (tiempos de respuesta obtenidos cada 5 minutos en 1 día) en una gráfica :


Y es entonces que nos encontramos con un problema típico de este tipo de representación: la gráfica no nos dice gran cosa. A primera vista son muy parecidas e incluso hasta nos puede parecer mejor la segunda que la primera, pero hay un par de trampas ocultas: por una parte, está la escala (ojo! Variando la escala puedo hacer que cualquier gráfico sea “aceptable”) y por otro lado está el número de picos que hay en la segunda gráfica, que es mayor.

Pero hay unos cuantos valores estadísticos que nos pueden ayudar en sobremanera en estos casos: el primero de ellos es sigma, o “desviación estándar”.

La desviación estándar indica el grado de dispersión de la muestra, osea, cuánto tienden a alejarse los valores del promedio de la muestra: cuando haya una dispersión muy grande (osea, poca estabilidad) tendremos un valor de sigma muy elevado y cuando los valores se agrupen cerca de la media, entonces tendremos valores de sigma muy bajos.

Si aplicamos las fórmulas correspondientes a nuestra muestra, nos encontramos que tenemos una desviación estándar de 1,22 en el primer ejemplo, mientras que nos encontramos con un valor de sigma de 3,02 para la segunda muestra. Esto significa que en el primer ejemplo, la distancia media entre las observaciones y el valor 4,2 es de 1,22 y, por lo tanto, podemos empezar a intuir que en el primer ejemplo hablamos de que aproximadamente el tiempo de respuesta oscila entre 3,06 y 5,5 segundos, mientras que en el segundo caso la horquilla va desde los 1,22 hasta los 7,26 segundos.

De esta forma, comenzamos a vislumbrar que la media como único elemento para la evaluación de un servicio o de un proceso no es suficiente y que precisamos de otros artefactos matemáticos estadísticos que nos permitan evaluar la estabilidad y la bondad o incluso predecir el grado de cumplimiento de estos ANS. Sigma destaca como uno de los más importantes, ya que nos permite saber la variabilidad de nuestros datos, pero no es lo único a investigar.

En próximos artículos iremos viendo qué artilugios podemos utilizar y cómo se comporta nuestro servicio ante este tipo de análisis estadístico, proporcionando herramientas tanto para actuar como clientes (y solicitar que los ANS de nuestros proveedores dispongan de objetivos de nivel de servicio medidos en los términos adecuados) como para actuar como proveedores (y utilizar las estadísticas para ajustar los valores propuestos de ANS a valores asequibles y con escasos niveles de error).

PS: Estos ejemplos están realizados con una versión de evaluación de SPSS 15.0 que caduca dentro de apenas 13 días, así que espero poder terminar de escribirlos antes de esa fecha o que los señores de SPSS me hagan feliz con un regalito de cumpleaños para el blog! ;-)