lunes, 21 de mayo de 2012

La importancia de la perspectiva múltiple en la Gestión de Riesgos

El riesgo viene derivado de la existencia de amenazas que en ocasiones y por diferentes circunstancias aprovechan las vulnerabilidades de los procesos / activos para producir una degradación de las actividades de negocio. 
La principal herramienta que utilizan las organizaciones para gestionar los riesgos y mitigarlos hasta niveles aceptables es el Control Interno, que es un proceso diseñado con el fin de proporcionar un grado de seguridad "razonable" para la consecución de los objetivos corporativos, garantizando la eficiencia y eficacia de la operatividad, la fiabilidad de la información corporativa y el cumplimiento normativo. 
El conjunto de controles que conforman el “Control Interno” y su nivel de madurez hacen evolucionar al riesgo intrínseco (riesgo existente por la propia naturaleza de los procesos) hacia un riesgo residual resultante tras valorar la eficacia de los mismos. Pero para que la gestión de riesgos sea óptima, completa y con perspectiva es totalmente clave “atacar” el riesgo desde dos caminos complementarios cuyo enfoque es distinto:


El Plan de Tratamiento de Riesgos y las Estrategias de Recuperación


En primer lugar “El Plan de Tratamiento de Riesgos” (o también conocido como Programa de Gestión de Riesgos), el cual está enfocado por y para el riesgo e incluye el conjunto de medidas a implantar para  mitigar /transferir/ asumir el riesgo hasta niveles aceptables por la organización, actuando sobre el impacto o sobre la probabilidad de ocurrencia. Incluye medidas normalmente a corto y medio plazo y combina controles preventivos, detectivos y correctivos.  

 

Sin embargo el Plan de Tratamiento solo es capaz de gestionar los riesgos desde la perspectiva del grado de exposición y necesita de otra naturaleza de controles denominados “Estrategias de Recuperación”, cuya perspectiva es la continuidad, su ejecución  es siempre reactiva (una vez se ha materializado el desastre) y la cuales tienen por objetivo dotar de una respuesta a la organización ante un desastre que acontece, a fin de recuperar la operativa normal cumpliendo los requerimientos de negocio (tiempos de recuperación, productividad, cumplimientos regulatorio…). Las Estrategias de Recuperación suelen ser muy costosas, se implantan en plazos largos y se deben aplicar a riesgos cuyo impacto es catastrófico y que justifica claramente la alta inversión que supone.
De esta manera la clave para conseguir una óptima Gestión de Riesgos será la habilidad del Responsable de Seguridad para diseñar un plan equilibrado de controles con perspectiva global que escale a la Alta Dirección y consiga el respaldo total por parte de la misma.

miércoles, 16 de mayo de 2012

Midiendo la seguridad de TI: 3 errores de enfoque muy comunes


Recientemente, he leído el libro IT Security Metrics. A Practical Framework for Measuring Security & Protecting Data de L. Hyden. Copyright © 2010 by The McGraw-Hill Companies.

Sin entrar en detalles, el libro se estructura en 4 partes que ofrecen un marco para el  tratamiento de la seguridad de TI. Desde una introducción al tema principal hasta la puesta en marcha del programa de mejora de la seguridad (SIP – Security Improvement Program), pasando por la fase de definición e implementación de las métricas (GQM – Goal Question Metric Method y SMP – Sample Measurement Projects), y la gestión del proceso (SPM – Security Process Management).

Como suele suceder en este tipo de literatura, la propuesta es en general muy interesante, y muchos de sus planteamientos pueden extrapolarse también a otros procesos de gestión, no sólo al de seguridad de TI.  Precisamente de estos planteamientos, quisiera destacar aquí especialmente 3 de ellos, puesto que constituyen errores de enfoque comunes:

1.  No se puede medir lo que no se puede entender

