Calidad en las TIC

La credibilidad del CISO

noreply@blogger.com (Pedro Dégano) — Wed, 22 Feb 2012 15:26:00 +0000

Sí, he de admitirlo, los proyectos de seguridad son los que más me hacen disfrutar. Además, durante estos años de consultor, he tratado con muchos CISOs (Chief Information Security Officer) y me fascina el rol que juegan en la organización. Su trabajo es una continua partida de ajedrez… yo muevo mi ficha, el ciberdelincuente mueve la suya y así sucesivamente…pero… ¿Quién gana la partida?

Es precisamente a la hora de responder a esta pregunta donde quiero profundizar. La seguridad es dinámica ya que el mapa de amenazas, los tipos de ataques, los riesgos y la tecnología avanzan constantemente y el CISO siempre debe anticiparse a este avance para ir mejorando la seguridad de los sistemas de negocio. Para mejorar la seguridad, el CISO pedirá fondos a la Alta Dirección para llevar a cabo sus estrategias y poder mover “su ficha”.

Es aquí donde entra en juego el parámetro clave: La credibilidad.

Pueden darse dos casos:

Si los incidentes de seguridad han sido pocos y con impactos irrelevantes, el CISO tendrá un “papelón” al explicarle a la Alta Dirección que necesita más fondos para mejorar una “seguridad corporativa” que ya de por sí parece buena. Los directivos pensaran: “ya estamos como todos los años pidiendo más dinero para que luego no pase nada”

Si por el contrario tienes un escenario de crisis por un incidente de seguridad, tal y como le ocurrió a la Plataforma PlayStation Network de Sony, el CISO podrá pedir fondos, pero su credibilidad estará en entredicho.

Ésta, precisamente, es la encrucijada con la que se encuentra el CISO en la organización, con su credibilidad como factor clave, sabiendo que en el dinamismo de la seguridad la ausencia de incidentes juega por un lado en su contra (aparentemente es seguro lo que no lo es tanto y la inversión puede parecer como no prioritaria) y por otro lado a su favor, reflejando que su trabajo es “tan bueno” que los incidentes no se materializan.

Es clave, por tanto, la conciencia de seguridad en la Alta Dirección y el conocimiento de que la seguridad es un proceso dinámico que si se para es más vulnerable. Es necesario hacerle ver a la Dirección que la seguridad no solo se valora como buena o como mala en función de lo que pase sino también de lo que podría pasar y no pasa. Para ello, he ayudado a muchos CISO a crear esa conciencia y ese conocimiento en las organizaciones a través de la exposición de los nuevos riesgos o brechas que se están presentando en empresas similares y de las que no se es consciente. Esta exposición significa “poner en el tejado” de la Dirección la siguiente cuestión: ¿Estáis dispuestos a asumir estos nuevos escenarios de riesgo?

Es esta pregunta la que gana, casi todas las veces, la partida.

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

noreply@blogger.com (Miguel A. Segura) — Fri, 17 Feb 2012 13:19:00 +0000

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.

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

noreply@blogger.com (Albert Vives) — Mon, 13 Feb 2012 09:18:00 +0000

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:

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.
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

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

noreply@blogger.com (David Ortega) — Thu, 09 Feb 2012 10:41:00 +0000

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 personas. La 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.

Gestión TIC. Obsesionado por lo básico

noreply@blogger.com (David Ortega) — Thu, 02 Feb 2012 11:27:00 +0000

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.

¿Por qué falla un Help Desk?

noreply@blogger.com (David Ortega) — Thu, 19 Jan 2012 10:32:00 +0000

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.

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

noreply@blogger.com (Albert Riera) — Wed, 18 Jan 2012 10:57:00 +0000

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).

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

noreply@blogger.com (Pedro Dégano) — Mon, 09 Jan 2012 10:47:00 +0000

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?

Gestión desde la nube

noreply@blogger.com (Joan Ramon) — Mon, 19 Dec 2011 14:42:00 +0000

Los departamentos de TI afrontan el reto de reducir los costes, el retorno de las inversiones realizadas y la entrega de valor al negocio, ofreciendo a la organización servicios eficientes y de calidad. Teniendo en cuenta que las necesidades del negocio cambian constantemente, los departamentos de TI tienen que alinearse a ellas a fin de que el cumplimiento de las metas del departamento de TI permita cumplir las metas del negocio. Para ello es necesario implantar procesos TI que permitan por lo menos:

1. Asegurar los servicios TI a sus usuarios para que estén disponibles, sean fiables y con buen rendimiento.

2. Garantizar la mejora continua de los mismos.

3. Reducir el coste total de provisión y soporte de los servicios TI.

4. Gestionar el conocimiento de la empresa.

5. Mejorar el flujo de información.

6. Aumentar la satisfacción de los usuarios.

7. Demostrar el valor y la aportación del departamento de TI.

Las incidencias y las peticiones que generan los usuarios al departamento de TI tienen un flujo de actividad que supone una importante carga, por ello, se debe poner énfasis en su automatización y optimizar su tratamiento en busca de altas cuotas de eficiencia.

La gestión de incidencias es el proceso que se ocupa del tratamiento de los sucesos que provocan la degradación o pérdida del funcionamiento normal de un servicio, con el objetivo fundamental de recuperar el servicio para el negocio lo más rápidamente posible. Se centra en restaurar el servicio cuanto antes, sin admitir dilaciones por investigaciones técnicas. Su objetivo es que todo servicio caído o degradado retorne cuanto antes a la normalidad. Mantener únicamente esta actividad frenética de “apaga fuegos” no es productivo.

Este proceso es el que más volumen de trabajo genera en TI. Además involucra a un número de actores bastante amplio, desde los teleoperadores, pasando por todas las áreas técnicas, hasta llegar a los desarrolladores de las aplicaciones. Hay que tener en cuenta que lo normal es atender ente 2 y 3 contactos por mes de cada usuario, relacionados a incidencias de servicio. Además hay que considerar que la tendencia es que este volumen de contactos se vaya incrementado, debido al aumento de la diversidad de dispositivos móviles y a la progresiva penetración de las TI en la actividad de la empresa. Por ello, es importante disponer de una organización perfectamente preparada y entrenada para su atención y resolución. Es necesario definir, en la actividad de clasificación, la prioridad con la que se debe tratar la incidencia. Igualmente ocurre a la hora de asignar un orden de resolución.

Actualmente el mercado ofrece muchas opciones para gestionar un departamento de TI y en concreto las incidencias y cambios. Muchos fabricantes de software disponen de herramientas con funcionalidades HelpDesk que permiten crear, gestionar y documentar todas las incidencias y problemas de una empresa. La implantación de una solución de este tipo requiere una mejora de los procesos que implica una mejora de conocimientos del personal y por supuesto una mejora en la tecnología. Una buena forma de mejora de procesos es la reingeniería de los mismos en base a las mejores prácticas (metodologías) existentes en el mercado. Esto implica una automatización y modernización de la infraestructura tecnológica así como un cambio en la manera de trabajar por parte de las personas implicadas. La adopción de todo ello no deja de ser un proceso complicado y en la mayoría de casos ligeramente largo. Sin embargo, la nube, el ya famoso y recurrente “cloud computing”, ofrece nuevas oportunidades de gestión TI. Adoptar una solución de gestión de TI basada en la nube, evita que tengamos que ampliar nuestra tecnología y la empresa se puede centrar en mejorar los conocimientos del personal y adaptar los procesos a la nube sin que estos se vean afectados. Una puesta a punto rápida y sencilla, carente de licencias o agentes/clientes y una modalidad de pago fraccionada y correspondiente al uso que se da. Sin costes de mantenimiento y sin inversión en soporte.

1. SaaS: modelo de distribución de software que proporciona a los clientes el acceso al mismo a través de la red, de manera que libera al cliente del mantenimiento de las aplicaciones, de operaciones técnicas y de soporte.

2. Puesta en marcha: al no haber servicios de implantación ni formación en un tiempo muy reducido la herramienta está operativa.

3. Disponibilidad: La modalidad de licenciamiento Saas ofrece un servicio continuo y accesible desde cualquier lugar y a cualquier hora, puesto que se ejecuta a través del navegador.

4. Ahorro: Una de las ventajas del cloud computing es el ahorro en tecnología ya que al estar en la nube no hay que comprar servidores o recursos.

Service Desk: el Factor Humano

noreply@blogger.com (Adelina Bonet) — Fri, 16 Dec 2011 12:33:00 +0000

Como muchos otros, empecé mis pasos en el ámbito de las TI embarcando en una “galera”. Sí, una galera de combate. En ese momento –hace ya más de 10 años- el concepto de Service Desk no estaba tan extendido y era mucho más conocido y frecuente el término “Helpdesk”.

