viernes, 17 de febrero de 2012

Protección de datos: La verdad sobre la sentencia del Tribunal Supremo

La reciente sentencia del Tribunal Supremo que anula el artículo 10.2.b del Real Decreto 1720/2007 ha hecho saltar todas las alarmas en los medios de comunicación. Titulares como “Barra libre para el trato de datos de carácter personal” o “El fin de la privacidad de las personas” han aparecido en la prensa generalista o en diversos blogs. Sin embargo, ¿qué hay de cierto detrás de estas noticias?

Analizando las primeras noticias que aparecieron en la prensa, una empresa podía pensar que a partir de ahora era posible tratar los datos de las personas a su antojo, sin que ello supusiera incumplir con la normativa aplicable en materia de protección de datos. Sin embargo, para tranquilidad de muchos y perjuicio de otros este hecho es totalmente falso, basta con leer cómo queda el famoso artículo 10 del Real Decreto 1720/2007 tras la sentencia del Tribunal Supremo.

Sin pretender entrar en temas demasiado técnicos, cabe desmentir de forma categórica las noticias que han aparecido, continúa siendo necesario contar con el consentimiento de las personas para cualquier tratamiento de sus datos de carácter personal. Lo único cierto del tema es que se ha eliminado una de las condiciones necesarias para constituir una excepción a dicha norma general, que establecía que dichos datos debían figurar en fuentes accesibles al público.

Más allá del contenido del artículo anulado, lo importante es saber que para que no sea necesario el consentimiento del afectado, deben coincidir una serie de restricciones que continúan siendo válidas, y que correspondientes al artículo 10.2.a). Básicamente exigen que dicho tratamiento esté amparado por una norma con rango de ley o de derecho comunitario, que corresponda al interés legítimo del responsable del tratamiento o cesionario (no basta con alegar interés comercial), y siempre que este interés no prevalezca a los derechos fundamentales de las personas (tales como el honor de las personas y su intimidad).

De hecho, la propia Agencia Española de Protección de Datos ya publicó una nota informativa donde analizaba este hecho, dejando claro su posicionamiento al respecto, incluso antes de que se pronunciase el propio Tribunal Supremo. La propia Agencia establece que atendiendo a las restricciones que permanecen vigentes, la sentencia no supone una modificación sustancial a los principios de la protección de datos de carácter personal.

Con todo ello es fácilmente comprobar que los titulares que se sucedieron a raíz de la mencionada sentencia partían de un análisis erróneo o exagerado y que en la práctica dicha sentencia no afecta sustancialmente a la mayoría de tratamientos que puedan realizarse.


lunes, 13 de febrero de 2012

Otras ventajas en la implantación de un Plan de Continuidad de Negocio

La implantación de un plan de continuidad de negocio tiene como principal objetivo  mejorar la resistencia o la capacidad de la Organización para sobreponerse a la materialización de una amenaza.

Dentro de la primera etapa del ciclo de vida de un BCP (Business Continuity Plan), la metodología propone dos actividades enfocadas a la comprensión de la organización (Norma BS25999):
  • Análisis de impacto al negocio: determinar cuáles son las actividades críticas y el impacto de su parada.
  • Análisis de riesgos: analizar los riesgos a los que están expuestos los activos de la Organización.


Estas dos actividades están orientadas a obtener los siguientes resultados:
  • Analizar estrategias de recuperación de las actividades críticas.
  • Planificar la reacción en caso de desastre.
Adicionalmente existen dos ventajas al enfocar un BCP en base a esta metodología:
  1. Por un lado, el análisis de impacto aporta una aproximación al mapa de procesos de la Organización. Obviamente no se profundiza en aspectos como el propietario del proceso, roles, métricas, instrucciones de trabajo, definición de las actividades secundarias, etc. pero sí se determinan las entradas y salidas críticas del proceso, los recursos humanos necesarios para ejecutarlo, los registros vitales que requiere el proceso y las dependencias con otros procesos, sistemas de información, proveedores  o localizaciones. Además de ello, también proporciona otros elementos que no se definen en proyectos de reingeniería de procesos, como son el tiempo máximo permitido de interrupción o el volumen de pérdida de recursos asumible para el negocio. 
  2. Por otro lado, permite identificar el mapa de riesgos corporativo (impacto a nivel técnico, legal, regulatorio, financiero, etc.). Este análisis es uno de los ejes de sostenibilidad de la compañía ya que ayuda a definir iniciativas para minimizar dichos riesgos, evitarlos, prevenirlos o anticiparse con posibles respuestas.