Si no entendemos qué aspectos son los que realmente nos interesan de la seguridad, será muy difícil que sepamos qué métricas nos proporcionan información y conocimiento, o bien nos ayudan a tomar decisiones en esta materia, y cuáles no. No nos debiera interesar tan sólo el valor en relación a una supuesta escala, sino todo lo que representa.
“We often hear the mantra, you cannot manage what you do not measure, and I agree with this. But if you lack definition or consensus regarding the phenomena that you hope to manage (system performance versus human behavior, for example), then jumping straight into metrics is a recipe for frustration and failure. Your understanding of what you are measuring must be specific and agreed upon if your data is to be specific and accepted by everyone. Thus, a corollary to the mantra can be stated like so: You cannot measure what you do not understand”. (Pág. XXIV Introduction) 
2.  Las métricas son sólo un resultado, la medición es la principal actividad

A menudo centramos toda nuestra atención en recopilar los datos (métricas), pero descuidamos la actividad principal que es la medición. Esta actividad es la que nos capacita para obtener la información, analizarla y entenderla, y proporcionarnos el conocimiento y el verdadero control del proceso de seguridad de TI.
“One of the common mistakes people make when setting up a security metrics program is to focus too much on the metrics themselves”  (...)   
“Metrics are conceptual data repositories –they define and standardize information. Metrics do not organize that information into knowledge”.  (...)  
“The true benefits of metrics come when the data they represent is the end result of meaningful activities, actions that we take to accomplish a goal or a task.” (Pág. 6)
3.  El valor de las métricas cualitativas frente a las cuantitativas

En la búsqueda de un mayor control del proceso de seguridad de TI (y de otros procesos de gestión), a menudo se tiende a otorgar mayor peso a resultados de tipo cuantitativo, entendiendo que éstos nos proporcionan una aproximación más real al estado de seguridad que queremos medir, frente a los resultados cualitativos que nos parecen mucho menos empíricos y más sujetos a interpretaciones. Pero este enfoque racionalista cuantitativo no contempla dos aspectos esenciales:
  • Los datos son elementos que no dejan de ser interpretados por personas.
  • La seguridad es un aspecto tanto o más ligado a las personas. Los fenómenos culturales y sociales de la organización tienen una incidencia directa en el esfuerzo por proteger la información en todo su conjunto.

 “I believe not only that nonquantitative approaches to measurement are possible in our world, but they are necessary and vital, because security is inherently a social process as much as a technical on”. (Pág. 26)
“Numbers possess an unmistakable power to persuade, which is probably why we try to turn so many things into numbers. But it is important to remember that numbers must be interpreted just like any other data. They do not speak for themselves but instead must be reconciled with the standards of measurement to which they are associated”. (...)
“Empirical qualitative measurement is exactly like its quantitative cousin in that it is based on observation and experience. Where the two differ substantially is regarding what is actually being observed”. (Pág. 32)
En conclusión, si no somos capaces de tener una visión clara por adelantado respecto a lo que queremos medir, si no obtenemos conocimiento del análisis de las métricas obtenidas y, no tenemos en cuenta la parte  humana y social implícita en la gestión de la seguridad y prevención del riesgo, probablemente, todo el esfuerzo invertido en el proceso será incompleto si no consigue el objetivo esperado de gestionar adecuadamente el riesgo potencial al que la organización y sus activos de información puedan estar expuestos.
 “In most of the companies I visit during consulting engagements, security is managed on a project basis, whether the purpose of those projects are assessment, development, or implementation. We all understand security meets only some of their needs. Even organizations with strong capabilities around security and numerous projects in place for protecting systems and information find themselves in positions where risks and security incidents occur almost in spite of the organization’s effort to understand and improve its posture. This only reinforces the fact that it is impossible to eliminate risk. Instead, we must learn to manage risk and to do that we need to measure it, and we must decide how much we are willing to accept and how much we can afford to mitigate”. (Pág. 308)

viernes, 11 de mayo de 2012

La planificación es esencial, la ejecución es decisiva


Cualquier proyecto que se desarrolle en cualquier ámbito, no sólo en el de TI, tiene dos momentos cruciales en su ciclo de vida: la fase de planificación y la fase de implantación. Ambos aspectos son las dos caras de la misma moneda. Podríamos decir que constituyen la “teoría” y la “práctica”; por eso, no va a ser posible asegurar su éxito completo si una de ellas falla.