El volumen de llamadas entrantes era muy elevado y los SLA asociados a la gestión telefónica de la llamada, que por aquel entonces era la entrada principal de incidencias, peticiones, quejas, y preguntas varias, era bastante estricto en cuanto a los tiempos de respuesta y abandono.

El perfil de actividad de los usuarios y clientes que accedían al servicio de soporte era absolutamente típico, por este motivo en cuanto se abrían las líneas telefónicas, la ocupación de los agentes era inmediata y el colapso se producía acto seguido. Las llamadas entrantes, que no dejaban de fluir, entraban en el sistema, escuchaban las opciones y se distribuían en función de la lógica de saltos y grupos diseñada para el servicio en cuestión.

En pocos minutos, las colas empezaban a acumularse y el supervisor cual “cómitre” iniciaba la maniobra: ¡remo de combate!

En los supuestos 3 minutos de media que debía durar cada llamada para poder asimilar las colas en espera, se debía escuchar, entender, registrar, resolver y cerrar o escalar. El proceso de registro debía ser por otro lado completo y adecuado en cuanto a su descripción, categorización y priorización. Sólo puedo decir, que lo intentábamos.

Ahora los tiempos han cambiado y el usuario dispone de múltiples fórmulas para contactar con su Service Desk y existen muchos automatismos e integraciones que facilitan el proceso de registro. Ahora bien, dado su coste, no podemos afirmar aquí que la implantación de dichos automatismos esté muy extendida, por lo que las dificultades en el proceso de registro siguen estando patentes. El operador gestiona su tiempo para “procesar la información” según su criterio y según la presión que asimile.

¿De qué depende entonces? ¿Es un problema de falta de conocimientos? ¿De procedimientos? ¿De metodología de trabajo? En parte, y sólo en parte, ya que aunque existan, no se contempla el factor humano, y éste es, de momento, un elemento muy importante, tanto a la hora de proporcionar el soporte, como a la hora de efectuar el proceso de registro y aprender de él.

A mi entender, el problema guarda relación directa con los siguientes aspectos:

El esfuerzo en cumplimentar los datos de registro correctamente todavía no se percibe como proporcional al valor intrínseco de la información que aportan. Por tanto, sigue faltando equilibrio entre el nivel de “detalle” requerido, su “valor” y el tiempo invertido en su tratamiento.

Los procesos se ejecutan de forma intuitiva, y su recurrencia, más o menos continuada, establece las bases de trabajo.

De lo anteriormente descrito, algún lector podría desprender cierto grado de determinismo que le llevara a cuestionarse la utilidad de los estándares metodológicos y “best practices”. Pero no estoy hablando de determinismo, estoy hablando de aprendizaje.

“La capacidad de evaluar – el nivel más alto de la taxonomía cognitiva – se basa en el supuesto de que el estudiante, para ser capaz de evaluar, tiene que disponer de la información necesaria, comprender esa información, ser capaz de aplicarla, de analizarla, de sintetizarla y, finalmente, de evaluarla” (E.W. Eisner a propósito de B. Bloom. Perspectivas: revista trimestral de educación comparada (París. UNESCO: Oficina Internacional de Educación), vol. XXX, n° 3, septiembre 2000, págs. 423-432).

Así pues, el factor humano no es un elemento determinante, pero sí condicionante del contexto de la prestación del servicio, porque en ese proceso cognitivo de comprender, evaluar y aplicar la información participan aspectos como la inteligencia, el contexto social, la motivación, así como otros componentes emocionales del individuo.

Sin olvidar aspectos tan esenciales como disponer de un dimensionamiento correcto y de las herramientas necesarias, podemos afirmar que se requiere un cambio de enfoque, pero incluso antes de que le pongamos nombre (ITIL, ISO/IEC 20000, etc.) esta diversidad sólo podrá gestionarse con enfoques que aporten sistemática, es decir que:

Se ajusten a un conjunto organizado de reglas
Se desarrollen de manera ordenada
Se realicen de manera regular

Aunque existan diferentes formas de hacer las cosas, siempre deberá existir un sistema estructurado de aprendizaje, una buena gestión del conocimiento, y una correcta definición de los procedimientos de trabajo que fundamenten sus actividades en un adecuado balance entre esfuerzo y valor; y por supuesto, algo que suele olvidarse muy a menudo: el control y seguimiento continuo de éstas y todas las actividades que se deriven.

X Jornada Internacional de Seguridad - ISMS

noreply@blogger.com (Oriol Martínez) — Fri, 02 Dec 2011 09:53:00 +0000

El martes 29 de Noviembre asistimos a la X Jornada Internacional de Seguridad de la Información organizada por el ISMS Forum Spain centrada en la CiberDefensa y CiberSeguridad.

El evento se celebró en la Ciudad de las Artes y las Ciencias de Valencia, un escenario que no conocíamos y que nos pareció idóneo para la jornada.

El congreso, que comenzó a las 9 y terminó pasadas las 18, contó con más de 20 ponentes de ámbitos distintos, desde expertos en seguridad, pasando por representantes de proveedores de seguridad hasta CISOs de importantes organizaciones.

Desde mi punto de vista (soy Consultor de Seguridad), las mejores ponencias fueron las posteriores al Coffee-break, concretamente :

“La estrategia Española en materia de CiberSeguridad” de Javier Candau (Subdirector General Adjunto del Centro Criptológico Nacional, CCN)
“Why security breaches are occurring? The Data Breach Investigations Report 2011” de Jelle Niemantsverdriet (Principal Consultant Forensics and Investigative Response), Verizon Business Security)

Javier Candau (cuyo apellido me pareció muy indicado para su profesión), comentó las distintas estrategias tomadas por otros países en cuanto a CiberSeguridad. Explicó las distintas amenazas a las que un país puede estar expuesto y de la importancia de proteger las infraestructuras críticas. Mencionó varios conceptos como el cibercrimen, el ciberespionaje, el hacktivismo o el ciberterrorismo. Dentro de la estrategia española, comentó la relevancia del Esquema Nacional de Seguridad (ENS).

Jelle Niemantsverdriet (@jelle_n) en una ponencia muy visual y llena de datos interesantes (se puede consultar aquí) remarcó la importancia de revisar los LOGS regularmente para conocer las intrusiones que las organizaciones sufren. Jelle en un baile de estadísticas de distintas fuentes, propone aprender de los errores de los demás. Comenta también que tal como ocurre en los accidentes de avión, las intrusiones no están normalmente producidas por un GRAN error, sino por la suma de pequeños errores que llevan a la catástrofe. El ponente mostró un gráfico con el descenso de brechas de información registradas en los dos últimos años. Su explicación a éste hecho es la mejora de los sistemas de seguridad, el incremento de la concienciación en seguridad de las organizaciones, el endurecimiento de la legislación y por tanto, que muchos crackers han sido detenidos con condenas severas. Otra de sus explicaciones al descenso es que las brechas de seguridad no se han producido en las grandes empresas, ya que estas han tomado mayor conciencia de la seguridad, sino que se dan en empresas mucho más pequeñas y que no detectan los ataques. En sus palabras, los crackers “ya no cazan elefantes, ahora cazan conejos”.

Después de un abundante y delicioso almuerzo a base de pequeñas tapas, la tarde se dividió en:

Mesa redonda: “La entrada en vigor de la normativa española en materia de infraestructuras críticas”
Mesa redonda: "El nuevo panorama de ciberamenazas. Casos de éxito y buenas prácticas."
“El headhunting de profesionales y directivos de la Seguridad ¿Qué está demandando el mercado?" de Miguel Portillo (Associate Director, Michael Page Executive Search)

Las dos mesas redondas fueron muy interesantes, aunque por mi vocación, encontré más interesante la segunda (sobre ciberamenazas y casos prácticos), que la primera (centrada en normativa e infraestructuras críticas).

Por último, la ponencia de Miguel Portillo de Michael Page fue muy interesante al tratar de un tema totalmente distinto a todos los tratados durante la jornada. Se hizo una muy buena contextualización del mercado laboral europeo y español. Se centró en la figura del CISO, tanto en sus características personales como lo que demanda el mercado.

En conclusión, la valoración del evento fue muy positiva y creo que el resto de asistentes coincidirán en ello, tanto por la organización como por el contenido de las charlas. Espero poder asistir al siguiente evento ya que fue una magnífica experiencia.

El error más común a la hora de Analizar y Gestionar los Riesgos Tecnológicos

noreply@blogger.com (Pedro Dégano) — Fri, 07 Oct 2011 09:41:00 +0000

El análisis de riesgos tecnológicos es la piedra angular utilizada por el CISO para gestionar la seguridad de los sistemas de información. Consiste en un estudio pormenorizado de las amenazas y eventos a los que están expuestos los activos de información que conforman los servicios tecnológicos, y los impactos que se provocarían en el negocio en caso de que estas se materialicen.

