IV. Curso de Gestión de Riesgos de TI. Enfoques del Riesgo

Maestría en Ingeniería de Sistemas con mención en Gerencia de TI y Gestión de Software Universidad Nacional Pedro Ruiz Gallo

 Curso de Gestión de Riesgos de Tecnologías de la Información – Cuarta Parte Dra. Maribel Capuñay Guzmán

Otros Enfoques de la Gestión de Riesgos

I. PARTE: EXPOSICIONES



1. CMMI Risk Management 2. COBIT para la Gestión de Riesgos en proyectos TI 3. Marco COSO de Control Interno 4. Metodologías de desarrollo ágil de productos: Visión del riesgo en Agile,

Scrum y Kanban 5. Comparativa de PMBOK frente a otros marcos de la gestión de riesgos 6. Gestión de Riesgos con PRINCE2 7. Técnicas Cualitativas y Cuantitativas para

Análisis de Riesgos

II. Parte ¿Por qué debemos gestionar los riesgos?

 SI NO LO HACEMOS, la empresa pierde:



Algunos ejemplos de porqué dar importancia y atención a los riesgos tecnológicos: Hersheys



 150 millones USD de pérdida en ventas por fallo del sw de logística en la compañía Hersheys, USA (1999): un defecto de software, obvió el envío de caramelos para Halloween

Algunos ejemplos de porqué dar importancia y atención a los riesgos tecnológicos: FoxMeyer Drugs



 Caso FoxMeyer (1998): Pérdidas por demora en la distribución y almacenamiento por un error en el sistema de planificación de recursos (ERP) y la demanda a SAP y a Andersen Consulting. Las órdenes procesadas bajaron de 420.000/noche a 10.000 cuando se reemplazó el sistema de FoxMeyer a SAP16.

Algunos ejemplos de porqué dar importancia y atención a los riesgos tecnológicos: McAfee



 Defectos en la actualización del antivirus McAfee 2010: el sistema operativo Windows XP SP3 a nivel mundial se reiniciaba continuamente, perdiendo el acceso a la red tanto en clientes corporativos como domésticos. La causa: un falso positivo pues McAfee identifica el ejecutable svchost.exe como un virus17.

Algunos ejemplos de porqué dar importancia y atención a los riesgos tecnológicos: Linkedin



 6.5’ de contraseñas de usuarios fueron obtenidas luego de un “ataque cibernético” en 2012. El costo de recuperación del incidente osciló entre 500.000 y 1.000.000 USD.

Gestionar los riesgos es importante…

   Aunque a primera vista la gestión de riesgos parece agregar más complejidad al proyecto de desarrollo, en realidad, reduce la complejidad del proyecto en general.

 Los proyectos que hacen gestión de riesgos son más predecibles y experimentan menos situaciones sorpresivas pues la mayoría de problemas se detectaron antes de ocurrir 

El paradigma tradicional de la gestión de riesgo

Sólo cuando estas preguntas pueden ser contestadas, la gestión de riesgos puede llevarse a cabo…



Un gerente de proyecto responde a las siguientes interrogantes (análisis)  ¿Qué puede salir mal?  ¿Cuál es la probabilidad de que eso salga mal?  ¿Cuáles son las consecuencias de que eso salga mal? Como resultado del análisis, un gerente de proyecto busca responder las siguientes interrogantes (planes):  ¿Qué se puede hacer para que no ocurra eso?  ¿Qué opciones disponibles hay?  ¿Cuál es el costo o beneficio asociado a las opciones existentes?  ¿Cuál es el impacto de las decisiones que se tomen actualmente con respecto a decisiones futuras?

Gestión de riesgos en CMMI V1.3

Marco de Trabajo del Modelo de Capacidad y Madurez Integrado

Los modelos de capacidad y madurez (CMMs):  



Se enfocan en la mejora

continua de los procesos de la organización Definen el paso de procesos inmaduros a procesos disciplinados y maduros elevando la calidad y efectividad en base a un conjunto de mejores practicas de

mercado. CMMI es:

 Identifican las fortalezas y debilidades de los procesos de la organización, y transforman las debilidades en fortalezas. 

Aplicable a equipos de trabajo, proyectos, divisiones y organizaciones.

 Su marco de trabajo ofrece tres modelos para cumplir con los objetivos de negocio:   