A la hora de tratar un proyecto, y siendo generalistas, podemos afirmar que existen dos posicionamientos o actitudes diferenciadas:

  • Prestar especialmente atención a la fase de definición y planificación del proyecto, y confiar en que la fase de implantación sea la consecuencia natural derivada de tal “impulso”, o bien,
  • el correcto, considerando ambos aspectos con igual dedicación y cuidado.

El primer posicionamiento, sin duda, pone en riesgo el proceso de implantación y, en definitiva, el éxito del proyecto. El segundo de ellos, proporciona mayores garantías, aunque no por ello, está exento de problemas.
¿Cuáles son, entonces, los factores que pueden comprometer el éxito de la implantación? Pues como sucede siempre, no es atribuible a un factor único. No es un fenómeno unicausal, sino que responde a múltiples causas de diferente naturaleza:

  • El propio diseño del proyecto
  • El factor humano

Veamos, a continuación, algunos de los aspectos más significativos que son representativos de ambas:

  • Incorrecta definición del proyecto en general

La definición del proyecto debe asegurar que se dé respuesta a cuestiones tales como: por qué se lleva a cabo, quién va a participar, qué va a hacer cada rol participante, cómo lo va a llevar a cabo, cuándo lo va a llevar a cabo y qué coste real se prevé que tenga. Si alguno de estos aspectos no se define correctamente, es probable que durante la fase de implantación del proyecto sea necesario realizar reajustes para mantener la rentabilidad.
Consecuencias: en la mayoría de los casos, estos reajustes se traducirán en recortes temporales que afectarán a la duración total del proyecto o bien, presupuestarios, que afectarán a la capacidad y calidad de su ejecución.

  • Inadecuada planificación de los recursos necesarios

Los recursos humanos del proyecto constituyen el principal componente a valorar, no sólo por su coste implícito, sino también porque son los ejecutores directos de las tareas previstas, y en consecuencia sintetizan la capacidad de trabajo asignada al proyecto.
Consecuencias: una planificación deficiente comportará la sobrecarga de los recursos existentes y su desmotivación, incrementando el malestar y el riesgo de errores en la ejecución de las tareas asignadas.

  • Ineficacia en la asignación de los roles de mando

Los roles de responsabilidad durante la fase de implantación y seguimiento del proyecto deben asignarse a aquellos recursos que tengan las competencias y aptitudes adecuadas para coordinar y dirigir las actividades de puesta en marcha, y que, así mismo, tengan la capacidad de gestionar posibles imprevistos que puedan poner en riesgo el éxito del proyecto.
Consecuencias: la ineficacia en la asignación de responsabilidades en la fase de implantación y seguimiento del proyecto conllevará problemas de liderazgo, y comprometerá el proyecto en su totalidad.

  • Pocas habilidades de motivación y dinamización de los recursos: inexistencia de una fase de comunicación efectiva

Para que las actividades de implantación se desarrollen de forma eficiente, debe existir una buena comprensión del proyecto por parte de los recursos asignados y colectivos afectados. Esta comprensión no sólo atañe a especificaciones y/o exigencias operativas, sino que atañe también a la comprensión de la necesidad y los beneficios que justifican el proyecto y el esfuerzo requerido.
Consecuencias: la falta de información y las expectativas frustradas, bloquea el proceso de comunicación eficaz. Si no se percibe el beneficio del proyecto difícilmente habrá implicación de los recursos y colaboración para secundar los cambios que el proceso de implantación conlleve.

  • Resistencia “cultural” al cambio

El ser humano es emoción, y su emoción un estado de ánimo que condiciona su comportamiento y, en definitiva su capacidad para percibir, comprender y  aceptar el cambio. Somos presa de la costumbre, de los hábitos y de los anclajes en formas de trabajo recurrentes que nos proporcionan seguridad y confianza.
Consecuencias: como ya se conoce, el proceso de cambio “cultural” pasa invariablemente por diversas fases: sorpresa, resistencia, aceptación (racional y emocional), apertura e integración. No tener en cuenta este proceso “humano” o no tener las habilidades necesarias para gestionarlo, mermará notablemente sus posibilidades de éxito, agregando un gran desgaste durante la implantación y posterior seguimiento.