Desde nuestro punto de vista, estas actividades son básicas para cualquier implantación exitosa de plan de continuidad y proporcionan un valor añadido a la Organización.
Más información sobre BCP en thebci.org

jueves, 9 de febrero de 2012

Integrar personas y procesos. El reto de la gestión de TI



No basta con definir un proceso para que éste funcione. Lo complicado es conseguir que las personas involucradas los sigan de manera eficiente, estén convencidas y participen en su mejora.

Esto es un reto, no sólo a la hora de implementar procesos de gestión de servicios de TI sino a la hora de implementar cualquier nuevo proceso en la empresa. Esto es especialmente complejo en empresas de gran tamaño.

Para que los procesos funcionen de manera eficiente, necesitamos apoyarnos en la tecnología. Para ello implantamos herramientas de gestión de TI que nos permiten automatizar la ejecución de los procesos, consolidar y relacionar los datos involucrados y proporcionar información útil para la gestión y toma de decisiones.

Sin embargo, en muchas implementaciones de procesos de TI hemos olvidado involucrar a las personasLa idea es hacer partícipes a las personas involucradas en dichos procesos para que no perciban su implementación como una imposición sino como algo suyo. De esta manera creerán en el proyecto y se aunarán esfuerzos para conseguir hacerlo con éxito. Si no lo hacemos así, podemos generar una sensación del tipo “esto lo tengo que hacer así porque lo dice alguien y no sé por qué hemos de trabajar de una manera diferente si hasta el momento funcionábamos más o  menos bien”.

Una buena manera de conseguir lo anterior consiste en empezar realizando reuniones de trabajo para la definición de los procesos en los que participe la gente afectada, de diferentes departamentos y con diferentes funciones, con el objetivo de conocer cómo lo harían los involucrados.

Es imprescindible que en estas reuniones participen los consultores y técnicos externos con el objetivo de 1) guiar a los participantes en base a las recomendaciones que proporcionan las mejores prácticas y metodologías existentes y 2) proporcionar el expertise técnico necesario sobre la manera de cómo implementar en la herramienta, de manera eficiente y eficaz, las ideas y requisitos resultantes de dicha reunión.

Generalmente sin participación no suele haber compromiso. Es necesario que los responsables de TI practiquen una política de gestión de su personal basada en la transparencia, participación y delegación, sin olvidar el ejercicio de las actividades de control necesarias para asegurar que 1) se mantiene el rumbo, es decir, se va en el camino correcto para la consecución de los objetivos de TI y 2) se ha llegado a buen puerto, es decir, esos objetivos se han alcanzado.

jueves, 2 de febrero de 2012

Gestión TIC. Obsesionado por lo básico

Si me pongo en la piel del Director de TI creo que me sentiría algo así como abrumado. Continuamente están bombardeados con información acerca de nuevas tecnologías y metodologías, o la actualización o refundación de las ya existentes, con la promesa de aumentar la productividad, reducir costes, etc. A esto se une la sensación de que si no te subes al carro de las mismas te puedes quedar obsoleto o desactualizado.

Además, hemos de tener en cuenta que, si somos una pequeña o mediana empresa, para ser efectivos necesitamos tener en cuenta el hecho de que dispondremos de unos recursos y opciones limitados. Será necesario evitar toda la burocracia innecesaria y proponer soluciones que sean atractivas y adecuadas para la manera de ser de este tipo de empresas.

Para abordar esta avalancha de información, así como los retos específicos de nuestra empresa o sector, hay que realizar una parada de sincronía y volver a lo básico. Para mí, este volver a lo básico significa, en cualquier ámbito de la vida, responder a la pregunta ¿Para qué hago lo que hago?. En el mundo de las TIC, para responder a esta pregunta, tanto nosotros como la Dirección de la empresa, necesita entender, básicamente, cuatro cosas:

A nivel de seguridad
  • Entender las obligaciones. Es imprescindible tener un buen conocimiento de los requerimientos legales, comerciales o regulatorios que aplican al negocio y, además, este conocimiento debe permanecer constantemente actualizado.
  • Entender los riesgos. Es imprescindible conocer a qué riesgos de seguridad está expuesto el negocio, es decir, sus procesos, actividades y activos.

