La importancia del "testing"

Esta tarde de casualidad, he encontrado un ranking con los 10 mayores desastres causados por servicios TIC. Algunos ya los conocía y otros la verdad es que me han sorprendido.

El número 1 de la lista es impactante: en 1983 un fallo en el sistema de detección de misiles soviético detectó por error un ataque estadounidense y estuvo a punto de desencadenar la tercera guerra mundial.

Todas ellas, sin duda se produjeron porque los sistemas no habían sido debidamente probados. Se considera que en proyectos críticos (como sin duda lo era el soviético), el 80% de su presupuesto debe ser destinado la realización de pruebas (testing).

Esta máxima, en el caso de los planes de recuperación de desastres (PRD) no debería ser menospreciada. En este sentido, nos podemos plantear la siguiente pregunta: ante un desastre, ¿de qué depende el éxito del plan de recuperación? Mi opinión es que depende de lo bien que haya sido "testeado".

Desde mi punto de vista, realizar un diseño óptimo del plan, es importante, pero sin duda lo es más la simulación periódica del mismo, para poder corregir los posibles fallos de diseño e instruir adecuadamente a las personas implicadas. La única forma de obtener suficientes garantías de éxito ante un desastre, es incluir este plan dentro de un ciclo de mejora continua.

Yo creo que sin haber realizado estas pruebas, la correcta recuperación de los sistemas, quedará en gran medida, en manos del azar.

¿Cómo realizar un BIA?

BIA son las siglas de Análisis de Impacto en el Negocio, en inglés, Business Impact Analysis.

El BIA ayuda a integrar los servicios de TI en los procesos de negocio, cuantificando el impacto que una indisponibilidad de estos servicios tendría en los mismos y determinando, para cada servicio de TI, el tiempo de recuperación necesario para que dicho impacto no pase a ser inasumible por el negocio ya sea desde un punto de vista económico, de imagen, legal, etc.

El BIA se engloba, como una de sus primeras fases, en el Plan de Continuidad de los Servicios de TI que, a su vez, forma parte del Plan de Continuidad del Negocio.

Por tanto, la organización de TI debe conocer en cuanto tiempo puede recuperar sus servicios y en cuanto tiempo necesita el negocio que sean recuperados. Estas dos variables se conocen como RTA (Recovery Time Actual) o Tiempo de Recuperación Garantizado y RTO (Recovery Time Objective) o Tiempo de Recuperación Objetivo o Deseado.

Es necesario tener en cuenta una variable más: el RPO (Recovery Point Objective) o Punto de Recuperación Objetivo o Deseado. Este valor describe la cantidad aceptable de datos que se pueden perder, medido en tiempo. Este valor, que ha de proporcionar el negocio, está estrechamente ligado a la política de backup, archiving, replicación de datos, etc. que se esté realizando.

Una vez se obtengan dichos valores para cada servicio, será el momento de diseñar las estrategias de recuperación que permitan cubrir ese gap.

¿Cómo calculamos el RTA?

1. El primer paso, por tanto, es calcular, para cada servicio, su RTA. Para ello, es condición necesaria disponer de la lista de servicios de TI que soportan los procesos de negocio de la organización.

2. El segundo paso consiste en estudiar cómo la infraestructura de TI soporta el servicio. Es decir, qué cadena de activos de TI soportan el servicio de TI. Estos activos se pueden agrupar, básicamente, en los siguientes grupos: CPD, Infraestructura WAN, infraestructura LAN, servidores, software (sistemas operativos, aplicaciones estándares, aplicaciones de negocio) y datos.

3. Para cada uno de estos grupos de activos en general y activos incluidos en particular, estudiaremos las contingencias existentes. Básicamente el tipo de contingencia (redundancias, tolerancias, contratos de mantenimiento, equipos en spare, etc) y la dependencia de la contingencia (si depende de la organización o de un tercero).

4. Por último, con estos datos, calcularemos el Tiempo de Recuperación Garantizado (RTA). El RTA del servicio lo marcará el mayor RTA de la cadena de activos que lo soporta.

¿Cómo calculamos el RTO?