lunes, 7 de mayo de 2012

5 fallos comunes en proyectos de corta duración



Las metodologías de gestión de proyectos presentan las áreas de conocimiento, como los diferentes ámbitos de actuación a la hora de gestionar un proyecto. En especial, se refieren a la triple restricción como las 3 áreas más importantes que estos deben cumplir (coste, alcance y tiempo).

Parece lógico pensar que cuanto más corto es un proyecto, más influirán los pequeños detalles en la consecución general, por ejemplo, no es lo mismo perder un día de trabajo por cualquier tipo de fallo en un proyecto de 1 año que en un proyecto de 1 semana. En este artículo nos centraremos en los fallos asociados a proyectos de corta duración que afectan a la triple restricción.

1.   No se determinaron adecuadamente las necesidades del cliente (Alcance): imaginen un proyecto de un mes en el que en una reunión inicial se pacta el proyecto a realizar, el equipo emplea el tiempo estipulado en hacer el encargo y al cabo de un mes vuelve con el proyecto terminado. Si el resultado esperado por el cliente dista demasiado del trabajo realizado no tenemos un problema de retraso del proyecto, sino un proyecto entero que no es válido. Es por esto que se debe delimitar exactamente el trabajo que se realizará y cerciorarse de que cumplirá con las expectativas del cliente
2.  El equipo trató de hacer demasiado (Alcance): si bien se trata de un fallo aplicable a los diferentes tipos de proyectos, en los de duración corta se puede acentuar de forma crítica. Intentar realizar un proyecto más extenso del que se ha planificado hará que la rentabilidad del mismo sea inferior o incluso negativa. Es por ello que el equipo debe realizar el proyecto de la mejor forma posible, pero sin excederse en las tareas previstas o sin añadir funcionalidades extra no pactadas.
3. Se ha utilizado la metodología de gestión equivocada (Tiempo): Aplicar una excesiva burocracia, documentar en exceso o realizar actividades de gestión muy costosas harán que la gestión del proyecto sea más laboriosa que la propia ejecución.
4.   El proyecto se ha retrasado debido a fallos imprevistos (Tiempo): en proyectos de corta duración se debe actuar rápido ante los imprevistos que surjan. Aprender de errores anteriores, ser proactivos ante las amenazas y dotar de flexibilidad al equipo de trabajo, son características que nos ayudarán a evitar este tipo de fallos.
5.   Muchas causas, una consecuencia (Coste): existen muchas causas por las que un proyecto puede desarrollarse de manera poco eficiente, pero la consecuencia general ya sea directa o indirectamente siempre suele ser la misma, un aumento del coste previsto del proyecto. 

Es cierto que metodologías de gestión predictiva de proyectos como PMBoK o PRINCE sirven perfectamente para gestionar proyectos tanto de pequeño como gran tamaño. No obstante, en proyectos de duración corta se debe tener muy en cuenta que partes de la metodología aplicar y que actividades de gestión realizar, ya que aplicar todo el abanico de acciones abocará nuestro proyecto al fracaso.

Por otra parte, existen las denominadas metodologías de gestión de proyectos ágiles como Scrum. Las principales características de este tipo de frameworks son la reducción de documentación innecesaria, utilización de equipos multidisciplinares y auto-gestionados, enfoque en las necesidades del cliente y su participación en el proyecto, flexibilidad y rápida respuesta ante cambios o problemas. Debido a su enfoque, este tipo de metodologías están siendo muy utilizadas en proyectos de desarrollo de software pero, ¿no se  podrían utilizar en cualquier tipo de proyecto de corta duración?

Tres herramientas para la asignación de responsabilidades