A nivel de servicios de TI
  • Entender qué procesos de negocio y que actividades principales de los mismos existen y, en particular, cuales forman la cadena de valor de la organización.
  • Entender qué servicios de TI soportan dichos procesos y cómo los soportan en cuanto a garantía y utilidad. ¿Por qué hablar de servicio de TI, de garantía y de utilidad?. Simplemente porque es el lenguaje que nos va a permitir entendernos e involucrar a la Dirección de nuestra empresa.

Volviendo a la pregunta inicial de para qué hago lo que hago, responderíamos que básicamente para:
  • Cumplir con las obligaciones del negocio
  • Reducir o eliminar los riesgos del negocio o el impacto asociado a la materialización de las amenazas asociadas a los mismos.
  • Mejorar la garantía o utilidad de los servicios que ofrecemos y soportamos.

Teniendo claro el mapa de situación en base a qué obligaciones, qué riesgos, qué procesos, y qué servicios, podemos abordar nuestros proyectos TIC con la garantía de que vamos por buen camino.

jueves, 19 de enero de 2012

¿Por qué falla un Help Desk?

En muchos momentos los servicios que realiza un Help Desk no suelen ser valorados positivamente por parte de los usuarios del mismo. La mayoría de las veces, eso queda reflejado en las encuestas de satisfacción del servicio donde dichos usuarios manifiestan su descontento con el servicio que reciben. 

Para tratar de simplificar, esa falta de satisfacción puede tener su origen en tres tipos de carencias o problemas:

Problema en las expectativas del usuario respecto del servicio ofrecido por el Help Desk. Por ejemplo, las expectativas pueden ser muy elevadas respecto a la capacidad operativa del Help Desk o respecto a los niveles de cumplimiento o acuerdos de nivel de servicio establecidos. 

A modo de ejemplo recuerdo una anécdota de hace años cuando participé en la implantación de un Service Desk en una multinacional española. En los Acuerdos de Nivel de Servicio se definió un tiempo de respuesta para cada una de las posibles peticiones de servicio que se podían realizar. En concreto, la solicitud de un nuevo PC, porque por ejemplo se incorporaba un nuevo empleado, tenía un tiempo de respuesta de dos semanas. Se entendió que ese era el tiempo necesario para gestionar la compra. La realidad es que, para ofrecer un mejor servicio, gestionábamos un pequeño stock de PCs. De esta manera, la instalación de un nuevo equipo se realizaba en dos días. La opinión del usuario era que dos días era un tiempo excesivo. Sin embargo, cuando conocían que los acuerdos de nivel de servicio estipulados nos permitían poder hacerlo en dos semanas, su percepción de la calidad del servicio variaba enormemente. 

Problema en la atención que el personal del Help Desk presta a los usuarios. Falta de empatía, cortesía, habilidades de escucha, falta de una guía de atención al usuario, etc. 

Simplificando mucho también, podemos decir que hay dos tipos de opciones: a) poner en la primera línea técnicos primando así la eficacia en la resolución de las incidencias y b) poner en la primera fila personal “no técnico” con mayores dotes sociales primando así la calidad en la atención. 

A mí, personalmente, me gusta poner técnicos. Esto implica que es necesario enfatizarles la importancia de la atención al usuario, así como establecer sesiones o cursos de formación en habilidades sociales básicas asociadas al tratamiento, por ejemplo, de usuarios enojados o incluso poco educados. Muchas veces, la percepción que recibe el usuario del servicio que proporciona el Help Desk está relacionada con estos aspectos. 


Problema en la operativa y/o organización interna del Help Desk que hace que el servicio no sea eficiente (lo necesariamente rápido) ni eficaz (bueno). 

Podemos tener unos buenos acuerdos de nivel de servicio y, además, cumplirlos. Podemos también tener un personal preparado capaz de ser muy resolutivo y simpático. Si no tenemos unos buenos procedimientos de, por ejemplo, escalado, clasificación, priorización, seguimiento … de las incidencias, no seremos capaces de gestionar de forma adecuada dichas incidencias, así como quejas, consultas, peticiones de servicio, etc, que llegan al Help Desk. 

Todos estos procedimientos, asociados al proceso de gestión de incidencias, se deben definir y depurar hasta que sean ágiles y nos permitan cumplir con los acuerdos de nivel de servicio establecidos o, mucho mejor incluso, con las expectativas de los usuarios. 