Existen multitud de metodologías y de enfoques, pero a menudo, y sobre todo, cuando se decide abordar por primera vez un análisis de este tipo, se cometen errores de base que pueden comprometer el éxito del proyecto.

El análisis debe surgir con un doble objetivo, por un lado estudiar los riesgos asociados a los sistemas de información y su entorno, y por otro, aplicar las medidas necesarias para conocer, prevenir, impedir, reducir o controlar los riesgos estudiados hasta niveles aceptables por la organización.

Sin embargo, a pesar de que los objetivos suelen estar claros, no siempre se consiguen, ya que las organizaciones han elevado el grado de exigencia, como consecuencia tanto del aumento acelerado del volumen y dependencia de las tecnologías de la información, como de los nuevos escenarios (nuevas amenazas, tecnologías novedosas, vulnerabilidades escondidas, nuevas salvaguardas…) a los que nos enfrentamos.

Por tanto para conseguir gestionar los riesgos con éxito en este nuevo entorno más complejo, es necesario tener un equipo experto que plantee el análisis y gestión de riesgos como un conjunto de iteraciones, en las cuales, en cada una de ellas, se analice el escenario actual y se amplíe el nivel de detalle en función de las necesidades del negocio.

En ocasiones las organizaciones incurren en el error de plantear un análisis estático con un principio y un fin, al que no se le da continuidad en el futuro y donde se intenta analizar de golpe el todo. La clave, desde nuestro punto de vista, a la hora de abordar un proyecto de este tipo, es plantear el análisis en fases, en modo dinámico de gestión continua de tratamiento de riesgos, en la cual en las diferentes iteraciones del estudio se vayan incorporando nuevos servicios, aumentando el catálogo de amenazas, contando con nuevas salvaguardas. La gestión de riesgos consistirá en ir viendo cómo evoluciona el riesgo en cada iteración, implantando controles, actualizando el escenario tecnológico, garantizando que se toman decisiones para mitigar, transferir o asumir el riesgo hasta los niveles que la Alta Dirección considera como “aceptables”, creando a su vez valor al negocio mediante:

Integración con los procesos organizacionales

Forma parte de la toma de decisiones

Atiende explícitamente los aspectos de incertidumbre

Es sistemática, estructurada y oportuna

Está alineada con el contexto externo e interno de la organización

Es dinámica, iterativa y responde a los cambios

Facilita la mejora continua en las organizaciones

Los 3 errores más comunes a la hora de contratar un servicio externo

noreply@blogger.com (Adelina Bonet) — Fri, 30 Sep 2011 10:52:00 +0000

Asumir completamente los requerimientos y costes de la prestación de un servicio o bien, contratarlo a un proveedor externo, suele ser una de las decisiones más controvertidas que una organización debe tomar. Pero ¿Qué aspectos inciden con mayor fuerza en la decisión final?, ¿Son estos aspectos realmente, significativos o a menudo se valoran desde una perspectiva errónea?

Las respuestas a estas preguntas están en el día a día, o sino ¿Quién no conoce casos de cancelaciones contractuales antes de que finalice el período estipulado?, ¿Penalizaciones por incumplimiento de contrato?, ¿Hastío de las relaciones cliente-proveedor?, por poner sólo unos ejemplos.

El punto de vista de valoración y las expectativas previas juegan, por tanto, un papel muy importante. Así pues, podemos considerar que en función del enfoque y la expectativa que se asuma, se pueden cometer, frecuentemente, los siguientes 3 errores:

Presupuesto vs Oferta

El presupuesto de gasto (o la necesidad de reducir costes), suele ser un elemento decisorio de peso a la hora de valorar distintas ofertas de proveedores, especialmente, en tiempos oscuros económicamente hablando, como los actuales. Se cumple la máxima: “para que voy a pagar más, si puedo obtener lo mismo por menos”. Si bien es normal y correcto comparar ofertas y prestaciones, el error está en considerar propuestas “supuestamente económicas” para prestaciones “supuestamente de calidad” que acaban siendo superficiales, no disponen de la flexibilidad necesaria para adaptarse a requerimientos cambiantes o a la propia complejidad de la organización.

Contrato legal vs SLA

Muchos contratos de servicios se resuelven a través de una correcta y concreta documentación legal que establece los detalles legales de la prestación que se contrata y las obligaciones de ambas partes firmantes, pero no siempre se acompaña o amplía con el establecimiento de un acuerdo de nivel de servicio (SLA) donde se detallen los requerimientos de servicio y se establezcan tanto el nivel de servicio requerido, como el umbral considerado por la organización para identificar un nivel inaceptable, el marco de trabajo, o el modelo de relación que deberá enmarcar la interacción cliente-proveedor.

En otros casos, sí existen estos acuerdos SLA, pero no son suficientemente claros o incluyen objetivos demasiado ambiciosos que alimentan la expectativa del cliente pero son claramente inasequibles por parte del proveedor, que en ocasiones, acepta “gratamente” el pago de las penalizaciones acordadas, antes que invertir en la mejora de los servicios que presta.

Se cumple la máxima: “el contrato legal me asegura el cumplimiento de todos mis deseos”. El error está en considerar que el contrato siempre cubre mis expectativas de servicio, incluso cuando éstas ni siquiera hayan sido formuladas e incluidas en él.

Seguimiento vs “laisser faire”

Si focalizarse en el presupuesto y no concretar explícitamente los requerimientos y expectativas de servicio son errores comunes, también lo es considerar que por el hecho de contratar un proveedor externo para que proporcione el servicio que necesitamos, no es necesario que “invirtamos tiempo y esfuerzo” en su seguimiento. Se cumple la máxima: “ya saben lo que tienen que hacer. Los hemos contratado para poder dedicarnos a otras tareas”.

Este aspecto está vinculado al punto anterior y es normal que no se tenga en cuenta, si previamente, no se ha tenido en cuenta el establecimiento de un acuerdo de nivel de servicio realista que establezca el marco de control del seguimiento (indicadores de rendimiento, métricas, etc.). El error está en no evaluar periódicamente la prestación del servicio para poder confirmar que sigue siendo adecuada a los requerimientos que nos han llevado a contratarlo.

En conclusión, el error más común es el de no conocer bien la expectativa de servicio, es decir, saber exactamente, qué es lo que se necesita, qué es lo que el proveedor ofrece, qué es lo que se contrata y cuál es el coste real de la prestación, y la estrategia que finalmente, se determine no pueden dejarse a merced de una cuestión de enfoque.

“El pesimista se queja del viento. El optimista espera que cambie. El realista ajusta las velas” (Guillen G. Ward)

Gestión de la Demanda y Proyectos

noreply@blogger.com (Joan Ramon) — Fri, 16 Sep 2011 10:08:00 +0000

¿A día de hoy es posible para los ejecutivos de TI ver, en qué proyectos y actividades operacionales deberían estar trabajando, qué porcentaje del presupuesto se destina a los proyectos, los niveles de capacidad de los recursos, y la alineación con las necesidades del negocio?.

Es posible! Gracias a una buena gestión de la demanda y una buena gestión de proyectos.

Los departamentos de TI absorben una demanda creciente con recursos ajustados. Con estas premisas es difícil responder plenamente a las peticiones del negocio, así como evaluarlas y priorizarlas adecuadamente. Además, los proyectos resultantes no se gestionan adecuadamente en calidad, tiempo y presupuesto. De esta manera el riesgo de que el resultado u oferta final al cliente no concuerde con lo demandado inicialmente es muy alto.

Gestionar la demanda

La Gestión de la Demanda es la encargada en estos casos de redistribuir la capacidad para asegurar que los servicios críticos no se ven afectados o, cuando menos, lo sean en la menor medida posible. Para llevar a cabo esta tarea de forma eficiente es imprescindible que la Gestión de la Capacidad conozca las prioridades del negocio del cliente y pueda actuar en consecuencia.

Una buena gestión de la demanda de la organización:

Permite que los departamentos de TI puedan enfocar sus recursos y su presupuesto a las prioridades del negocio.
Consolida y prioriza todos los proyectos con mayor y mejor visibilidad y control, centrándose en aquellos de mayor prioridad cumpliendo los compromisos de nivel de servicio.
Automatiza este ciclo de vida de la demanda parar alinearse con los procesos de negocio y reducir el tiempo de resolución de las solicitudes asociadas a la demanda de servicios.
Subsanar la degradación del servicio por aumentos no previstos de la demanda.

Gestionar proyectos

Tan importante como gestionar adecuadamente la demanda, es realizar una buena gestión de los proyectos resultantes de la misma. De esta manera sabremos en todo momento qué proyectos están centrados en aumentar el valor del negocio, y cuáles en optimizar la prestación de servicios de TI y reducir los costes. Una buena gestión de proyectos permite:

Medir el progreso del proyecto y los tiempos del mismo: (Integración con diagramas de Gantt, por ejemplo) de forma automatizada, de tal forma que cada vez que un proyecto está programado, se calcula y destaca visiblemente las tareas más importantes. Las tareas se asignan a los recursos de cada usuario.
Visibilidad financiera: para la toma diaria de decisiones sobre el departamento y sus proyectos, una correcta visualización del rendimiento financiero mediante la recopilación de los costes reales.
Plan presupuestario: El objetivo es establecer y administrar el presupuesto de TI durante todo el ciclo de vida del proyecto. Los directores de IT obtienen la flexibilidad necesaria para adaptarse con rapidez, a medida que cambian las previsiones de los objetivos de negocio.
Gestionar los recursos: (actividades estratégicas y operativas en cualquier etapa del ciclo de vida del proyecto). Permite un completo entendimiento de los recursos internos o contratados que se encuentran comprometidos y/o asignados a diferentes tareas o proyectos. De esta manera, los jefes de proyectos pueden responder rápidamente a los cambios con una clara comprensión de los posibles efectos en la capacidad de los recursos y en la priorización de trabajo.
Automatización: Habitualmente, las empresas tratan un volumen de cientos de proyectos y equipos que se distribuyen geográficamente, a esto se añade la participación de socios externos, subcontratistas y empresas internacionales. Para afrontar este reto, la automatización de los flujos de trabajo en el proceso de gestión de proyectos, permite el control del mismo reduciendo los tiempos de ejecución, el presupuesto, y por ende los riesgos y costes asociados.

Es prácticamente imposible abordar este tipo de gestión y obtener los beneficios expuestos sin contar con unas herramientas adecuadas. Por ello es interesante acudir al mercado para ver las posibilidades que este nos ofrece. (Project & Portfolio Management).

Cuadrante Mágico de Gartner (soluciones PPM)

Servicios TIC: Equilibrio entre garantía y utilidad

noreply@blogger.com (Miguel A. Segura) — Fri, 09 Sep 2011 08:12:00 +0000

La gestión de servicios TIC es un concepto que se ha convertido en la piedra angular para todos aquellos que nos dedicamos a la prestación de servicios, en cualquiera de sus vertientes.

Mucho se ha hablado sobre cuál es el modelo de gestión más adecuado, cuáles son las mejores prácticas, e incluso si implantar un sistema de gestión introduce demasiada burocracia. Sin embargo, mi intención es hacer una reflexión sobre algo mucho más elemental, pero que considero que a menudo se pierde de vista: el propio concepto de SERVICIO.

Realmente, ¿Qué entendemos por servicio? Son de aquellas cosas intangibles que nos cuesta definir. De hecho la RAE presenta 20 entradas para este concepto, y creo que ninguna de ellas se acaba de ajustar al concepto de servicio TIC. Por ello, prefiero acudir a ITIL®, que define el servicio como “un medio de entrega de valor a los clientes facilitando los resultados que los clientes desean lograr sin la responsabilidad sobre los costes y riesgos específicos”.

El concepto de costes y riesgos específicos es bastante intuitivo, por ejemplo, todos necesitamos un teléfono móvil profesional, pero ninguna compañía decidiría desplegar su propia red de comunicaciones en lugar de contratar el servicio a un operador (no estamos dispuestos a asumir los costes y riesgos específicos de desplegar el servicio).

Sin embargo, ¿En qué consiste la entrega de valor? A nivel conceptual, el valor que se entrega es el hecho que nos diferencia de la competencia, el que hace que el cliente nos perciba como un activo para su operativa y no como un gasto innecesario, y en definitiva, el que hace que nos seleccione a nosotros en lugar de a cualquier otro competidor.

En este punto, es importante aclarar que esta definición es aplicable a cualquier proveedor de servicios, incluso para aquellos cuyo cliente es su propia organización: Al fin y al cabo, la provisión con recursos propios también supone un coste, y todo servicio podría llegar a ser externalizado. Por este motivo, los proveedores de servicios deberíamos analizar si para nuestro cliente los servicios ofrecidos “valen más de lo que le cuestan”.

Cuando explico estos conceptos nuevamente acudo a ITIL® para presentar la composición de valor a través de dos conceptos clave: la UTILIDAD y la GARANTÍA.

Utilidad es qué se provee. La característica de cumplir con un objetivo, es decir, que realmente aporte “algo” a la organización. En caso contrario, ¿Para qué ofrecer este servicio? Y en este sentido, se trata de aportar una de las siguientes características:

Soportar el rendimiento: supone un rendimiento positivo en las tareas realizadas, o en los resultados obtenidos. Volviendo al ejemplo anterior, la telefonía fija facilitó la comunicación a larga distancia, agilizando así la operativa de las organizaciones.

Eliminar restricciones: permite realizar una tarea que en caso de no disponer del servicio sería imposible. En el momento de su aparición, la telefonía móvil no aportaba una nueva utilidad (básicamente el resultado era el mismo que la telefonía convencional), sin embargo, eliminó la barrera de tener que buscar un teléfono o una cabina telefónica, la de no poder localizar en cualquier momento a una persona, etc.

Garantía es cómo se provee. Consiste en ofrecer dicho servicio en buenas condiciones, de forma que el cliente pueda confiar en él. Para ello, obligatoriamente deberá cumplir con las siguientes características:

Suficiente disponibilidad: Imaginemos que la mitad de las veces que intento llamar por teléfono no puedo establecer la conexión. ¿Cómo puedo valorar positivamente este servicio?

Suficiente capacidad: Si el sonido se interrumpiera constantemente cuando paso por una zona con más personas hablando por teléfono, el servicio resultaría poco fiable.

Suficiente continuidad: Si en mi casa dejara se tener cobertura durante toda una semana porque ha caído un repetidor de señal, ¿Continuaría confiando en el operador?

Suficiente seguridad: Por último, si cualquiera pudiera interceptar mis conversaciones, seguramente dejaría de utilizar este servicio para preservar mi intimidad.

Todo ello resulta bastante lógico e intuitivo, sin embargo, a la hora de la verdad, acaba difuminándose. Normalmente el cliente se preocupa por exigir UTILIDAD (pese a que evidentemente también requiere un nivel aceptable de garantía), y son el grupo de desarrollo y los responsables funcionales quienes se focalizan en conseguir dicho objetivo. Como contrapartida, el departamento de sistemas se centra en conseguir la GARANTÍA del servicio. ¿Dónde se rompe este equilibrio? La respuesta es clara: en el momento en que se valoran las restricciones de coste y tiempo. Y en estos casos, normalmente se opta por dar prioridad a la UTILIDAD en detrimento de la GARANTÍA.

Sin embargo la lógica dice que únicamente cuando se cumplen las dos características (tanto la utilidad como la garantía), estamos en condiciones de ofrecer valor al cliente. Luego, la pregunta es evidente: ¿realmente todos los servicios que ofrecemos están aportando valor? Y si la respuesta no está clara, será el momento de hacer algo al respecto …. quizás revisar el catálogo de servicios.

ITIL® es una marca registrada de la OGC (Office of Government Commerce) en Reino Unido, resto de la UE y otros países

Wifi: La amenaza invisible

noreply@blogger.com (Oriol Martínez) — Mon, 04 Jul 2011 07:32:00 +0000

Las redes inalámbricas o redes wifi están presentes en la mayor parte de las organizaciones hoy día. Es más, muchos comercios, hoteles, bares y restaurantes lo ofrecen de forma gratuita a sus clientes. La moda de las redes wifi abiertas pasó y la gran mayoría ya usan protocolos como los WEP (Wired Equivalent Privacy) o WPA/WPA2 (Wi-Fi Protected Access) para proteger el acceso. La gente se siente segura detrás de contraseñas interminables y complejas de números, símbolos, mayúsculas y minúsculas. Pero ¿estamos realmente seguros? ¿Qué pasaría si alguien pudiera travesar esta barrera de protección?

Crackeo de Wifis

Los protocolos más comunes de cifrado wifi son WEP y WPA/WPA2. El algoritmo WEP se rompió hace años. Por eso, obviando los métodos o detalles técnicos, una red wifi WEP con clientes haciendo uso de ella se tardaría desde segundos (claves por defecto de operador), a una hora como máximo en descifrar. Cuando una contraseña WEP es la única barrera de protección a la red interna la organización tiene definitivamente un problema.

Existen métodos para el crackeo de redes WPA/WPA2, aunque dependen en gran medida de la fortaleza y longitud de la contraseña. Es preferible tomar las recomendaciones típicas sobre políticas de contraseñas y cambiarla cada cierto tiempo.