CMMI para adquisiciones: Guía de la gestión de la cadena de suministros para adquirir/integrar productos y servicios cumpliendo con la necesidad de los clientes. CMMI para servicios: Guía para organizaciones que establecen, gestionan y entregan servicios satisfaciendo las necesidades de sus clientes y usuarios finales. CMMI para desarrollo: Guía en la mejora de procesos a organizaciones que desarrollan

productos y servicios de software.

Gestión de riesgos en CMMI V1.3 CMMI v1.3 para desarrollo



El modelo propuesto por CMMI para desarrollo utiliza conceptos de gestión e ingeniería para ayudar en la entrega de productos a tiempo y de alta calidad, especialmente para las organizaciones que dependen fuertemente del desarrollo de

software. El modelo cubre el ciclo de vida de productos/servicios desde su concepción hasta la entrega y mantenimiento. Adoptando este modelo como guía de referencia, las organizaciones pueden lograr: 1. Mejorar la satisfacción del cliente 2. Aumentar la calidad de los desarrollos 3. Realizar las entregas en el tiempo acordado 4. Minimizar los costos de desarrollo 5. Garantizar un retorno de inversión 6. Mejorar las condiciones de trabajo de los empleados

Gestión de riesgos en CMMI V1.3 Componentes para su Implementación



La guía CMMI comprende tres componentes para su implementación en pro de la mejora de cualquier proceso. Componentes Informativos. Info. que ayuda a los usuarios a entender los 2 componentes Componentes Esperados. anteriores:explicaciones Son las prácticas genéricas detalladas, notas, referencias, y específicas que permiten títulos de metas, fuentes, lograr satisfacer un elaboración de las prácticas componente requerido. genéricas Componentes Requeridos. Son las metas específicas, genéricas y visibles las cuales son utilizadas en las evaluaciones como base para decidir si se ha logrado satisfacer un área de proceso.

Gestión de riesgos en CMMI V1.3

RSKM y la Representación Continua y Representación por Etapas

Nivel 3 - Definido (NC3)  R. Continua En NC3, los procesos se describen de una manera rigurosa, y se gestionan de forma más proactiva y no reactiva como ocurre en NC2.



Nivel 3 - Definido (NM3)  R. por etapas RSKM cae en la categoría de proceso de gestión de proyectos en la representación continua. * NM3: los procesos bien caracterizados, comprendidos, y descritos en estándares, procedimientos y métodos. El cjto. de procesos estándar del NM3, se establece y mejora en el tiempo dando consistencia a toda la organización: los patrones, descripción del proceso y procedimientos estándar de la organización para proyectos se adecuan a un proyecto particular, excepto las diferencias permitidas por las guías de adaptación.

Gestión de riesgos en CMMI V1.3 Risk Management (RSKM)



 Identifica los problemas potenciales antes que ocurran para que las actividades de respuesta se planifiquen y utilicen en toda la vida del proyecto mitigando los impactos adversos.  RSKM amplía las prácticas de Planificación de Proyectos y Monitorización y Control de Proyectos al establecer principios para planificar, anticipar y mitigar de manera sistemática y proactiva los riesgos que se presenten en el proyecto u organización.  El mayor riesgo para un proyecto es suponer que no existen riesgos: hay una alta probabilidad de que ocurrencia, muchas veces, con impactos fuertes para el proyecto.  La Mitigación en CMMI incluye tanto actividades para controlar la ocurrencia del riesgo como para minimizar el impacto si se presenta (planes de contingencia)  En la versión 1.3 del modelo existen las metas y prácticas siguientes:

• • •

Establecer la estrategia para gestionar los riesgos Identificar y analizar los posibles riesgos Controlar los riesgos

Cobit para la gestión de riesgos

Generalidades



2013: ISACA publicó oficialmente la nueva guía que aplica COBIT 5 para la gestión efectiva de Riesgos de TI, que ayuda a alcanzar un mejor rendimiento para el Negocio al vincular los riesgos de TI con la concreción de los objetivos estratégicos de la empresa.

Riesgos Tecnológicos en el marco son posibles pérdidas derivadas de un evento concerniente al acceso /uso de tecnología, que afecta el desarrollo de los procesos del negocio y la gestión de riesgos de toda la organización al degradar dimensiones críticas de la información como:

confidencialidad, integridad y disponibilidad. COBIT 5 for Risk se basa en COBIT 5 para Gobierno y el Management de la TI con visión integral de Empresa y provee 20 categorías de escenarios de riesgos + respuestas potenciales y acciones de mitigación. Ej. las acciones maliciosas de empleados, brechas de seguridad, fuga de información sensible a través de redes sociales, espionaje industrial y de soporte para la innovación.

Cobit para la gestión de riesgos Facilitadores



La publicación da lineamientos de cómo COBIT 5 soporta y asiste en la gestión y gobierno del riesgo informático, la implementación y mantenimiento basada en los 7 facilitadores de COBIT 5 y está especialmente orientada a profesionales de las áreas de Riesgos, Gerentes de TI y de Negocio, Alta Gerencia y Dirección (Ref. Exp. COBIT para la gestión de Riesgos)

Gestión de Riesgos en Metodologías de desarrollo Ágil

Metodologías Ágiles



 “Actividad caótica caracterizada por la frase codificar y corregir” (Martin Fowler, 2005): 

Se escribe sin un plan muchas veces



El diseño depende de decisiones de corto plazo



A mayor tamaño del software, es más complejo añadir nuevas funcionalidades, aumenta la cantidad de errores y la dificultad para corregirlos.

 El movimiento que trató de cambiar esta forma de trabajar introdujo la noción de metodología, intentado establecer un proceso detallado con un fuerte énfasis en “planificación” inspirado por otras disciplinas de la ingeniería.  La presencia y uso de estas metodologías está vigente desde hace mucho, no obstante, la crítica más frecuente para éstas es que son “burocráticas”: demandan tantos

requisitos que disminuyen el rendimiento y la velocidad del proceso de desarrollo  Como reacción a este movimiento surgieron las metodologías ágiles.

Gestión de Riesgos en Metodologías de desarrollo Ágil

Características





Los métodos agiles son adaptativos, no predictivos. Distintos a las metodologías tradicionales que buscan crear un plan a largo plazo y en gran detalle, los métodos ágiles contemplan el cambio como algo normal, adaptándose a estos con frecuencia.



Los métodos ágiles están orientados a las personas y no a los procesos: Las metodologías ágiles se basan en que el rol del proceso es servir de soporte al equipo de desarrollo y no viceversa.

 

Los métodos agiles son menos orientados a la documentación. En los métodos agiles la participación del cliente durante el desarrollo es esencial, de forma que los cambios se incorporan rápidamente.



Las metodologías ágiles son iterativas: provee partes funcionales y operativas de un conjunto de funcionalidades del software que se encuentra en construcción. Cada una de las funcionalidades a proveer debe estar probada y ser integrada bajo las mismas condiciones como si fuese la entrega del sistema final. Trabajar con iteraciones es realmente productivo ya que el cliente se puede sentar frente al sistema y empezar a utilizarlo detectándose los defectos o mala interpretación de requerimientos y permitiendo la toma de acciones rápidamente sin esperar hasta la entrega de un producto final, donde el costo de corregir errores se incrementa considerablemente.



Manifiesto Ágil (Agile Manifesto)



Como alternativa a las metodologías de desarrollo de software tradicional, consideradas pesadas, rígidas y altamente dependientes de planificaciones detalladas previas al desarrollo, nace el “Manifiesto para el desarrollo de software Ágil”: Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar: Individuos e Interacciones sobre procesos y herramientas. Software funcionando sobre documentación extensiva. Colaboración con el cliente sobre negociación contractual. Respuesta ante el cambio sobre seguir un plan. Esto es, aunque valoramos los elementos de la derecha, valoramos más los elementos de la izquierda.

GESTION DE RIESGOS CON METODOLOGIAS DE DESARROLLO AGIL Metodologías Crystal



Seguridad Personal Cada integrante debe tener la seguridad de que no va a ser ridiculizado o no tenido en cuenta. Enfoque Enfoques en dos vertientes: tiempo y dirección del proyecto.. 1er caso: se establecen períodos de no interrupción a los desarrolladores (2 horas) y se garantiza la continuidad en el desarrollo de tareas asignando desarrolladores con antelación al cambio de proyecto de uno de ellos. 2do caso: para conseguir una adecuada dirección del proyecto es necesario que los desarrolladores tengan muy claros los objetivos y que el responsable del py. priorice a cada momento los objetivos de forma que el equipo de proyecto se centre en tareas concretas. Fácil acceso a usuarios expertos La participación/implicación de usuarios expertos en el proyecto es esencial: como mín. una vez por semana se deben mantener encuentros de mínimo un par de horas con ellos y existir accesibilidad para tener comunicaciones telefónicas si fuera necesario. Entorno técnico Generar pruebas automatizadas, gestionar la configuración y la integración continua.

