Proyecto de Desarrollo de Software para la Gestión de Riesgos TIC bajo la Normativa EBA

Se describe un proyecto concreto enfocado en la creación de un producto de software innovador para eficientar la evaluación y gestión de riesgos tecnológicos y de seguridad de la información, siguiendo las directrices establecidas por la Autoridad Bancaria Europea (EBA) en su informe final EBA/GL/2019/04.

En los últimos años, la digitalización del sector financiero y la creciente interconexión con otras instituciones y terceros a través de canales de telecomunicaciones han impulsado a la EBA a publicar estas directrices. El objetivo es definir requisitos claros para entidades de crédito, empresas de inversión y Proveedores de Servicios de Pago (PSP) sobre la mitigación y gestión de los riesgos de Tecnologías de la Información y Comunicación (TIC) y de seguridad.

Objetivo del Producto Software

El proyecto busca desarrollar un producto software que dé respuesta a las siguientes actividades clave:

• Identificar los activos de TI bajo el alcance de la normativa.
• Gestionar la aplicabilidad de las directrices en función de dichos activos.
• Identificar a los responsables de la aplicabilidad de las directrices para cada activo de TI.
• 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 Business Intelligence (BI) para apoyar el proceso de mejora continua en la gestión de riesgos TIC.
• Cumplimiento de la Norma ISO/IEC 9126, utilizada para definir la calidad en uso desde la perspectiva del usuario del producto software en un contexto específico (evaluación de riesgos TIC en entidades bancarias). Específicamente, se busca:
  • Puesta en marcha de la herramienta con una tasa de errores inferior al 3%.
  • Adaptación de las funcionalidades a las exigencias de la EBA GL/2019/04.
  • Disponibilidad de la herramienta 24×7, salvo en situaciones de mantenimiento.
  • Portabilidad a todo tipo de software bancario definido en el alcance de la EBA GL/2019/04.
  • Escalabilidad para adaptarse a la evolución futura de las normas y nuevos controles.
  • Usabilidad: la herramienta debe ser sencilla de utilizar, proporcionando al usuario…

A1. Plan de Gestión del Riesgo del Proyecto

A continuación, se describen las etapas del plan de gestión del riesgo aplicadas a este proyecto y la metodología empleada en cada una.

Etapa 1: Identificación de los Riesgos

Para identificar los riesgos, es fundamental plantear la pregunta: ¿Qué puede fallar? Se identificaron los siguientes riesgos asociados a la ejecución del proyecto:

1. Cambio o actualización del informe final sobre las directrices sobre TIC y gestión de riesgos de seguridad (EBA/GL/2019/04).
2. Abandono por baja o enfermedad de personal clave en el desarrollo del proyecto.
3. Usurpación o plagio de la idea/herramienta por parte de la competencia o algún miembro del equipo.
4. No disponibilidad del hardware necesario, a raíz de la alta demanda generada por el mercado cripto.
5. Errores en la implementación del código, que generen resultados incorrectos.

Etapa 2: Cuantificación y Priorización de los Riesgos

Se realizó una cuantificación y priorización utilizando el Número de Prioridad del Riesgo (NPR), evaluando Severidad, Importancia, Probabilidad e Impacto del Riesgo.

Etapa 3: Respuesta a los Riesgos y Supervisión

Una vez identificados y jerarquizados, es necesario dar respuesta y supervisar cada riesgo mediante un plan de contingencia.

Respuesta al Riesgo 3 (NPR 48 – Riesgo Alto)

Este riesgo contempla la posibilidad de fuga de información o que herramientas de vigilancia tecnológica de la competencia accedan al proyecto. Para su mitigación se plantean:

• Mitigación: Cláusulas de confidencialidad en el contrato de todos los empleados. Cifrado de la información en las máquinas que alberguen datos relativos al proyecto.
• Supervisión: Registro de toda información extraída (vía correo, USB o cualquier otro medio) en una herramienta destinada a ello. Una empresa externa al proyecto identificará e investigará semanalmente a las personas que hayan sustraído cualquier tipo de información.

Respuesta al Riesgo 1 (NPR 18)

Aunque es poco probable que se modifiquen las directrices de la EBA, no es imposible. La respuesta se centra en la adaptabilidad:

• Mitigación: La herramienta debe ser lo más escalable posible, tal como se definió en los requisitos de calidad. El código desarrollado debe estar estandarizado y documentado para ser comprensible por cualquier experto en la materia.
• Supervisión: Revisión periódica de la página web oficial de la Autoridad Bancaria Europea para comprobar si se ha producido alguna actualización.