Algunos de los métodos para conseguir contraseñas WPA/WPA2 agilizan el proceso con el uso de clústers y GPUs, ya que el crackeo se puede realizar offline, es decir, fuera del alcance de la red, una vez capturados los datos necesarios (WPA handshake).

Segmentación e independencia

Otros de los factores que debemos analizar son la información, servicios y recursos a los que pueden acceder los usuarios una vez obtienen acceso. Se debe tener en cuenta por dos razones: por los distintos roles de usuarios que pueden acceder a dicha red y por los usuarios no legítimos que puedan obtener la contraseña (crackers, curiosos, antiguos empleados, etc.).

No es lo mismo un Director General de una empresa accediendo por wifi a los archivos confidenciales de una empresa que un empleado externo o un invitado accediendo a internet. Se debe ser riguroso con el control y acceso a las redes y cuidadoso con la asignación de permisos para los distintos roles de usuario.

Cada vez es más importante diseñar una estructura de red que mantenga una arquitectura con dos o más redes separadas o incluso segmentadas internamente a través de redes virtuales VLANs.

Por otro lado, imaginemos por un momento que alguien de forma fraudulenta o un antiguo empleado accede a la red wifi corporativa. ¿Sabemos con seguridad a qué recursos tendría acceso? ¿Se auditan o monitorizan estas acciones de forma regular? ¿Cuándo fue la última vez que se cambió la contraseña de las redes wifi? La contraseña de la red inalámbrica no puede ser nunca la única forma de protección.

Sniffing de tráfico

Todos los datos/paquetes que se envían por redes inalámbricas, pueden ser interceptados por tarjetas en modo monitor. En los protocolos WEP y WPA/WPA2 los datos interceptados están cifrados, pero en el protocolo abierto (sin contraseña), los datos transmitidos pueden ser capturados y leídos tal como son emitidos.

Lo que mucha gente no sabe, es que conociendo la clave de una wifi puede descifrarse el tráfico entre emisores y receptores. La prueba de concepto siempre sorprende, y el nivel de seguridad al que se está expuesto dependerá del protocolo de red usado. Si se usan FTPS, HTTPS, ssh, nuestros datos siempre estarán más seguros que con los protocolos FTP, HTTP o telnet en los que pueden verse en texto plano datos y contraseñas. En resumen, alguien que supiera la contraseña de la red, no sólo podría campar a sus anchas en la red, sino que podría recopilar credenciales de la organización.

