Proyecto de Gestión de Riesgos Tecnológicos y de Seguridad de la Información

Proyecto de Gestión de Riesgos Tecnológicos y de Seguridad de la Información

Describe brevemente un proyecto concreto que conozcas y, sobre el mismo, responde a dos de las tres siguientes cuestiones:

En los últimos años, debido a la creciente digitalización del sector financiero y la creciente interconexión con otras instituciones financieras y terceros a través de canales de telecomunicaciones, la Autoridad Bancaria Europea (EBA) publicó el informe final sobre las directrices sobre TIC y gestión de riesgos de seguridad (EBA/GL/2019/04) con la finalidad de definir los requisitos para las entidades de crédito, empresas de inversión y proveedores de servicios de pago (PSP) sobre la mitigación y gestión de las TIC y los riesgos de seguridad.

Por tanto, se plantea un proyecto cuyo objetivo sea la obtención de un producto software innovador que permita eficientar el proceso de evaluación y futura gestión, establecido por la normativa GL/2019/04 de la EBA referente a los riesgos tecnológicos y de seguridad de la información. Para ello, se pretende desarrollar un producto software permita dar respuesta a las siguientes actividades:

• Identificar aquellos activos IT bajo alcance de la normativa.
• Gestionar la aplicabilidad de las directrices en función de los activos.
• Identificar los responsables de la aplicabilidad de las directrices para cada activo IT.
• Soporte en la autoevaluación del grado de cumplimiento de cada directriz de la EBA GL/2019/04 mediante respuestas predeterminadas.
• Gestionar, a partir de los resultados de la autoevaluación, los riesgos de TIC y de seguridad a los que la entidad está expuesta.
• Dar soporte en el proceso de definición de medidas y generación del plan de acción.
• Proporcionar asistencia en el proceso de evaluación continua sobre la gestión de riesgos TIC.
• Generar cuadros de BI para dar soporte sobre el proceso de mejora continua sobre la gestión de riesgos TIC.
• Cumplimiento de la Norma ISO/IEC 9126 que se utiliza para definir la calidad en uso como la perspectiva del usuario de la calidad del producto software cuando éste es usado en un ambiente específico y un contexto de uso específico, en este caso la evaluación de los riesgos TIC sobre las entidades bancarias. De manera más concreta:

- Puesta en marcha de la herramienta con una tasa de errores inferior del 3%.

- Las funcionalidades de la herramienta se adaptan a las exigidas por la EBA GL/2019/04.

- La herramienta tiene una disponibilidad de 24x7, estando siempre disponible y no dejando de funcionar salvo en situaciones de mantenimiento.

- Portabilidad a todo tipo de herramientas, la normativa EBA GL/2019/04 define que tipo de software bancarios son aplicables a la misma. No obstante, la herramienta desarrollada debe ser aplicable a todos definidos en dicho alcance.

- Escalabilidad, la herramienta debe ser escalable con el paso del tiempo puesto que las normas suelen evolucionar con el paso de los años demandando nuevos controles.

- Usabilidad, la propia herramienta debe ser sencilla de utilizar, proporcionando al usuario

A1. Describe las etapas del plan de gestión del riesgo aplicadas a dicho proyecto y explica la metodología a emplear en cada una de las etapas.