GESTION DE RIESGOS CON METODOLOGIAS DE DESARROLLO AGIL SCRUM



Utilizado para desarrollar productos complejos desde principios de los '90, Scrum es un marco de trabajo en el que se pueden emplear diversos procesos y técnicas, proporcionando un marco dentro del cual se pueden desarrollar productos complejos. Los pilares que sostienen la implementación del control empírico de procesos son: Transparencia La transparencia garantiza que los aspectos del proceso que afectan al resultado sean visibles para quienes administran dicho resultado. Inspección Se deben inspeccionar con frecuencia suficiente los diversos aspectos del proceso para que puedan detectarse variaciones inaceptables en el mismo. Adaptación Si el inspector determina mediante la inspección, que uno o más aspectos del proceso están fuera de los límites aceptables, se debe ajustar el proceso o el material procesado lo más rápidamente posible para minimizar una desviación mayor.

GESTION DE RIESGOS CON METODOLOGIAS DE DESARROLLO AGIL SCRUM



Los equipos Scrum están diseñados para ser flexibles y productivos: son auto-gestionados, multifuncionales, y trabajan en iteraciones. Asimismo, Scrum emplea 3 Cada equipo Scrum tiene tres roles: artefactos principales para 1. El ScrumMaster (Facilitador). implementarse: 2. El Propietario del Producto. 1. El Product Backlog. 3. El Equipo Scrum. 2. El Sprint Backlog. 3. El Burndown de la entrega. Scrum emplea seis bloques de tiempo para crear regularidad: 1. La Reunión de Planificación de la Entrega. 2. El Sprint. 3. La Reunión de Planificación del Sprint. 4. La Revisión del Sprint. 5. La Retrospectiva del Sprint. 6. El Scrum Diario.

Finalmente, las “reglas” en Scrum han de servir de unión para los bloques de tiempo, los roles y los artefactos de Scrum.

Bibliografía 1.

BECK, K., BEEDLE, M., VAN BENNEKUM, A., COCKBURN, A., CUNNINGHAM, W., FOWLER, M. , …,



THOMAS, D. (2001). Manifiesto por el Desarrollo Ágil de Software: http://agilemanifesto.org/iso/es/ 2.

FERNÁNDEZ, A.(2003). Boletín N° 9 NORMARIA. Riesgo. Nuevo Marco COSO de Gestión de Riesgos. Disponible en https://www.iaia.org.ar/revistas/normaria/Normaria09.pdf

3.

FOWLER, M. (2005). Post del blog The New Methodology. Disponible en http://martinfowler.com/articles/newMethodology.html

4.

IT – Governance, Risk & Compliance. El blog de Franco sobre IT – GRC con visión de Negocio. (2013). Disponible en http://francoitgrc.wordpress.com/2013/09/27/gestion-de-riesgos-usando-cobit-5/

5.

MELENDEZ, F. (2013). Nueva versión del PMBOK – Edición 2013. PB&M Consulting Group. Disponible en: http://es.slideshare.net/pmiunmsm/pmbok-5ta-edicionfelipemelendez

6.

PAOLINI, A. (2013). Implementación de área de proceso de gestión de riesgos de CMMI v1.3 utilizando metodologías ágiles. Tesis para optar al grado de Magister en Tecnologías de la información. Disponible en:

http://www.tesis.uchile.cl/bitstream/handle/2250/114722/cf-paolini_an.pdf?sequence=1 7.

PÉREZ, C. (2010). Qué significa CMMI. Disponible en http://asprotech.blogspot.com/2010/11/resumen-degestion-de-riesgos-en-cmmi.html

8.

RAMÍREZ, R. (2012). COBIT 5. Artículo de la revista Magazcitum, el Magazine para los profesionales de Seguridad de TI. Disponible en: http://www.magazcitum.com.mx/?p=1893