""
Todas las actividades de análisis de riesgo presentadas hasta ahora tienen un objetivo único: ayudar al equipo del proyecto a desarrollar una estrategia para tratar los riesgos. Una estrategia eficaz debe considerar tres aspectos:
• Evitar el riesgo• Supervisar el riesgo• Gestion del riesgo y planes de contingencia
Si un equipo de software adopta un enfoque proactivo frente al riesgo, evitarlo es siempre la mejor estrategia. Esto se consigue desarrollando un plan de reducción del riesgo. Por ejemplo, asuma que se ha detectado mucha movilidad de la plantilla como un riesgo del proyecto, n. Basándose en casos anteriores y en la intuición de gestión, la probabilidad, li, de mucha movilidad se estima en un 0.70 (70 por ciento, bastante alto) y el impacto, si está previsto que tenga un impacto crítico en el coste y planificación temporal del proyecto. Para reducir el riesgo, la gestión del proyecto debe desarrollar una estrategia para reducir la movilidad. Entre los pasos que se pueden tomar están estos:
• Reunirse con la plantilla actual y determinar las causas de la movilidad (por ej.: malas condiciones de trabajo, salarios bajos, mercado laboral competitivo).• Actuar para reducir esas causas que estén al alcance del control de gestión antes de que comience el proyecto.• Una vez que comienza el proyecto, asuma que habrá movilidad y desarrolle técnicas para asegurarse la continuidad cuando se vaya la gente.• Organice los equipos del proyecto de manera que la información sobre cada actividad de desarrollo esté ampliamente dispersa.• Defina estándares de documentación y establezca mecanismos para asegurarse de que los documentos se cumplimenten puntualmente.• Convoque reuniones de revisión de todo el trabajo de manera que más de una persona a la vez esté familia rizada con el trabajo.• Defina un miembro de la plantilla como reserva para cada técnico crítico.
A medida que progresa el proyecto comienzan las actividades de supervisión del riesgo. El jefe del proyecto supervisa factores que pueden proporcionar una indicación de si el riesgo se está haciendo más o menos probable. En el caso de gran movilidad del personal, se pueden supervisar los siguientes factores:
• Actitud general de los miembros del equipo basándose en las presiones del proyecto.• El grado de compenetración del equipo.• Relaciones interpersonales entre los miembros del equipo.• La disponibilidad de empleo dentro y fuera de la compañía.
Además de supervisar los factores apuntados anteriormente, el jefe del proyecto debería supervisar también la efectividad de los pasos de reducción del riesgo. Por ejemplo. un paso de reducción del riesgo apuntado anteriormente instaba a la definición de "estándares de documentación y mecanismos para asegurarse de que los documentos se cumplimenten puntualmente". Este es un mecanismo para asegurarse la continuidad, en caso de que un individuo crítico abandone el proyecto. El jefe del proyecto debería comprobar los documentos cuidadosamente para asegurarse de que son válidos y de que cada uno contiene la información necesaria en caso de que un miembro nuevo se viera obligado a unirse al proyecto. La gestión del riesgo y los planes de contingencia asumen que los esfuerzos de reducción han fracasado y que el riesgo se ha convertido en una realidad. Continuando con el ejemplo, suponga que el proyecto va muy retrasado y un número de personas anuncia que se va. Si se ha seguido la estrategia de reducción. tendremos reservas. la información está documentada y el conocimiento del proyecto se ha dispersado por todo el equipo. Además. el jefe del proyecto puede temporalmente volver a reasignar los recursos (y reajustar la planificación temporal del proyecto) desde las funciones que tienen todo su personal, permitiendo a los recién llegados que deben unirse al equipo que vayan "cogiendo el ritmo". A los individuos que se van se les pide que dejen lo que estén haciendo y dediquen sus últimas semanas a "transferir sus conocimientos". Esto podría incluir la adquisición de conocimientos por medio de vídeos, el desarrollo de "documentos con comentarios" y/o reuniones con otros miembros del equipo que permanezcan en el proyecto. Es importante advertir que los pasos RSGR provocan aumentos del coste del proyecto. Por ejemplo, emplear tiempo en conseguir una reserva de cada técnico crítico cuesta dinero. Parte de la gestión de riesgos es evaluar cuando los beneficios obtenidos por los pasos RSGR superan los costes asociados con su implementación. En esencia, quien planifique el proyecto realiza el clásico análisis coste/beneficio. Si los procedimientos para evitar el riesgo de gran movilidad aumentan el coste y duración del proyecto aproximadamente en un 15 por ciento, pero el factor coste principal es la copia de seguridad (backup), el gestor puede decidir no implementar este paso. Por otra parte si los pasos para evitar el riesgo llevan a una proyección de un aumento de costes del 5 por ciento y de la duración en un 3 por ciento, la gestión probablemente lo haga. Para un proyecto grande se pueden identificar hasta unos 40 riesgos. Si se pueden identificar entre tres y siete pasos de gestión de riesgo para cada uno, la gestión del riesgo puede convertirse en un proyecto por sí misma. Por este motivo, adaptamos la regla de Pareto 80-20 al riesgo del software. La experiencia dice que el 80 por ciento del riesgo total de un proyecto (p. ej.: el 80 por ciento del potencial de fracaso del proyecto) se debe solamente al 20 por ciento de los riesgos identificados. El trabajo realizado durante procesos de análisis de riesgo anteriores ayudará al jefe de proyecto a determinar qué riesgos pertenecen a ese 20 por ciento. Por este motivo, algunos de los riesgos identificados, valorados y previstos pueden no pasar por el plan RSGR -no pertenecen al 20 por ciento crítico (los riesgos con la mayor prioridad del proyecto).
Riesgos y peligros para la seguridad
El riesgo no se limita al proyecto de software solamente. Pueden aparecer riesgos después de haber desarrollado con éxito el software y de haberlo entregado al cliente. Estos riesgos están típicamente asociados con las consecuencias del fallo del software una vez en el mercado. Aunque la probabilidad de fallo de un sistema de alta ingeniería es pequeña, un defecto no detectado en un sistema de control y supervisión basados en ordenador podría provocar unas pérdidas económicas enormes, o peor, daños físicos significativos o pérdida de vidas humanas. Pero el coste y beneficios funcionales del control y supervisión basados en computadora a rnenudo superan al riesgo. Hoy en día, se emplean regularmente hardware y software para el control de sistemas de seguridad crítica. Cuando se emplea software como parte del sistema de control, la complejidad puede aumentar del orden de una magnitud o más. Sutiles defectos de diseño inducidos por error humano -algo que puede descubrirse y eliminarse con controles convencionales basados en hardware- se convierten en mucho más difíciles de descubrir cuando se emplea software. La seguridad del software y el análisis del peligro son actividades para garantizar la calidad del software que se centra en la identificación y evaluación de peligros potenciales que pueden impactar al software negativamente y provocar que falle el sistema entero. Si se pueden identificar los peligros al principio del proceso de ingeniería del software, se pueden especificar características de diseño software que eliminen o controlen esos peligros potenciales.
El plan RSGR
Se puede incluir una estrategia de gestión de riesgo en el plan del proyecto de software o se podrían organizar los pasos de gestión del riesgo en un plan diferente de reducción, supervisión y gestión del riesgo (Plan RSGR). Todos los documentos del plan RSGR se llevan a cabo como parte del análisis de riesgo y son empleados por el jefe del proyecto como parte del Plan del Proyecto general. A continuación se expone un es;quema del Plan RSGR.
I. Introducción
1. Alcance y propósito del documento2. Visión general de los riesgos principales3. Responsabilidades
a. Gestiónb. Personal técnico
II. Tabla de riesgo del proyecto.
1. Descripción de todos los riesgos por encima de la línea de corte2. Factores que influyen en la probabilidad e impacto
III. Reducción, supervisión y gestión del riesgo
n. Riesgo # n
a. Reducción
i.Estrategia general.ii. Pasos específicos.
b. Supervisión
i. Factores a supervisarii. Enfoque de supervisión
c. Gestión
i. Plan de contingenciaii. Consideraciones especiales.
IV. Planificación temporal de revisión del Plan RSGRV. Resumen
Una vez que se ha desarrollado el plan RSGR y el proyecto ha comenzado, empiezan los procedimientos de reducción y supervisión del riesgo Como ya hemos dicho antes, la reducción del riesgo es una actividad para evitar problemas La supervisión del riesgo es una actividad de seguimiento del proyecto con tres objetivos principales (1) valorar cuando un riesgo previsto ocurre de hecho; (2) asegurarse de que los procedimientos para evitar el riesgo definidos para el riesgo en cuestión se están aplicando apropiadamente; y (3) recoger información que pueda emplearse en el futuro para analizar riesgos. En muchos casos, los problemas que ocurren durante un proyecto pueden afectar a más de un riesgo. Otro trabajo de la supervisión de riesgos es intentar determinar el "origen" (qué riesgos ocasionaron tal problema) a lo largo de todo el proyecto.
MAGERIT
MAGERIT es el acrónimo de "Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información de las Administraciones Públicas". Es una metodología de carácter público, perteneciente al Ministerio de Administraciones Públicas. Su utilización no requiere autorización previa del MAP.La generalización del uso de las tecnologías de la información y de las comunicaciones es potencialmente beneficiosa para los ciudadanos, las empresas y la propia Administración Pública, pero también da lugar a ciertos riesgos que deben minimizarse con medidas de seguridad que generen confianza en su utilización.No es posible una aplicación racional de medidas de seguridad sin antes analizar los riesgos para, así implantar las medidas proporcionadas a estos riesgos, al estado de la tecnología y a los costes (tanto de la ausencia de seguridad como de las salvaguardas).La Metodología de Análisis y GEstión de Riesgos de los sistemas de Información de las AdminisTraciones públicas, MAGERIT, es un método formal para investigar los riesgos que soportan los sistemas de información, y para recomendar las medidas apropiadas que deberían adoptarse para controlar estos riesgos.MAGERIT ha sido elaborada por un equipo interdisciplinar del Comité Técnico de Seguridad de los Sistemas de Información y Tratamiento Automatizado de Datos Personales, SSITAD, del Consejo Superior de Informática.
La versión 1.0 de MAGERIT se presenta en siete guías metodológicas:· Guía de Aproximación. Presenta los conceptos básicos de seguridad de los sistemas de información, con la finalidad de facilitar su comprensión por personal no especialista y ofrece una introducción al núcleo básico de MAGERIT, constituido por las Guías de Procedimientos y de Técnicas.· Guía de Procedimientos. Representa el núcleo del método, que se completa con la Guía de Técnicas. Ambas constituyen un conjunto autosuficiente, puesto que basta su contenido para comprender la terminología y para realizar el Análisis y Gestión de Riesgos de cualquier sistema de información.· Guía de Técnicas. Proporciona las claves para comprender y seleccionar las técnicas más adecuadas para los procedimientos de análisis y gestión de riesgos de seguridad de los sistemas de información.· Guía para Responsables del Dominio protegible. Explica la participación de los directivos "responsables de un dominio" en la realización del análisis y gestión de riesgos de aquellos sistemas de información relacionados con los activos cuya gestión y seguridad les están encomendados.· Guía para Desarrolladores de Aplicaciones. Está diseñada para ser utilizada por los desarrolladores de aplicaciones, y está íntimamente ligada con la Metodología de Planificación y Desarrollo de Sistemas de Información, Métrica v2.1.· Arquitectura de la información y especificaciones de la interfaz para el intercambio de datos. La interfaz para intercambio de datos posibilita que un usuario de MAGERIT establezca la comunicación con otras aplicaciones y sistemas facilitando la incorporación de sus productos a la herramienta MAGERIT y viceversa.· Referencia de Normas legales y técnicas. Lista de normas en materia de seguridad a fecha 31 de Diciembre de 1996.""