Para estas pruebas de concepto, existen programas como Firesheep (addon de Firefox -http://codebutler.github.com/firesheep/) o Faceniff (Aplicación de Android http://faceniff.ponury.net/) que sorprenden por su facilidad de uso, y por los resultados obtenidos. Existen herramientas de uso más complejo que consiguen resultados más sofisticados y exhaustivos .

Medidas de seguridad adicionales

Existen varias medidas complementarias a una simple contraseña:

Filtrado de MAC: en grandes entornos puede ser complicado gestionarlo, pero es un método de control simple pero efectivo. Debemos tener en cuenta que existen técnicas sencillas de mac-spoofing (http://www.govannom.org/seguridad/14-wifi-wireless-redes/154-como-hacer-mac-spoofing.html) y también es cierto que algunos Access Point pueden detectar el mac-spoofing. Tal como la contraseña, no puede ser la única medida de seguridad.
SSID oculta: Medida que sirve básicamente para evadirse del punto de mira de curiosos. Cualquiera con los conocimientos y herramientas necesarias puede obtener fácilmente el SSID (también conocido como nombre de la red). La seguridad por oscuridad se convierte en un sencillo paso más en el crackeo de la red y más cuando el atacante sabe qué se busca.
SSID distinto: Una medida de seguridad sencilla es renombrar la wifi con un SSID que no identifique la empresa.
Otras: a medida que crecen las organizaciones, la complejidad de sus redes y la concienciación en la seguridad de la información se usan soluciones más sofisticadas como pueden ser NAC, UAC, Radius o portales cautivos por poner algunos ejemplos. Todas son herramientas que mejoran de forma sustancial la seguridad de las redes inalámbricas.

En Conclusión:

Para evitar la intrusión de usuarios maliciosos y garantizar la confidencialidad de los datos es recomendable seguir las siguientes instrucciones:

Las redes wifi deben considerar la encriptación WPA2 preferentemente, con una contraseña compleja y larga (mínimo 12 caracteres).
Debe existir una segmentación de red adecuada para los tipos de usuarios que se conectaran a la red inalámbrica.
Crear una red de invitados separada de la red interna, para conceder únicamente conexión a internet a los proveedores que lo requieran.
No se puede confiar solamente en una contraseña, el uso de más medidas de seguridad es muy recomendable.
Monitorizar la red y los equipos conectados a ella, ya sea de forma manual o automatizada para evitar ataques.

Es posible que alguno piense que estas medidas son muy básicas, pero nuestra experiencia nos dice que no siempre se siguen estas recomendaciones. Para ilustrarlo, desde nuestras oficinas, se puede ver una red inalámbrica con el SSID que es el nombre de una organización que utiliza una clave WEP. Esperamos por su bien, que sea una red de invitados bien gestionada. Aunque desafortunadamente, creo que eso sería mucho esperar.

Evento Hacking Ético

noreply@blogger.com (David Ortega) — Wed, 29 Jun 2011 10:53:00 +0000

Los recientes robos de datos de usuarios de la plataforma PSN de Sony y del INTECO, así como las actividades de Anonymous, han puesto en primera página de actualidad el problema de la vulnerabilidad de los sistemas de organización frente a ataques malintencionados.

Esto nos lleva a preguntarnos:

Si le ha pasado a ellos ¿podría suceder también en mi organización?

¿Dispongo de las medidas de seguridad necesarias para evitar un ataque similar?

En caso de que sucediera ¿cuánto tardaría en detectarlo?

¿Nuestra organización puede permitirse ser victima de un ataque parecido?

¿Qué nivel de madurez tiene nuestra seguridad de la información?

¿Cuáles son nuestras vulnerabilidades más críticas?

¿En qué debemos cambiar para mejorar nuestra seguridad?

¿Son efectivas las medidas de seguridad que tenemos implementadas?

Abast Grup y Buguroo (Grupo Ecija Consulting&Security) os invitan a este seminario en el que os mostraremos cómo mejorar vuestros niveles de seguridad.

El evento se realizará mañana día 30 de junio en las oficinas de Abast en Barcelona (c/equador 39-45). Se iniciará a las 9:45 y finalizará aproximadamente sobre las 12:00h. La agenda será la siguiente:

Café de bienvenida y entrega de documentación

Charla sobre hacking ético: ¿Cómo?, ¿cuando?, ¿donde? a cargo de David Ortega, Director de Consultoría y Auditoría de TI de Abast Systems

Demostración práctica de la herramienta Buguroo de análisis de vulnerabilidades en código fuente a cargo de Abel González Lanzarote, Director de Operaciones de Buguroo Offensive Security

Ruegos y preguntas

Aperitivo

Para apuntaros podéis llamar al 902 486 901 o inscribiros en www.abast.es/seminarios. Os esperamos.

Monitoriza tu negocio

noreply@blogger.com (Joan Ramon) — Fri, 10 Jun 2011 09:16:00 +0000

Hoy en día monitorizar el estado de los servidores, los tiempos de respuesta e incluso el rendimiento de las aplicaciones, no es suficiente. Una monitorización transaccional es un componente clave en la estrategia de la gestión de servicios de negocio que permite a las TI mejorar los resultados de las empresas.

Para tener una correcta visión del negocio es necesario:

Medir y administrar los procesos críticos para asegurar la obtención de resultados esperados.
Monitorizar de arriba abajo la tecnología con el fin de integrar a usuarios finales y perspectivas de sistema, dando una imagen clara de la complejidad de la infraestructura que soportan las aplicaciones más importantes para el negocio.

El poder medir la experiencia del usuario final ayuda a solucionar y entender los problemas y requisitos de un departamento de TI. Para ello es necesario ejecutar transacciones controladas de forma repetitiva. Gracias a este control obtendremos datos de rendimiento (tiempo de respuesta) y disponibilidad de las transacciones monitorizadas, acelerando la labor de investigación de un problema y su resolución cuando se detecta.

Cuando los usuarios interactúan con las aplicaciones, sus acciones incluyen una serie de peticiones que interactúan con los componentes tecnológicos (firewalls, switches, routers, servidores, bases de datos,...) que generan respuestas que deben ser validadas y traducidas como tiempo de respuesta y disponibilidad.

Podemos identificar como una correcta monitorización del negocio la que:

Se realiza desde múltiples localizaciones (dentro y fuera de los firewalls) obteniendo medidas de disponibilidad y rendimiento.
Permite detectar problemas que pueden impactar a los usuarios antes de que éstos queden afectados.

La captura minuciosa de estos datos de forma repetitiva y consistente desde cualquier lugar de la red permite crear una línea base de funcionamiento y tener una visión clara del funcionamiento de las aplicaciones monitorizadas. De esta forma podremos alinear la organización IT con las prioridades de negocio.

Al fin y al cabo se trata de:

Capturar de forma rápida la actividad en tiempo real de los usuarios, viendo donde se hizo el clic así como las páginas y los errores que percibo o no el usuario.
Comprender el impacto que tienen en el negocio los incidentes en la disponibilidad del servicio
Dar la prioridad adecuada para responder a los múltiples problemas en el orden correcto.

Todas estas prácticas darán valor al departamento de TI que proveerá al negocio:

Una visualización en profundidad de los procesos empresariales.
Un seguimiento y medida de las transacciones individuales conforme progresan a través de sus cauces de proceso.
Convergencia entre los sistemas de bajo nivel y monitoreo en la red, y los procesos de negocio de alto nivel.

Por último, hay que proporcionar al negocio de una solución eficaz para reducir el número, duración y gravedad de las interrupciones del servicio. Para ello hay que realizar un análisis para manejar los problemas de manera integral, que podemos dividir en dos ramas:

Análisis proactivo: proporciona una visibilidad avanzada en interrupciones en el servicio al mostrar problemas y automáticamente aislar sus las causas del mismo. Esta capacidad permite solucionar el problema antes de que se produzcan impactos en la empresa.
Análisis reactivo: En el caso de que se produzca un incidente o problema, el análisis reactivo reduce el tiempo medio de reparación (MTTR).

(MTTR es el acrónimo de las palabras inglesas Medium Time To Repair, o tiempo medio hasta haber reparado la avería).

El mercado actual ofrece herramientas varias para conseguir este tipo de monitorización, pero lo más importante es hacer un análisis del negocio, las aplicaciones y los usuarios, desde un punto de vista de valor para poder medir cada uno de los mencionados de la forma correcta.

Las FAQ del Hacking Ético

noreply@blogger.com (Oriol Martínez) — Thu, 19 May 2011 09:56:00 +0000

Antes de realizar un proyecto de hacking ético, test de penetración o auditoria de seguridad surgen ciertas preguntas comunes que nos gustaría responder. Estas son las FAQ (Frequent Asked Questions) que surgen antes de afrontar un proyecto de este tipo.

¿Porqué realizar una Auditoría de seguridad?

Las razones son muy variadas, aunque las más comunes son: prepararse para auditorías corporativas obligatorias, auditorías de certificación (ISO27000, SOX, Basilea, VISA, etc.), cambios recientes en la infraestructura, comprobar el funcionamiento de nuevos productos tecnológicos, iniciarse en la gestión de la seguridad o un plan director de seguridad, conocer las prioridades de inversión en seguridad, justificar inversiones o proyectos, conocer el riesgo potencial existente, etc.

¿Como se van a ver afectados mis sistemas durante la auditoría?

Para responder a esta pregunta se debe tener en cuenta que nuestro objetivo durante estos proyectos es el de vulnerar la confidencialidad de los sistemas de información de la forma más discreta y sigilosa posible.

La afectación típica que reciben los sistemas, es un ligero incremento de tráfico provocado por los distintos tipos de ataque que en la mayoría de casos es imperceptible. En casos en que el cliente desee realizar algún tipo de prueba específica que pueda comprometer la disponibilidad o integridad de algún sistema concreto, se advertirá y se tomarán las medidas de seguridad necesarias para provocar un impacto controlado.

¿Qué tipos de auditorías de seguridad se realizan?

Hay varias formas de catalogarlas y definirlas. Una forma común es catalogarlas por la red dónde se encuentra el atacante, interna o externa (perimetral). Aunque la categorización que más nos gusta es la siguiente:

Caja Negra: Se trata de la auditoría en los que el atacante no debe conocer ningún detalle de los sistemas a auditar, sólo información mínima y realiza un ataque externo.
Caja Gris: En este caso se realiza desde dentro de la organización. Se conecta un portátil a una toma de red, o se accede a un ordenador con un perfil estándar y privilegios limitados.
Caja Blanca: Este tipo de auditorías se realizan desde dentro de las instalaciones del cliente. Se da a los auditores credenciales válidas y una lista de IPs o de servidores de los cuales se quieren auditar riesgos y vulnerabilidades.
Aplicación Web: En este tipo de auditoría se revisa la seguridad de una aplicación web específica. Por norma general se auditan los riesgos más comunes, publicados en OWASP Top 10. Es común realizarlas antes de poner en producción la aplicación web, o para auditar su seguridad si ha sido realizado por un tercero.
Completa: Es una combinación de las anteriores (sobre todo de las 3 primeras), es habitual realizarlas cuando se quiere hacer un análisis general de la seguridad de una organización. Los resultados son muy completos y abarcan muchos ámbitos (webs, arquitectura de redes, DMZ, correo, hardware, software, wifi, configuración, intranet, proxy, firewall, etc.).

¿Qué tipo de ataques se realizan en una auditoria?

Esta respuesta es compleja, ya que dependerá del tipo de proyecto y del sistema a auditar. Si se trata de una aplicación web, se suelen auditar los OWASP top 10. Si es un ataque externo, se probaran escaneos, ataques de fuerza bruta y diccionario, fallos de configuración de hardware y software, errores conocidos, etc. Si es un ataque interno se auditará la seguridad de la plataforma de trabajo, configuración correcta, contraseñas por defecto o compartidas, etc. Se debe tener en cuenta que una de las limitaciones dentro del alcance es la temporal, esto merma las capacidades de algunos tipos de técnicas como es el de fuerza bruta o el análisis de código.

¿Cómo se garantiza la confidencialidad?

En cualquier proyecto, se realizan contratos de confidencialidad, aunque en este caso, no se debe olvidar que se está redactando un “manual de intrusión” en la organización, por lo que los datos son especialmente sensibles. Todos los datos que se recopilan durante la auditoría son encriptados de forma segura tanto durante el transporte como dentro de nuestras oficinas. Sólo el personal que participa en el proyecto tiene acceso a los datos. Una vez finalizado el proyecto, entregados los documentos al cliente, y firmado el acuerdo de cierre, estos son eliminados definitivamente de nuestros sistemas.

¿Cuál es el resultado de este tipo de proyectos?

Se obtiene uno o varios informes de auditoría (dependiendo del alcance) en el que se detallan paso a paso las acciones realizadas por el equipo de auditores señalando las vulnerabilidades y la criticidad de éstas. Según se acuerde se pueden auditar o crear políticas de seguridad, definir planes directores de seguridad, dar formación en seguridad a distintos roles dentro de la organización, etc.

¿Cuáles son las reacciones ante los resultados?

Curiosamente la reacción más habitual en las auditorías de seguridad completas es la sorpresa, aunque hay que diferenciar dos perfiles que son el técnico y el de negocio. El técnico en muchos casos ya conoce algunas de las carencias técnicas, y se sorprende de la criticidad de otras. En algunos casos sale reforzado en su opinión de ser más estricto con la seguridad a nivel organizativo. El perfil orientado a negocio también queda sorprendido ya que en algunos casos no eran conscientes del potencial peligro al que estaban expuestos. Cuando los resultados son muy distantes a lo esperado, crece la focalización en la seguridad de la empresa a nivel técnico y organizativo. Es muy importante dejar claro que el objetivo del proyecto es mejorar la seguridad global y no señalar a nadie.

En definitiva, detrás de todo proyecto de hacking ético existe una metodología contrastada de gestión de proyectos que se encarga de que se ejecuten todas las pruebas de forma rigurosa y controlada, hecho que nada tiene que ver con los falsos tópicos existentes sobre la figura del hacker, donde un personaje excéntrico a altas horas de la madrugada trata de acceder a los sistemas basándose en su inspiración, y sin tener en cuenta las consecuencias de sus acciones.

Nos podría pasar a todos

noreply@blogger.com (David Ortega) — Fri, 06 May 2011 07:38:00 +0000

La seguridad de la red es un tema muy de moda últimamente con las noticias que llegan desde Sony en relación a su Play Station Network (PSN). Los datos de 77 millones de usuarios, incluidos datos bancarios y contraseñas, han sido robados por un grupo de hackers paralizando el acceso durante 9 días de la Play Station Network de Sony. A día de hoy se conocen aún pocos detalles sobre el suceso como la autoría, el alcance real del ataque y la finalidad de éste.

Esta noticia lleva a varias reflexiones:

¿Si le ha pasado a Sony, podría suceder en mi organización?

¿Dispongo de las medidas de seguridad necesarias para evitar un ataque de hacking?

En caso que sucediera ¿Cuánto tardaría en detectarlo?

¿Nuestra organización puede permitirse soportar un escándalo similar?

A pesar de que Sony es una compañía fuerte y consolidada, todavía no se conoce el impacto que producirá en la imagen de marca y en la confianza de sus clientes, ya que la información robada es crítica por su repercusión mediática y por el temor de sus clientes a ver expuestos en la red sus credenciales y sus datos bancarios. Por este motivo es muy importante en nuestras organizaciones saber qué datos son especialmente críticos, quién tiene acceso a éstos y si están debidamente protegidos.

Las Auditorías de Seguridad o Tests de Penetración se realizan para prevenir este tipo de ataques. Se simula la ejecución de un ataque informático realizado por un hacker de la forma más realista posible. Estos proyectos son una buena forma de auditar la seguridad interna o perimetral de la organización, no sólo para ayudar al Departamento TIC a justificar inversiones que la organización no percibe como prioritarias, sino también para conocer la respuesta a estas preguntas:

¿Qué nivel de madurez tiene nuestra seguridad de la información?

¿Cuáles son nuestras vulnerabilidades críticas?

¿Qué debe cambiar en nuestro sistema o nuestros procedimientos para ser mejorar la seguridad?

¿Son efectivas nuestras medidas de seguridad?

Es importante destacar que no se audita la seguridad solamente a nivel técnico sino también a nivel de procedimientos y políticas. La mayoría de las vulnerabilidades que se encuentran en este tipo de auditorías pueden ser subsanadas aplicando medidas organizativas, políticas de seguridad adaptadas a la organización y formación a los usuarios. La concienciación de los usuarios a todos los niveles es fundamental en la seguridad, de nada sirven las mejores y más caras soluciones de seguridad sin unos procedimientos y sin una cultura de seguridad organizativa. Los resultados de un test de penetración son una buena herramienta para lograr dicha concienciación.

La seguridad de la información es una cadena que siempre se rompe por el eslabón más débil. Por este motivo, es imprescindible conocer las vulnerabilidades existentes para saber qué medidas pueden mejorar la seguridad proactiva, la seguridad activa y la seguridad reactiva. Llegando a la conclusión de que no deberíamos esperar sufrir un incidente para invertir en seguridad.

El ROI (Retorno de la Inversión) en seguridad es mucho mayor en la prevención que en la reparación, sobretodo porque existen casos en que el daño puede ser irreparable.

Plan de Contingencia. ¿Cómo?. ¿Cuándo?

noreply@blogger.com (David Ortega) — Tue, 22 Mar 2011 09:54:00 +0000

Algunos de vosotros nos habéis preguntado respecto de los criterios de activación del Plan de Contingencia. Para ello recurriremos a la guía 800-34 del NIST: Contingency Planning Guide for Information Technology Systems.

Para fijar conceptos, empecemos estableciendo en qué consiste realmente el plan. Estamos hablando, básicamente, de restaurar la interrupción de los servicios de TI:

Recuperando las operaciones de TI en una ubicación alternativa.
Recuperando las operaciones de TI con equipamiento alternativo.
Realizando alguno de los procesos de negocio soportados por dichos servicios mediante medios manuales.

Una vez tenemos el plan montado y probado, éste debe ser activado sólo cuando la evaluación de daños indica que uno o más de los criterios de activación se cumplen. Estos criterios son únicos para cada organización, deben ser claros y pueden basarse en:

La seguridad del personal y/o la magnitud de los daños sobre las instalaciones.
La extensión de la avería según criterios físicos, operacionales o financieros.
La criticidad del sistema afectado.
La previsión de la duración de la interrupción en base a los RTOs establecidos en el BIA. Este punto está relacionado con el anterior.

Por ejemplo, podemos establecer que nuestro plan se activará:

Cuando el tiempo de recuperación previsto de cualquiera de los servicios excede el tiempo máximo establecido.
Cuando transcurrido el 50% del tiempo máximo para la recuperación de un servicio, no haya sido posible identificar su causa.

Plan de Contingencia y catálogo de servicios de TI

noreply@blogger.com (David Ortega) — Wed, 09 Mar 2011 16:46:00 +0000

Últimamente se han escrito en este blog diferentes puntos clave a tener en cuenta durante la realización de un Plan de Contingencia. El Plan de Contingencia tal como sabemos, trata de planificar la restauración de los servicios de TI ante una situación de desastre.

Como explicamos en su día, la primera fase del plan, el Análisis de Impacto (BIA), consiste en:

Identificar los procesos más críticos del negocio y los servicios de TI que los soportan.

Determinar el impacto si uno o varios de estos servicios de TI se ven afectados total o parcialmente.

Definir los requerimientos de recuperación establecidos por el negocio - tiempo máximo de interrupción o RTO y máxima pérdida de datos permitida o RPO.

En el momento de realizar el BIA, los requerimientos de recuperación del negocio se recogen a través de entrevistas con los responsables de las diferentes áreas o departamentos de la organización: RR.HH, compras, marketing, logística, producción, etc. El objetivo de dichas entrevistas es averiguar qué servicios de TI usa cada área o departamento.

Sin embargo, en este punto debemos preguntarnos si sabemos cuáles son los servicios de TI que ofrecemos. No se puede empezar la casa por el tejado, por lo que tanto el negocio como el Departamento de TI deben conocer cuáles son los servicios de TI que se ofrecen y soportan desde TI y en qué consisten.

El problema radica en que si no tenemos esta información:

Es complejo traducir lo que percibe el negocio con respecto a lo que ofrece TI.

Es fácil que el entrevistado no hable de todos los servicios de TI que utiliza. Disponer de un listado de servicios de TI ayuda a no dejarse nada en el tintero durante la realización de las entrevistas.

Por tanto, se hace necesario disponer de este catálogo de servicios de TI lo más fiel a la realidad posible.

Nuestra recomendación es incluir dentro del proyecto de Plan de Contingencia una revisión de los servicios de TI para poder conocer qué elementos los soportan (infraestructura, aplicaciones, etc.) y tener la habilidad de identificarlos durante las entrevistas. El uso de este catálogo reducirá el riesgo de repetir entrevistas y agilizará el proyecto con la seguridad de ser exhaustivos durante el proceso.

Como ya sabréis o habréis podido deducir de lo explicado hasta ahora, el catálogo de servicios es la herramienta que permite a los departamentos de TI categorizar de una manera ordenada cuales son los servicios de TI que se están provisionando y soportando. El catálogo de servicios de TI permite al departamento de TI describir:

Qué está proporcionando TI al negocio: cómo está ayudando a soportar los procesos de negocio de la organización.

Cómo lo está proporcionando: infraestructura, aplicaciones, personas, procesos de TI, niveles de disponibilidad y seguridad, garantías de continuidad, costes, etc.

Con esta entrada completamos el trimestre dedicado a los Planes de Contingencia. Si alguno de vosotros tiene alguna pregunta, necesita más información del tema o quiere aclarar algún concepto, por favor no dudéis en escribir vuestros comentarios o poneros en contacto con nosotros.

El próximo trimestre, hablaremos de las auditorías técnicas de seguridad o hacking éticos.

Plan de Contingencia. Aspectos a tener en cuenta

noreply@blogger.com (David Ortega) — Tue, 08 Feb 2011 15:15:00 +0000

Informe de situación del CPD

Dentro del análisis de riesgos es imprescindible evaluar el conjunto de sistemas que forman parte del CPD y conocer exactamente las condiciones en que se encuentran. Para ello es conveniente realizar un estudio detallado de las condiciones que cumplen, con el objetivo de definir un conjunto de medidas correctoras, dirigidas a mejorar la seguridad física de la sala y optimizar la disponibilidad de los servicios de TI.

Como valor añadido, este análisis nos permitirá establecer recomendaciones con el objetivo de perseguir la máxima eficiencia energética de cada uno de los sistemas y así reducir el consumo energético del conjunto del CPD y, en consecuencia, los costes asociados.

De esta forma y una vez implementadas las recomendaciones resultantes, la organización habrá minimizado los riesgos que pueden afectar al CPD, aportando estabilidad y seguridad a todos los procesos de negocio.

El análisis ha de contemplar los siguientes aspectos:

Sistema de cerramiento de la sala.
Sistema eléctrico.
Sistema de alimentación interrumpida.
Sistema de climatización.
Sistema de protección contra incendios.
Sistema de monitorización de alarmas.
El estado general de la sala, en cuanto a distribución, orden, limpieza, y nivel de respeto intrínseco de las condiciones de seguridad, control de accesos así como otros criterios técnicos específicos vitales en este tipo de entornos.

Manuales técnicos y “checklists funcionales”

Para que la recuperación de los servicios en el entorno de contingencia y su posterior restitución a la situación original sea un éxito, es imprescindible:

Definir cómo “levantaremos” la infraestructura que soporta los servicios de TI – equipos, bases de datos, comunicaciones, etc.- en los diferentes entornos.

Definir cómo comprobaremos que los procesos de negocio asociados a dichos servicios funcionan correctamente. Hemos de comprobar si podemos seguir haciendo pedidos, facturando, vendiendo, etc…

Para realizar el primer punto debemos definir todos aquellos manuales técnicos asociados. Manuales cuya ejecución se comprobará durante las pruebas y cuya responsabilidad de realización recae sobre el personal de TI.

Para realizar el segundo punto debemos definir todos aquellos “checklists funcionales” asociados a los procesos de negocio soportados por los servicios de TI. La responsabilidad de su realización recae sobre las diferentes unidades de negocio.

Proceso de gestión de la continuidad y disponibilidad de los servicios de TI

Una vez realizado el plan de contingencia, si queremos que sea algo vivo y útil, es fundamental establecer las bases para una gestión eficaz y eficiente, que proporcione continuidad en el tiempo al resto de trabajos realizados durante la creación del plan. Para ello, será necesario definir el proceso de gestión de la continuidad y disponibilidad de los servicios de TI.

La definición de este proceso implica, a su vez, la definición de los siguientes elementos:

Objetivos de cada proceso.
Actividades de cada proceso y roles y responsabilidades asociados a cada una de ellas de manera que quede claro quién hace qué dentro del proceso.
Relaciones con el resto de procesos, principalmente gestión de incidencias, problemas, configuración y cambios.
Las entradas del proceso definirán qué es lo que este proceso requiere de los demás.
Las salidas del proceso definirán qué información se debe entregar al resto de procesos.
Métricas e indicadores que describan cómo se debe medir el proceso.

Este proceso nos permitirá:

Determinar claramente las responsabilidades dentro del ciclo de diseño, transición y operación de los servicios de TI.
Que los servicios de TI se diseñen para alcanzar los requerimientos de disponibilidad y continuidad del negocio.
Que se establezcan las bases para la mejora continua de los servicios de TI.
Que se facilite la justificación del coste de las inversiones asociado a la disponibilidad y continuidad de los servicios.
Adoptar una mentalidad proactiva.

Retos de la gestión de la LOPD en grandes organizaciones

noreply@blogger.com (David Ortega) — Tue, 08 Feb 2011 08:55:00 +0000

Las grandes organizaciones, con grandes grupos de empleados, un número importante de departamentos o varias delegaciones y/o sucursales, necesitan poder gestionar y mantener toda la información y documentación asociada al cumplimiento de la LOPD de forma centralizada y actualizada.

Además, este tipo de organizaciones tiene la necesidad de enmarcar las medidas exigidas por la LOPD y su Real Decreto dentro del cumplimiento general de las obligaciones legales, reglamentarias o contractuales y de los requisitos de seguridad de la organización que pueden venir determinados por estándares internacionales como ISO27000 o SOX.

Abast Grup y ECIJA le invitan a un seminario en el que examinaremos la forma de abordar el cumplimiento de lo exigido por la LOPD y le mostraremos herramientas que le permitirán gestionar y cumplir con lo establecido por la ley y su Real Decreto de una manera eficaz.

El evento se realizará el día 1 de marzo en las oficinas de Abast en Barcelona (C/Equador, 39-45). El evento se iniciará a las 9:30 y finalizará, como muy tarde, a las 12:30. A continuación os detallamos la agenda del mismo:

Café de bienvenida y entrega de la documentación
Retos de gestión de la LOPD en grandes organizaciones.
- David Ortega - Director de Consultoría y Auditoría de TI de Abast
Demostración práctica de la herramienta Ecija DPServer.
- Álvaro Écija Bernal - Socio Director de ECIJA
Caso de éxito. Pendiente de confirmar
Ruegos y preguntas
Aperitivo

Si estáis interesados podéis inscribiros en www.abast.es/seminarios o llamando al 902 486 901.

¿Cómo hacer un Plan de Contingencia?

noreply@blogger.com (David Ortega) — Thu, 13 Jan 2011 08:46:00 +0000

A medida que las organizaciones dependen más y más de la tecnología, que se ha convertido en un componente clave de la mayor parte de los procesos de negocio, la disponibilidad de los servicios de TI es imprescindible para su supervivencia. Esta disponibilidad se consigue mediante la definición e implementación de un Plan de Contingencia cuyo objetivo consiste en garantizar que se puede recuperar la infraestructura de TI que soporta dichos servicios dentro de los plazos y con el nivel de servicio acordado y necesario para el negocio.

Beneficios

Reducción de aquellos riesgos que, en caso de materializarse las amenazas que les originan, pueden representar pérdidas ingentes de capital, bien por facturación fallida, por reposición de los daños causados, por pérdida de oportunidad de negocio, por reclamación de clientes, por sanciones legales, etc.
Ahorro de tiempo y dinero al afrontar y corregir situaciones nefastas antes de que ocurran y nos obliguen a resolverlas con prisas y a cualquier precio.
Mejora de la imagen y revalorización de la confianza en la empresa de los accionistas, inversores, empleados, proveedores y clientes al mostrarles que se toman medidas diarias para garantizar la continuidad del negocio.

Retorno de la Inversión

La metodología para desarrollar el plan tiene como objetivo principal ayudar a la organización a garantizar que se implementan las medidas y estrategias de recuperación que el negocio realmente necesita y puede permitirse.

Es fundamental, por tanto, entender que significa para el negocio la no disponibilidad de sus sistemas y realizar las acciones y planes necesarios para evitar que ocurra. La clave para lograr esta comprensión es la calificación (la validación con el negocio) de lo que significa realmente el tiempo de inactividad y, a continuación, la cuantificación (medición) de las consecuencias para el negocio. Se trata, por tanto, de estimar el coste de mejorar la infraestructura de TI actual frente a las pérdidas por no disponibilidad.

Metodología

Básicamente, un proyecto de Plan de Contingencia consiste en:

Análisis de impacto en el negocio. Consiste en identificar los procesos más críticos del negocio, los servicios de TI que los soportan, determinar el impacto si uno o varios de estos servicios de TI se ven afectados total o parcialmente y definir los requerimientos de recuperación establecidos por el negocio – tiempo máximo de interrupción y máxima pérdida de datos permitida -.
Análisis de riesgos. Consiste en estimar el riesgo potencial al que están sometidos los sistemas de TI, evaluando el impacto asociado a la materialización de una amenaza, y definir aquellas recomendaciones o controles preventivos que permitan reducir o eliminar dicho riesgo.
Definición de las estrategias de recuperación. Consiste en establecer los escenarios de recuperación en función de las amenazas determinadas en el análisis de riesgos y los requerimientos de negocio definidos en el análisis de impacto. En esta fase se define el escenario tecnológico óptimo para soportar los procesos de negocio, atendiendo a las disponibilidades del servicio.
Desarrollo e implementación del Plan de Contingencia. Una vez definida la estrategia de recuperación, el plan debe definir y establecer aquellos procedimientos, manuales técnicos y checklists funcionales que permitan restaurar los servicios de TI (sistemas, operaciones y datos) después de una emergencia o afectación total o parcial de estos servicios. La implementación del plan consiste en la ejecución de las recomendaciones establecidas en el análisis de riesgos y el escenario tecnológico definido.
Prueba y mantenimiento del plan. Las pruebas del plan son esenciales para identificar las deficiencias de planificación y preparación del personal. Además, el plan debe ser un documento vivo que se actualiza periódicamente para mantenerse al día con los cambios en los sistemas de TI.

Aspectos importantes a tener en cuenta:

Es aconsejable, en algunos casos imprescindible, utilizar una herramienta para realizar el análisis de riesgos. En el mercado existen diversas herramientas y cada una de ellas tiene sus ventajas e incovenientes: PILAR, Meycor, Proteus, Ecija (PCN, SGSI), etc.
Es necesario definir los procesos de continuidad y disponibilidad de TI que permitan mantener actualizado el plan frente a los cambios continuos de la infraestructura y servicios de TI, considerando de forma especial su integración con el proceso de gestión de cambios.
Un punto delicado es la definición de los criterios de activación del plan. El plan debería activarse cuando la evaluación de los daños indique que se han cumplido uno o más de estos criterios.
Las estrategias de recuperación nos definen el escenario tecnológico que cumple con los criterios de continuidad del negocio. El desarrollo del plan de contingencia asociado puede verse aplazado hasta la implementación de dicho escenario. Esto puede conllevar una inversión económica considerable que deberá pasar, entre otras cosas, por un proceso de aprobación que se puede dilatar en el tiempo. Entre tanto, es aconsejable definir un plan provisional basado en "best effort" - intentar solucionarlo lo antes posible - que prevea qué hacer en caso de activación del plan.