Respuesta al Riesgo 2 (NPR 16)

Dada la rotación en el sector de desarrolladores, existe la posibilidad de abandono de personal clave.

• Mitigación: Cláusulas contractuales que exijan notificar las bajas con tiempo suficiente para buscar reemplazo. Contemplar la realización de horas extra por el resto del equipo para cubrir bajas temporales.
• Supervisión: Realización de encuestas de satisfacción a los empleados. Provisión de servicio médico privado para prevenir e identificar problemas de salud.

B1. Criterios de Evaluación de Calidad de Entregables

Los criterios de evaluación sirven como referencia para los revisores, asegurando que todos aplican los mismos estándares de calidad a los entregables. Estos se dividen en científicos y formales.

Criterios Científicos

Estos criterios se evalúan típicamente mediante una escala de Likert (1=Bajo, 5=Alto):

1. Relevancia: Se refiere a la pertinencia de los contenidos respecto a los objetivos del proyecto y la tarea que genera el entregable. (Ejemplo: La entrega del paquete referente al ejecutable software tendría una relevancia alta).
2. Prototipo (Documentación asociada): Se evalúa la documentación que acompaña al prototipo. La información de usabilidad de la herramienta es de alta importancia, ya que sin ella el proyecto no sería funcional para los usuarios.
3. Novedad: Evalúa si el entregable presenta nuevos enfoques o aborda problemas de manera innovadora. Es vital si surgen nuevos enfoques en torno a las directrices sobre las que se desarrolla la herramienta.

Criterios Formales

Se identifican tres criterios formales para asegurar la consistencia:

• Terminología: Todos los términos específicos deben estar adecuadamente explicados para proveer un marco de referencia al lector. En una herramienta de TI, es relevante incluir un glosario de conceptos utilizados en el entregable.
• Estandarización: Es importante que los documentos del proyecto mantengan una apariencia y estructura uniformes. Se propone el uso de una plantilla que incluya logos, portada y formato predefinidos para todos los entregables.
• Estructura: Todos los entregables deben contar con una estructura definida: portada, índice, listado de miembros participantes, desarrollo y referencias bibliográficas.

C1. Reuniones de Seguimiento del Proyecto

Las reuniones de seguimiento, ya sean presenciales o virtuales, deben contar con la participación de roles definidos para asegurar la eficiencia y el registro adecuado.

Importancia y Roles Principales

La importancia radica en mantener la alineación del equipo, resolver impedimentos y documentar decisiones y acciones pendientes.

• Moderador (TD – 1): Encargado de determinar los objetivos de la reunión, los puntos a tratar y responsable de guiar la sesión cumpliendo con los objetivos definidos.
• Facilitador (TD – 2): Encargado de la logística de la reunión, incluyendo la creación del enlace de videollamada y la provisión de recursos necesarios para cada miembro en caso de ser virtual.
• Secretario (PwC – 1): Responsable de la creación del acta de la reunión, donde se registran los puntos tratados y las acciones a realizar por cada miembro.
• Participantes: A definir según el motivo específico de la reunión (ej. desarrolladores, expertos en normativa, cliente).

Plantilla para el Acta de Reunión

Se adjunta un formato básico para el acta de reuniones:

%IMAGE%

A2. Criterios de Calidad del Proyecto

Se definen 7 criterios de calidad aplicables al proyecto, considerando los elementos solicitados:

1. Diseño Universal (Objetivos del proyecto): Diseñar una solución tecnológica que pueda utilizarse en la totalidad de departamentos de auditoría que cuenten con software bajo las directrices de la EBA 2019/04.
2. Capacidad de Extracción y Documentación (Necesidades del cliente): 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 auditoría.
3. Dedicación Consistente (Participantes del proyecto): Al realizarse el proyecto con empleados cuya principal labor es la auditoría, establecer al menos un día a la semana de dedicación completa al proyecto para asegurar el avance.
4. Cumplimiento del Plazo (Tiempo y recursos a disposición): El desarrollo de la herramienta debe ajustarse al tiempo de 12 meses definido desde el inicio del desarrollo de software como tal.
5. Calidad en Uso (Otros factores externos): La herramienta ha de cumplir con lo establecido en la ISO/IEC 9126, enfocándose en la perspectiva del usuario de la calidad del producto software.
6. Tasa de Error Mínima (Requisito funcional): La tasa de errores en la ejecución del software no debe superar el 3%.
7. Documentación Completa (Entregables): Todos los entregables deben incluir documentación técnica y funcional completa, incluyendo diagramas de arquitectura y manuales de usuario.

C2. Apartados Básicos del Plan de Calidad