Identificación de los riesgos, para identificar los riesgos es necesario preguntarse ¿Qué puede fallar? A continuación, se han identificado los riesgos asociados al proyecto teniendo en cuenta qué puede fallar durante la ejecución del mismo. Los riesgos asociados al proyecto han sido los siguientes: (Riesgo 1. Cambio o actualización del informe final sobre las directrices sobre TIC y gestión de riesgos de seguridad (EBA/GL/2019/04). // Riesgo 2. Abandono por baja o enfermedad por personal clave en el desarrollo del proyecto. // Riesgo 3. Usurpación o plagio de la idea/herramienta por parte de la competencia o algún miembro del equipo. // Riesgo 4. No disponibilidad del hardware necesario, a raíz de la alta demanda del mismo generada por el mercado cripto. // Riesgo 5. Errores en la implementación del código, que generen resultados incorrectos. )

Cuantificación y priorización de los riesgos. Posteriormente, se ha realizado una cuantificación y priorización de los riesgos a través del numero de prioridad del riesgo (NPR).

Respuesta a los riesgos: Una vez identificados los riesgos es necesario dar respuesta y supervisar a cada uno de ellos generando un plan de contingencia. El mismo se ha desarrollado teniendo en cuenta la jerarquización de los mismos.

Riesgo 3: Este riesgo contempla la posibilidad de que dentro del proyecto exista una fuga de información o que las herramientas de vigilancia tecnológica de la competencia consigan llegar a este proyecto. Es por este motivo que para la realización del mismo se plantean cláusulas de confidencialidad en el contrato de todos los empleados que cubran parte del riesgo y el cifrado de información de las máquinas que alberguen información relativa al mismo. Por otra parte, en lo que respecta a la supervisión la información extraída, vía correo, usb o cualquier otro medio, quedará registrada en una herramienta destinada a ello y de manera semanal una empresa ajena al proyecto identificará e investigará aquellas personas que hayan sustraído cualquier tipo de información.

Riesgo 1: Aunque es poco probable que se modifiquen las directrices establecidas por la EBA, no es imposible. Es por este motivo que la herramienta debe ser lo más escalable posible, tal y como se había definido anteriormente, con tal de poder adaptarse a cualquier modificación. De igual forma, el código desarrollado debe estar lo más estandarizado y documentado posible con tal de que sea entendible por cualquier experto en la materia. Como factor de supervisión será necesario revisar la página web oficial de la Autoridad Bancaria Europea con la finalidad de comprobar si se ha producido alguna actualización.

Riesgo 2: En tiempos de pandemia y en el sector de desarrolladores donde los mismos están continuamente cambiando de empresa, cabe la posibilidad de que algún miembro de la compañía abandone la empresa. Es por este motivo que es necesario contar con cláusulas en los contratos que exijan notificar las bajas de empleados en un tiempo que permita buscar personal en el mercado y que por otra parte contemplen la posibilidad de realización de horas extra por el resto de miembros del equipo con la finalidad de cubrir estas bajas en caso de que sean temporales. En lo referente a la supervisión, con tal de identificar estas situaciones, por una parte, se realizarán encuestas de satisfacción a los empleados. Por otra parte, se les proporcionará la posibilidad de contar con servicio médico privado con tal de prevenir e identificar cualquier problema de salud.

B1. En relación con la evaluación de la calidad de los entregables, indica tres ejemplos de criterios científicos y tres ejemplos de criterios formales que deberían cumplir los entregables del Proyecto mencionado, así como el proceso de revisión para asegurar la consistencia y calidad de los mismos.

Estos criterios de evaluación permiten a las personas encargadas de revisar el contenido de los entregables seguir una guía y asegurar que todos usan los mismos criterios para evaluar la calidad. Consiste en una plantilla que considera todo o parte de los puntos siguientes, en función del tipo de proyecto. Los mismos se dividen en dos modalidades.

Los criterios científicos se evalúan en base a una escala de Likert, por lo cual las respuestas tienen que ser codificadas como 1-2-3-4-5 (1 corresponde a bajo y 5 a alto).

- Relevancia: Esta cuestión se refiere a la relevancia de los contenidos en relación con los objetivos del proyecto, y de la tarea que general el entregable. En el caso anteriormente descrito, la entrega del paquete referente al ejecutable software tendría una relevancia alta.

- Prototipo, este punto tiene que ver con la documentación entregada que acompaña el prototipo. La información de usabilidad de la herramienta tiene una importancia alta también puesto que sin la misma los usuarios no pueden hacer uso de esta y no serviría para nada el proyecto en cuestión.

- Novedad, evalúa si nuevos problemas o nuevos enfoques están presentados en el entregable. Es de vital importancia si se producen nuevos enfoques entorno a las directrices sobre las que se desarrolla la herramienta.

Por otra parte, se identifican tres criterios de forma:

- Terminología, todos los términos específicos tienen que estar adecuadamente explicados, para proveer el marco de referencia para el lector. Al tratarse de una herramienta IT es relevante incluir un glosario de conceptos donde se identifique todos aquellos utilizados en el entregable.

- Estandarización, es importante que los documentos del proyecto tengan una apariencia y estructura uniforme. Para ello, se pretende la utilización de una plantilla que incluya los logos, portada y formato prefedefinidos para todos los entregables.

- Estructura, todos los entregables deben contar con una estructura que cuente con una portada, índice, miembros que han participado en el desarrollo del mismo, desarrollo y referencias bibliográficas.

C1. Explica cómo se llevarán a cabo las reuniones de seguimiento de este proyecto, su importancia, los roles principales en las mismas, y elabora un formato o plantilla para el acta de las reuniones.

Las reuniones que se lleven a cabo, tanto presenciales en caso de que proceda como las virtuales, durante la elaboración del proyecto deben ser partícipes los siguientes miembros del equipo:

• Moderador, TD – 1: encargado de determinar los objetivos de la reunión, los puntos a tratar y responsable de guiar la reunión cumpliendo con los objetivos para que la misma ha sido definida.

• Facilitador, TD – 2: Encargado de la logística de la reunión, en el caso de ser virtual la creación del enlace de videollamada y los recursos necesarios para cada miembro.

• Secretario, PwC – 1: Responsable de la creación del acta de la reunión en la que se registran los puntos a tratar y los acciones a realizar por cada miembro. 

• Participantes: A definir según se plantee el motivo de la reunión.

Incluir plantilla

A2. Define entre 7-10 criterios de calidad que apliquen al proyecto mencionado teniendo en cuenta los siguientes elementos: (Objetivos del proyecto (requisitos) // Promotor/cliente del proyecto // Participantes en el desarrollo del proyecto // Tiempo y recursos a disposición // Otros factores externos)

Los criterios de calidad definidos para el proyecto son los siguientes:

- Diseñar una solución tecnológica que pueda utilizarse en la totalidad de departamentos de auditoria que cuenten con software bajo las directrices de la EBA 2019/04. (Objetivos del proyecto)

- Desarrollar una solución que permita extraer, analizar y documentar los resultados del análisis de todas las validaciones de las directrices de la EBA para los diferentes departamentos de auditoria. (Necesidades y expectativas del cliente)

- Al realizarse el proyecto con empleados propios de la empresa en la que su principal trabajo es la auditoría, establecer al menos un día a la semana de dedicación completa al proyecto. (Participantes del proyecto)

- El desarrollo de la herramienta debe ajustarse al tiempo de 12 meses definido desde el momento en que dé comienzo al desarrollo de software como tal. (Tiempo y recursos a disposición)

- La herramienta ha de cumplir con lo establecido en la ISO/IEC 9126 utilizada para definir la calidad en uso como la perspectiva del usuario de la calidad del producto software. (Otros factores externos)

C2. ¿Qué apartados básicos tendría el Plan de Calidad del proyecto descrito? Explica brevemente su contenido, es decir, qué tipo de información se desarrollaría en cada uno de ellos.

1. Introducción

2. Procesos contractuales            

3. Organización y responsabilidades       

4. Comunicaciones y colaboración (4.1 Medios de comunicación // 4.2 Plataformas de colaboración //  4.3 Reuniones)

5. Aseguramiento de la calidad y gestión del riesgo (5.1 Establecimiento de métricas de calidad//5.2 Proceso de producción de entregables//5.3 Proceso de revisión de entregables//5.4 Proceso de monitorización y evaluación de la calidad//5.5 Proceso de identificación de riesgos //5.6 Proceso de monitorización y mitigación de riesgos)

6. Anexos (plantillas)(6.1. Plantilla para el control de documentos//6.2 Plantilla para acta de reunión//

6.3 Plantilla para la revisión de documentos)

C3. Indica qué medios de comunicación se pondrán a disposición de los participantes de este proyecto y en qué casos será recomendable utilizar cada uno de ellos. Así mismo, explica qué son las plataformas de colaboración, 2 ejemplos:
A continuación, se definen los medios de comunicación establecidos para llevar a cabo el proyecto.
Correo electrónico: Medio de comunicación preferible para llevar a cabo la comunicación escrita del proyecto. El asunto a tratar vendrá predefinido con Proyecto EBA – XXXX. El uso de dominios fuera del proyecto está restringido y prohibido.
Chat Teams: Medio de comunicación para tareas telemáticas no relevantes. El borrado de comentarios y registro deberá estar deshabilitado. Se utilizará únicamente Microsft Teams.
Documentos en papel: Los documentos en papel serán enviados por correo postal. Siendo esta opción únicamente preferible bajo circunstancias justificadas.
Audio y vídeo conferencias: Debido al COVID será preferible mantener reuniones telemáticas a través de la herramienta Teams de Micrsoft.
Teléfono: Únicamente se utilizará en caso de que las plataformas previamente comentadas no se encuentren disponibles.

Plataformas de colaboración Gestión de la colaboración online, por ejemplo, combinando Dropbox6 con Googledocs, se obtiene un entorno que permite compartir documentos por una parte y editarlos conjuntamente por otra. La elección de la plataforma o del entorno colaborativo debería tener en cuenta varios factores, como pueden ser: ( · Las facilidades y los sistemas ya en uso por parte de los participantes. // · Existen plataformas particularmente diseñadas para la gestión de proyectos colaborativos y el intercambio de documentos. // · Existen entornos de código abierto, que tienen la ventaja de ser gratuitos.). En el caso de desarrollo de software: Si el proyecto prevé actividades de desarrollo de software conviene utilizar herramientas de control de cambios y versiones como por ejemplo la Subversion de código abierto (SVN).

C4. Explica cómo se llevarán a cabo las reuniones de seguimiento de este proyecto, su importancia, los roles principales en las mismas, y elabora un formato o plantilla para el acta de las reuniones.

Las reuniones que se lleven a cabo, tanto presenciales en caso de que proceda como las virtuales, durante la elaboración del proyecto deben ser partícipes los siguientes miembros del equipo:

• Moderador, TD – 1: encargado de determinar los objetivos de la reunión, los puntos a tratar y responsable de guiar la reunión cumpliendo con los objetivos para que la misma ha sido definida.

• Facilitador, TD – 2: Encargado de la logística de la reunión, en el caso de ser virtual la creación del enlace de videollamada y los recursos necesarios para cada miembro.

• Secretario, PwC – 1: Responsable de la creación del acta de la reunión en la que se registran los puntos a tratar y los acciones a realizar por cada miembro.

• Participantes: A definir según se plantee el motivo de la reunión.

Plantilla

A3. Elabora una tabla con un mínimo de 5 métricas de calidad para el proyecto mencionado, incluyendo el tipo de métrica, descripción sobre lo que se quiere medir (objetivo de calidad) y cómo medirlo (indicador), así como su valor mínimo de aceptación.