En este punto me gustaría hacer hincapié en dos aspectos. El primero es el relativo a la base de datos de conocimiento. Es importante disponer de una en la que se documenten los errores conocidos, workarounds, etc, pero la primera base de datos de conocimiento es la base de datos de registro de incidencias. Si se documentan mínimamente bien, es posible atender a un usuario que nos llama diciendo que vuelve a tener un problema con la cola de impresión del AS/400 sin necesidad de ser un experto o tener conocimientos avanzados en dicho sistema. Es más, esta es una de las pruebas, intentar resolver incidencias en primera línea, que el responsable del Help Desk es aconsejable que realice de forma periódica. 

El segundo es el relativo a las peticiones de servicio. Es necesario definir todas aquellas peticiones de servicio que pueden realizar los usuarios de cada uno de los servicios del catálogo. Es necesario definir el flujo de trabajo asociado a cada una de estas peticiones (qué, quién y en qué orden), y es necesario automatizar esos flujos en una herramienta de gestión a la que accedan todas las áreas o departamentos implicados. ¿Es un trabajo?. Sí. ¿Funciona?. Por supuesto.

miércoles, 18 de enero de 2012

Editada la nueva versión de la ISO20000:1-2011 en español

UNE-ISO/IEC 20000-1:2011 . Tecnología de la información. Gestión del Servicio. Parte 1: Requisitos del Sistema de Gestión del Servicio (SGS).