El Plan de Calidad del proyecto descrito incluiría los siguientes apartados básicos, detallando la información que se desarrollaría en cada uno:

1. Introducción: Propósito del Plan de Calidad, alcance del proyecto y referencias normativas (EBA GL/2019/04, ISO/IEC 9126).
2. Procesos Contractuales: Definición de los acuerdos de nivel de servicio (SLA) y los requisitos de calidad acordados con el promotor/cliente.
3. Organización y Responsabilidades: Definición de roles (como los vistos en C1) y sus responsabilidades específicas en relación con las actividades de aseguramiento y control de calidad.
4. Comunicaciones y Colaboración:
   • 4.1 Medios de comunicación: Definición de las herramientas a usar (ver C3).
   • 4.2 Plataformas de colaboración: Especificación de las herramientas para trabajo conjunto (ver C3).
   • 4.3 Reuniones: Frecuencia y estructura de las reuniones de seguimiento (ver C1).
5. Aseguramiento de la Calidad y Gestión del Riesgo:
   • 5.1 Establecimiento de métricas de calidad: Definición de los indicadores clave (KPIs) a medir (ver A3).
   • 5.2 Proceso de producción de entregables: Estándares y procedimientos para la creación de cada producto de trabajo.
   • 5.3 Proceso de revisión de entregables: Metodología para la verificación y validación (incluyendo criterios científicos y formales).
   • 5.4 Proceso de monitorización y evaluación de la calidad: Cómo se recopilarán y reportarán los datos de calidad.
   • 5.5 Proceso de identificación de riesgos: Metodología para la detección continua de riesgos.
   • 5.6 Proceso de monitorización y mitigación de riesgos: Seguimiento de los planes de respuesta definidos.
6. Anexos (Plantillas):
   • 6.1 Plantilla para el control de documentos.
   • 6.2 Plantilla para acta de reunión (ver C1).
   • 6.3 Plantilla para la revisión de documentos.

C3. Medios de Comunicación y Plataformas de Colaboración

A continuación, se definen los medios de comunicación establecidos para llevar a cabo el proyecto y su uso recomendado:

Medios de Comunicación

• Correo electrónico: Medio preferible para la comunicación escrita formal del proyecto. El asunto debe estar predefinido con el formato: Proyecto EBA – XXXX. El uso de dominios externos al proyecto está restringido y prohibido.
• Chat Teams: Medio para tareas telemáticas de menor relevancia o consultas rápidas. El borrado de comentarios y registro debe estar deshabilitado. Se utilizará únicamente Microsoft Teams.
• Documentos en papel: Se utilizarán únicamente para el envío de documentos formales por correo postal, siendo esta opción preferible solo bajo circunstancias justificadas que impidan el uso digital.
• Audio y videoconferencias: Debido a las circunstancias actuales (ej. COVID), se priorizarán las reuniones telemáticas a través de la herramienta Teams de Microsoft.
• Teléfono: Se utilizará únicamente en caso de que las plataformas digitales previamente comentadas no se encuentren disponibles o para comunicaciones urgentes que requieran inmediatez.

Plataformas de Colaboración

Las plataformas de colaboración gestionan la colaboración en línea, combinando el intercambio de documentos con la edición conjunta. La elección de la plataforma debe considerar:

• Las facilidades y sistemas ya en uso por parte de los participantes.
• La existencia de plataformas diseñadas específicamente para la gestión de proyectos colaborativos y el intercambio de documentos.
• La disponibilidad de entornos de código abierto (ventaja de ser gratuitos).

Ejemplos de Plataformas de Colaboración:

1. Entorno de Documentación Compartida: Combinación de herramientas como Dropbox con Google Docs, permitiendo compartir y editar documentos conjuntamente.
2. Control de Cambios y Versiones (Para desarrollo de software): Si el proyecto incluye desarrollo de software, es conveniente utilizar herramientas de control de versiones como Subversion (SVN), que es de código abierto.

C4. Reuniones de Seguimiento del Proyecto (Repetición y Formato)

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 de Acta:

%IMAGE%

A3. Métricas de Calidad del Proyecto

A continuación, se presenta una tabla con 5 métricas de calidad aplicables al proyecto, incluyendo el tipo, el objetivo de calidad y el indicador de medición (cómo medirlo), junto con su valor mínimo de aceptación.

Nota: Las imágenes y contienen la tabla solicitada con las métricas de calidad.

Etiquetas: calidad de software, desarrollo de software, EBA GL/2019/04, Gestión de Riesgos TIC, ISO/IEC 9126, seguridad de la información