Para calcular el RTO, nos reunimos con los diferentes departamentos de la organización y les preguntamos dos cosas:

1. ¿Cómo utilizan la informática?. Con esta pregunta tratamos de averiguar qué servicios de TI utilizan y cómo los utilizan.

2. ¿Qué dependencia tienen de la informática? o más concretamente ¿Cuánto tiempo consideran que, para su operativa diaria, es admisible que un servicio de TI pueda no estar disponible?. Aquí es importante matizar al entrevistado que se trata de un escenario de desastre.

Con la información obtenida de las entrevistas y el visto bueno del Comité de Dirección de la organización, podremos establecer el RTO para cada servicio de TI.

Si, para un servicio de TI determinado, el RTO obtenido es inferior al RTA calculado, no se estará cumpliendo con los requisitos del negocio y, como ya se ha comentado, deberemos diseñar un escenario futuro que nos permita eliminar esa diferencia. Ese escenario futuro tendrá que tener en cuenta la tecnología, los procesos, las personas y los proveedores (ITIL v3).

Lo más importante es que el RTA lo proporcione la organización de TI y el RTO lo proporcione el negocio. Esta clarificación de espectativas mútuas es la mejor manera de integrar los servicios de TI en los procesos de negocio. Es un error que desde TI se piense que se sabe lo que necesita el negocio sin haber intentado averiguarlo mediante una aproximación minimamente estructurada como la que se ha expuesto.

Certificaciones TIC: la tendencia de un futuro inmediato

Quizá por el hecho de trabajar en un sector relativamente joven, lo cierto es que las certificaciones de calidad en las TIC (ISO27000, ISO2000, etc.) no están tan "extendidas" como en otros sectores, sobre todo como en aquellos relacionados con la producción.

En la actualidad, desde las organizaciones competentes se está trabajando por impulsar la calidad en el ámbito TIC, así que en los próximos años se espera que aparezcan nuevas normas y que evolucionen las existentes.

Sin embargo, la realidad es que hoy en día son muy pocas las empresas que han conseguido este tipo de certificaciones. Las causas pueden ser muy diversas: puede que los clientes no las exijan, que las organizaciones crean que aportan muy poco al negocio, que el mundo de la certificación TIC no sea lo suficientemente maduro...

Más allá de la confianza que aporta que "alguien" independiente garantice que estás trabajando de forma adecuada y con los medios necesarios, muchas empresas se plantean implantar estas normas para conseguir "el sello", es decir, la certificación se ve como un hecho que les diferencia de sus competidores: en definitiva, una buena estrategia de marketing.

Llegados a este punto, es posible que poco a poco vayan cambiando las reglas de juego: lo que se inició como un intento de desmarcarse de la competencia, puede que con el tiempo, acabe convirtiéndose en un requisito imprescindible para operar en el sector, ya que nadie querrá quedarse atrás, y los clientes no confiarán en aquellos que no muestren orgullosos sus correspondientes certificados.

Gestión de incidencias, gestión de peticiones o, simplemente, gestión de tareas

En esta entrada voy a hablar de mi particular visión acerca de la gestión de incidencias y peticiones en los Help Desk, Service Desk, etc.

En la versión 2 de ITIL, el proceso de gestión de peticiones de servicio estaba incluido en el proceso de gestión de incidencias. Se entendía (y yo sigo entendiendo) que la manera de tratar las peticiones de servicio era bastante similar a la manera de tratar las incidencias. Si tenemos presente que las peticiones de servicio son aquellas solicitudes realizadas por los usuarios tales como, solicitar un PC nuevo, una conexión VPN, un restore, etc, podemos entender que se gestionen de forma parecida a las incidencias.

En la versión 3 de ITIL, ambos procesos se separaron. No me parece mal a nivel teórico. A nivel práctico sigo pensando que en ITIL versión 2 ya quedaba claro: al categorizar distinguimos entre incidencias y peticiones de servicio y luego clasificamos en función de la categoría elegida.

Tenemos, por tanto, por un lado gestión de incidencias y por otro gestión de peticiones. Sin embargo a mi me gusta hablar simplemente de gestión de tareas.