Finalmente, desde el día 21 de diciembre de 2011, es posible conseguir la nueva versión de la norma ISO20000-1 en su versión de 2011, ya traducida al español.(http://www.aenor.es/aenor/normas/normas/fichanorma.asp?tipo=N&codigo=N0048609&pdf).

La norma original ISO/IEC 20000-1:2011 se liberó en inglés en abril de 2011, y tras 8 meses, finalmente ha visto la luz su homónima en castellano.

Durante este tiempo hemos tenido que trabajar con la norma inglesa, puesto que a partir del 1 de julio de 2012 las nuevas certificaciones deben seguir esta nueva versión de la norma, y por tanto, ya hemos utilizado esta versión para todos los proyectos que hemos liderado. (Las certificaciones anteriores deberán adaptarse antes del 1 de junio de 2013).


Las novedades de esta norma ya se han ido explicando en varios foros, teniendo siempre en cuenta la norma en inglés, pero a partir de ahora ya todos tenemos la oportunidad de contrastar la antigua norma UNE-ISO/IEC 20000-1:2007 (Tecnología de la información. Gestión del servicio. Parte 1: Especificaciones. (ISO/IEC 20000-1:2005)), con la nueva versión de 2011.

Por poner un ejemplo de las diferencias entre ambas versiones: en la de 2007 se podía encontrar la palabra “debe” 183 veces, y en la nueva versión se repite en 257 ocasiones. Eso demuestra que se requerirá una madurez mayor para cumplir algunos aspectos, que deberán cumplir todas las empresas que quieran demostrar que siguen un Sistema de Gestión de Servicios (SGS) para proveer sus servicios de TI.


A modo anecdótico informar que la nueva versión cuesta 31,62€, y tiene en total 36 páginas (la versión del 2007 costaba 28,44 y tenía 21 páginas).

lunes, 9 de enero de 2012

¿Cómo abordar un Plan de adecuación a los requerimientos del Esquema Nacional de Seguridad?

El año 2010 trajo consigo un nuevo referente en el marco regulatorio legal, el Real Decreto 3/2010, de 8 de enero (BOE de 29 de enero), por el que se regula el Esquema Nacional de Seguridad (en adelante ENS) en el ámbito de la administración de Acceso Electrónico a los Ciudadanos. Este Real Decreto supone, además, un nuevo marco legal para las Administraciones Públicas, que junto al estándar internacional ISO 27002 o el Real Decreto 1720/2007 de desarrollo de la LOPD, establecen una serie de medidas de seguridad a implantar en los sistemas de información. En el caso del ENS, el ámbito de aplicación abarca a aquellos sistemas que soportan los medios electrónicos de comunicación con los ciudadanos en los servicios públicos. Su objeto es establecer la política de seguridad en la utilización de medios electrónicos y está constituido por principios básicos y requisitos mínimos que permitan una protección adecuada de la información.

En el Esquema Nacional de Seguridad, se diferencian dos tipos de proyectos:
· Aquellos que se desarrollan después de la entrada en vigor.
· Los existentes con anterioridad a la publicación de la norma.

Los primeros deberán iniciarse bajo el paraguas de acción del ENS, sin embargo, en el caso de los segundos, se establece en un año el tiempo de adecuación para el cumplimiento de la normativa. Es precisamente en este momento, cuando cobra importancia el Plan de Adecuación ya que en el caso de que concurran circunstancias que impidan la plena aplicación de lo exigido, se puede disponer de un plan de este tipo que marque los plazos de ejecución. Estos plazos no podrán exceder los 48 meses, desde que entra en vigor el ENS, por tanto 2014.

Para las organizaciones a las cuales aplica este ENS, se aproxima la hora de “remangarse” y comenzar a realizar un Plan de Adecuación que programe la implantación de los requerimientos que específica antes de 2014. Pero llegado este momento, surge siempre la siguiente pregunta:


¿Por dónde empezar un Plan de Adecuación?

Abast Systems, con una dilatada experiencia en proyectos de seguridad de la información concibe un proyecto de adecuación al ENS en las siguientes fases:

Fase I: Política de Seguridad: Validar si la política existe y si cumple con los requisitos del Anexo II del ENS.

Fase II: Valoración de la Información: Valorar la información significa identificar los requisitos relevantes en las dimensiones de confidencialidad, integridad, autenticidad y trazabilidad.

Fase III: Valoración de los Servicios: Valorar los servicios significa identificar los requisitos relevantes en las dimensiones de confidencialidad, disponibilidad, autenticidad y trazabilidad.

Fase IV: Datos de Carácter Personal: En caso de que los sistemas gestionen datos de carácter personal se tendrán en cuenta los requerimientos del RD 1720/2007.

Fase V: Categorización de los sistemas: Se categorizarán los sistemas en base al Anexo I del ENS.Para ello Los niveles de seguridad determinados para la información se imputaran a todos los activos que manejen la información correspondiente. Los niveles de seguridad determinados para los servicios se imputaran a todos los activos que concurran para prestar el servicio correspondiente.

Fase VI: Declaración de aplicabilidad de las medidas del Anexo II del ENS: Se elaborará una relación de las medidas exigidas por el anexo II del ENS y que son de aplicación a los sistemas o subsistemas de la fase anterior. También se motivará la no-aplicabilidad de algunas de las medidas.

Fase VII: Análisis de Riesgos: En esta fase se realizará un análisis de riesgos en función de lo exigido por el Anexo II del ENS. Este análisis será diferente en función de las categorías de los sistemas:

Sistemas de Categoría Básica. Se realizará un análisis informal que:
- Identifique los activos más valiosos del sistema.
- Identifique las amenazas más probables.
- Identifique las salvaguardas que protegen dichas amenazas.
- Identifique los principales riesgos residuales.

Sistemas de Categoría Media. Se realizará un análisis semi-formal con un catálogo básico de amenazas y una semántica definida que:
- Identifique y valore cualitativamente los activos más valiosos del sistema.
- Identifique y cuantifique las amenazas más probables.
- Identifique y valore las salvaguardas que protegen dichas amenazas.
- Identifique y valore el riesgo residual.

Sistemas de Categoría Alta. Se realizará un análisis formal que:
- Identifique y valore cualitativamente los activos más valiosos del sistema.
- Identifique y cuantifique las amenazas posibles.
- Identifique las vulnerabilidades habilitantes de dichas amenazas.
- Identifique y valore las salvaguardas adecuadas.
- Identifique y valore el riesgo residual.

Fase VIII: Determinación de las carencias de los sistemas: En base al trabajo realizado en las fases anteriores se establecerá una relación de:
- Aquellas medidas de seguridad exigidas por el Anexo II que no se cumplen.
- Aquellas medidas de seguridad exigidas por el RD1720 para los datos de carácter personal, que no se cumplen.
- Aquellos riesgos no asumibles por la organización.

Fase IX: Plan de Mejora de la Seguridad: En el Plan de Mejora se detallan las actuaciones encaminadas a subsanar las deficiencias detectadas en la fase anterior. Cada acción correctiva se debe documentar mostrando las carencias que subsana, el plazo previsto de ejecución, y la estimación del esfuerzo económico que implica.

Por tanto, en base a nuestra experiencia y a nuestros casos de éxito, una adecuación al ENS debe realizarse por fases, implantando un sistema de gestión de seguridad de la información que permita garantizar la aplicación de las diferentes medidas (marco organizativo, marco operacional, medidas de protección) a los sistemas de acceso electrónico de los ciudadanos.
Un primer paso indispensable es el Plan de Adecuación y a dos años de 2014… ¿no os parece un buen momento para comenzarlo?