La falta de una asignación formal de tareas está detrás de muchos de los problemas de eficiencia en las organizaciones. Por ello presentamos tres herramientas que permiten gestionar dicha asignación de una forma sencilla.

Si no está claro quién debe realizar una determinada tarea, tarde o temprano aparecen situaciones de duda o de conflicto que acaban teniendo un impacto en la organización. Ante esta situación, cuando surge un problema es frecuente oír frases como: “Es que esto no es cosa mía...”, “A mí nadie me dijo que lo hiciera…” o “Yo pensaba que se encargaba él…”.

La tendencia natural a esquivar los problemas o a dedicarnos a aquello que más nos gusta produce estas situaciones tan perjudiciales para el correcto desarrollo de la operativa diaria.

También es muy importante aclarar que nada tiene que ver la flexibilidad con la falta de asignación de funciones y obligaciones. Una organización o departamento puede ser extremadamente flexible y que todo el mundo en cada momento tenga claro cuáles son sus responsabilidades, simplemente se trata de gestionar adecuadamente estas asignaciones.

Cuando una organización desea solucionar estos problemas puede recurrir a una serie de herramientas, que de forma complementaria, ayudan a la gestión de las funciones y obligaciones del personal:

1. Descripción del puesto de trabajo (Job description):  Muy habitual en el ámbito de recursos humanos, se trata de una lista de tareas generales, funciones y responsabilidades de un determinado cargo. A menudo también incluye a quién debe reportar, y las cualificaciones y habilidades necesarias para el correcto desarrollo de sus funciones. Con esta herramienta se consigue una doble función, por un lado que todo trabajador tenga una visión en alto nivel de qué es lo que se espera de él y de cuáles son sus competencias, y por otro que la organización tenga claro qué es lo que se le puede exigir un determinado perfil. 
2. Matriz de asignación de responsabilidades: Todo proceso / procedimiento organizativo debería estar documentado, y como parte de dicha documentación deberían incluirse aspectos relacionados con la asignación de responsabilidades. Para ello, se suelen utilizar las denominadas matrices de asignación de responsabilidades, entre las que destaca la denominada “RACI”.
El mecanismo es sencillo, en las columnas se representan los diversos implicados, y en las filas las tareas a realizar. Así, para cada actividad se establece qué implicado ostenta los siguientes roles:
  • R (Responsible): Encargado/s de la ejecución de la actividad.
  • A (Accountable): Responsable final de que la actividad se ejecute adecuadamente (sólo debe haber un "accountable" por actividad).
  • C (Consulted): Rol de soporte para la ejecución de la actividad, dispone de información o capacidad necesaria para la ejecución de la actividad.
  • I (Informed): Interesado en la ejecución de la actividad que debe ser informado del avance de la misma.

De esta forma se consigue asignar las responsabilidades de cada uno de los implicados. La matriz RACI resulta especialmente útil cuando para la ejecución de un determinado proceso, intervienen diversos grupos de trabajo o áreas organizativas.


3. Tableros visuales: Esta herramienta es especialmente útil cuando exiten grupos de trabajo en entornos muy dinámicos. Por ejemplo, suelen ser muy utilizados en el desarrollo de software. Basados en conceptos de teoría de colas, a simple vista una persona puede comprobar qué actividades tiene asignadas, y el estado de las mismas.

Existe una gran variedad de ejemplos de tableros visuales, un posible modelo podría ser el siguiente: En primer lugar se crea un tablero en forma de matriz con la siguiente información: en forma de columna los tres estados de una actividad (pendiente, en progreso y finalizado), y en las filas se representan las personas implicadas. Se descomponen las actividades de forma que sean sencillas de gestionar, y cada una de ellas se representa en una tarjeta que se irá moviendo por el tablero en función de la persona responsable y del estado de la misma.

Utilizando este tablero como sistema de gestión de actividades es fácil balancear dinámicamente las cargas de trabajo.

                                                                                                                                                                                                             
Existen otras muchas más herramientas para la asignación de responsabilidades, pero tanto por su sencillez y como por el valor que aportan, estas son las más utilizadas.