Para razonar lo anterior, empezaremos hablando de cómo se gestiona una incidencia o una petición de servicio. Se puede hacer, básicamente, de dos maneras:

1.- En lo que podríamos llamar "modo estrella": el operador del help desk recibe la llamada, el correo, lo que sea. El operador lo intenta resolver él en primera instancia y si no lo consigue lo pasa a un técnico. El técnico realiza la acción necesaria y devuelve la incidencia al operador. El operador la cierra si ya está resuelta o se la trasmite a otro técnico para que lo haga. Este segundo técnico devuelve la incidencia al operador y este la cierra si está resuelta o la envía a otro técnico....Aquí he exagerado el escalado, no suele haber tantos niveles.

Si se trata de una petición de servicio, lo mismo. El operador traspasa la petición al primer técnico para que realice la tarea. Una vez realizada, el técnico se la devuelve al operador para que este se la pase al siguiente técnico necesario para resolver la petición....

2.- También es posible que los diferentes técnicos implicados conozcan (o esté documentado), para cada tipo de incidencia y petición de servicio, quien es el siguiente que debe hacer algo. De esta manera. sólo el último, devolverá la incidencia o petición al operador de help desk para su cierre. Sinceramente, bastante difícil.

Todavía existe una tercera opción, la que a mi me gusta:

a) Para todas los tipos de incidencias y peticiones de servicio, definimos las tareas necesarias, quien las ha de realizar (grupo o persona) y las dependencias entre ellas.

b) Insertamos esta información en la herramienta y la asociamos a la clasificación de las incidencias y peticiones de servicio.

c) La herramienta nos permite la posibilidad de añadir o quitar tareas a las ya definidas por defecto.

d) Los diferentes técnicos y no técnicos que han de resolver la incidencia o petición de servicio trabajan únicamente con tareas de manera que ellos sólo ven en la herramienta aquellas tareas que pueden realizar. El flujo de las mismas ya está definido en la herramienta.

La gran mayoría de herramientas de nivel medio-alto permiten trabajar con flujos de tareas. Sin embargo, no se suelen utilizar porque no se ha realizado el trabajo previo de definir lo expresado en el punto a); o porque no se mantienen actualizadas; pero, sobretodo, por cuestión de precio.

Trabajando con flujos de tareas nos interesa que toda la organización de TI y, seguramente, parte de la organización fuera de TI, trabaje con la herramienta. Si, por ejemplo, el departamento de compras está fuera de TI y trabaja con nuestra herramienta, podremos asignarle la tarea de compra de un PC nuevo cuando entre un empleado en nuestra empresa.

El problema reside en que la gran mayoría de estas herramientas se licencian por puesto de trabajo y, entonces, se intenta minimizar el número de personas que necesitan trabajar con ella.

De las dos caras de la moneda a la mejora TIC

Cuando los expertos entran a valorar la LOPD, a menudo utilizan el símil de las dos caras de la misma moneda. Por un lado, los "afectados" (a mi modo de ver un término poco acertado para representar al individuo sobre el que se refieren los datos de carácter personal) disfrutan de mayores garantías de la protección de sus datos. En la otra cara de la moneda están las empresas que los tratan, ya que se ven obligadas a implantar unas estrictas medidas de seguridad, bajo la amenaza constante de una dura sanción.

En la cara menos amable de la moneda se encuentra un colectivo que, sin duda alguna, es el auténtico "afectado" (en sentido literal) de la situación: el departamento TIC. Es muy frecuente encontrar a un grupo de personas arrollados por la operativa diaria, con la avalancha de medidas a implementar, y todo ello sin contar con el suficiente compromiso del resto de la organización -al fin y al cabo, la información es cosa suya, ¿no? - Éste es un comentario irónico pero que refleja bastante bien la realidad.

Pero es aquí, ante esta situación tan poco prometedora, donde nace quizás la mayor oportunidad de mejora del departamento TIC:

Imaginemos por un momento al responsable del departamento TIC solicitando los recursos necesarios para optimizar el rendimiento de su departamento, aplicar mejoras en las medidas de seguridad etc. Si en esta empresa no está arraigada la visión de las TIC como un elemento que soporta la cadena de valor del negocio, con mucha suerte, se le aprobará un presupuesto para realizar alguno de los proyectos que tanto necesita. Unos proyectos vistos por el resto de los departamentos como "otro capricho más del informático".

Entonces, ¿qué pasaría si solicitase los recursos necesarios para diseñar de forma óptima todos los procesos del departamento, modificar todas las aplicaciones para incluir las medidas de seguridad adecuadas, realizar auditorias e inventariados de la información, implantar un mecanismo eficiente para la gestión de las incidencias... y un largo etcétera? Posiblemente debería aguantar alguna carcajada...

Pero se produce un cambio de paradigma cuando aparece en escena la LOPD. Es habitual que en una reunión con la directiva se vayan sucediendo las siguientes fases:

1. Indiferencia: cuando se está explicando en qué consiste la LOPD, sus objetivos, implicaciones...
2. Rechazo: se comienza a notar en el ambiente cuando se van detallando las diferentes medidas a aplicar.
3. Atención: llega el momento de explicar las cifras que se están barajando en las sanciones.
4. Alarma: momento en el que se empiezan a mostrar recortes de prensa con las noticias diarias de las sanciones (incluso a las grandes entidades), hecho que repercute tanto en lo económico como en el prestigio de la compañía.
   

Y es justo en este preciso momento cuando se comienza a apreciar el deseado compromiso y todas las miradas apuntan al responsable del departamento TIC buscando soluciones. Unas soluciones que con ciertos matices, en su mayoría ellos mismos ya habían rechazado.

Evolucionar o morir

Las "best practices" o buenas prácticas... casi todo el mundo ha oído hablar de ellas, casi todo el mundo conoce, en general, sus principios y sus beneficios. Entonces, ¿Por qué no se utilizan?. ¿Por qué representa una dificultad trabajar con ellas y no se entienden como un beneficio?. Ante estas preguntas, suele ser común argumentar cuestiones relacionadas con costes e inversiones, por no hablar de recursos, sobrecarga de trabajo, etc., aunque desde mi opinión y siendo un tanto generalista, la parte más importante de la dificultad reside en un aspecto conceptual: la preponderancia de un tipo de pensamiento tecnicista. Una forma de pensamiento impermeable muy común y extendida entre muchos de los especialistas del sector, que hace que se perciban como una "Filosofía" en vez de hacerlo como una experiencia práctica que ha demostrado su eficacia y su utilidad en el contexto en el que se ha aplicado. ¡El eterno binomio de la teoría y la práctica!, a pesar de que ambos términos no sean semánticamente opuestos.

No resulta sorprendente que bajo este prisma se perciba negativamente, si se tiene en cuenta que el principio central, o dicho de otro modo, lo que lo hará posible, se fundamenta en un cambio de mentalidad. ¿Filosofía, entonces? En parte y sólo en parte.

Analizando la evolución de género humano, resulta curioso que el mayor logro a nivel de desarrollo (sin tener en cuenta aquí el desarrollo físico) se dé fundamentalmente en el ámbito tecnológico. A lo largo de millones de años de evolución, hemos sido capaces de pasar de la "ingeniería" lítica más arcaica a la ingeniería tecnológica más innovadora. ¿Cuál ha sido el denominador común de semejante logro? Simplificándolo mucho:

a) La predisposición mental que ha permitido ir un paso más allá, no sólo visualizando el resultado, sino que también asumiendo la dificultad e incluso el riesgo implícito. En resumen: el cambio.

b) La sistematización y optimización de procesos productivos mecanizables basados en los principios de la mejora continua (Plan - Do - Check - Act).

Vemos pues que ambos conceptos son complementarios y forman parte de un todo. Ahora bien, el segundo sólo será posible si el primero ha tenido lugar, estamos entonces ante una decisión trascendente:

Evolucionar o morir

¿Se está haciendo correctamente el documento de seguridad de la LOPD?

El Real Decreto 1720/2007 en su artículo 88 establece lo siguiente:

"3. El documento deberá contener, como mínimo, los siguientes aspectos:
a) Ámbito de aplicación del documento con especificación detallada de los recursos protegidos.
b) Medidas, normas, procedimientos de actuación, reglas y estándares encaminados a garantizar el nivel de seguridad exigido en este reglamento.
c) Funciones y obligaciones del personal en relación con el tratamiento de los datos de carácter personal incluidos en los ficheros.
d) Estructura de los ficheros con datos de carácter personal y descripción de los sistemas de información que los tratan.
e) Procedimientos de notificación, gestión y respuesta ante las incidencias.
f) Los procedimientos de realización de copias de respaldo y de recuperación de los datos en los ficheros o tratamientos automatizados.
g) Las medidas que sea necesario adoptar para el transporte de soportes y documentos, así como para la destrucción de los documentos y soportes, o en su caso, la reutilización de los mismos".

La propia Agencia de Protección de Datos dentro de su Guía de Seguridad publicada en abril de este año, incluye una guia modelo del documento de seguridad. A modo de ejemplo, dentro del apartado de gestión de soportes y documentos, podemos encontrar, entre otras, las siguientes recomendaciones:

"Los soportes que vayan a ser desechados, deberán ser previamente (detallar procedimiento a realizar para su destrucción o borrado) de forma que no sea posible el acceso a la información contenida en ellos o su recuperación posterior.
En el traslado de la documentación se adoptarán (indicar medidas y procedimientos previstos) las para evitar la sustracción, pérdida o acceso indebido a la información".

Tras lo expuesto queda claro que, en el documento de seguridad, es necesario detallar los procedimientos y medidas técnicas exigidas por el Real Decreto. Sin embargo, la práctica nos lleva a encontrar documentos de seguridad que son una mera copia del Real Decreto. Por ejemplo, cuando el Real Decreto determina en su artículo 94, punto 4 que:

"Siempre que vaya a desecharse cualquier documento o soporte que contenga datos de carácter personal deberá procederse a su destrucción o borrado, mediante la adopción de medidas dirigidas a evitar el acceso a la información contenida en el mismo o su recuperación posterior".

En el documento de seguridad aparece un texto similar al siguiente:

"Los soportes que tengan que ser desechados, se destruirán siguiendo un mecanismo que no permita recuperar la información contenida en los mismos"

Es decir, simplemente se copia el artículo de la ley sin detallar ni procedimientos (responsabilidades) ni medidas. El resultado ya es conocido por todos: currículums con anotaciones subjetivas sobre el comportamiento de los candidatos en papeleras, historias clínicas en contenedores públicos, etc.

¿Cuál es la razón?. Probablemente, porque se ve la LOPD como un trámite burocrático impuesto que viene a complicar la ya difícil realidad diaria de las empresas. Sin obviar que el Real Decreto es criticable en muchos de sus aspectos, creo que es conveniente tener en cuenta que:

1. La LOPD es como una moneda, tiene dos caras: como empresa nos parece un lastre burocrático más pero, como personas, constituye un garante de nuestros derechos individuales. Con esta perspectiva, como responsables del cumplimiento de la ley, debemos poner empeño en tratar los datos de los demás como nos gustaría que trataran los nuestros. Es decir, podemos intentar aplicar lo que podemos llamar la "regla de oro del tratamiento de datos de carácter personal".

2. Además, es muy interesante hacer una aproximación a la LOPD como algo más que el mero cumplimiento de una obligación legal. Podemos ver la LOPD com el principio, o la parte, de un SGSI o Sistema de Gestión de Seguridad de la Información. SGSI que puede estar basado en la norma ISO27000. Con esta perspectiva, vemos que prácticamente todas las medidas de seguridad exigidas por el Real Decreto tienen su equivalente en controles definidos en la norma. Por tanto, implantando las medidas de seguridad técnicas del Real Decreto, estamos construyendo el SGSI de nuestra organización.

Primera entrada

Hola, os damos la bienvenida a este blog con el deseo de compartir con vosotros nuestro conocimiento y nuestras experiencias en el mundo de las TIC.