Banca TI: Consejos para la gestión de pruebas

Desde la publicación de la circular "10/2012 (BA) - Requisitos mínimos para la gestión de riesgos MaRisk", así como las explicaciones 12/2012 de la Autoridad Federal de Supervisión Financiera (BaFin), hay un gran número de medidas que deben aplicarse en la TI de los bancos para cumplir los requisitos de AT 7.2 y AT 7.3 en particular. Las auditorías especiales anunciadas con arreglo al artículo 44, apartado 1, de la KWG (Ley bancaria alemana) suponen un reto tanto para los gestores empresariales como para los informáticos.

Hay que superar numerosos formalismos y obstáculos administrativos, además de la pesada carga del día a día. Por supuesto, hay que cumplir los requisitos reglamentarios, pero no es raro que las medidas se pasen de la raya. Es importante encontrar una vía de aplicación adecuada.

Conectar el profesorado, el desarrollo y las operaciones

La gestión de las pruebas constituye el vínculo central entre el departamento técnico, el de desarrollo y el de operaciones. Las medidas prescritas en la prueba provocan efectos secundarios considerables en los ámbitos mencionados.

A continuación se describen enfoques pragmáticos y probados en la práctica a lo largo del proceso de desarrollo de software, con los que se pueden cumplir los requisitos normativos desde la perspectiva de la gestión de pruebas. Puede utilizarse una lista de comprobación (véase la página siguiente) para verificar qué componentes quedan por implementar.

Hay que probar el software nuevo o modificado. La especificación técnica de los casos de prueba por parte de los departamentos inmediatamente antes de la fase de prueba suele resultar un proceso arduo. Es mucho mejor exigir una descripción del escenario de prueba para cada requisito formulado en la fase de concepción.

Concepto: Funciones y permisos

El tema de las funciones y autorizaciones suele tratarse de forma bastante madrastra. También en este caso, TI debería insistir en la definición correcta y completa, la separación de funciones y la formulación de los escenarios de prueba correspondientes ya en la fase de concepción.

Desarrollo: SAP ChaRM

En la actualidad, son imprescindibles unas directrices de desarrollo actualizadas y lo más simplificadas posible, con convenciones de nomenclatura, directrices sobre técnicas de programación críticas y consejos para optimizar el código de los programas.

Además, se recomienda un sistema integrado de gestión de solicitudes y transporte. Para los usuarios de SAP, el componente SAP Change Request Management (ChaRM) del Solution Manager, con procedimientos de aprobación específicos, una estricta separación de funciones y una prueba a prueba de auditorías de la cadena de transporte desde el desarrollo a los sistemas de prueba y aceptación hasta la producción, es una buena elección.

No son muchas las áreas de desarrollo que se toman el tiempo necesario para revisar el código según el principio de los cuatro ojos. También en este caso existen ahora en el mercado buenas herramientas que comprueban el código de los programas en busca de vulnerabilidades relevantes para la seguridad, entre otras cosas, e impiden su transporte a los sistemas de aseguramiento de la calidad o de producción en caso de infracción de las normas.

En el entorno SAP, el Code Profiler de Virtual Forge y el SAP Code Vulnerability Scanner se consideran punteros. El requisito previo para la entrada en la prueba especializada son las pruebas de módulos documentadas por el equipo de desarrollo, así como la denominación de las restricciones de la prueba, como funciones que aún no se han completado o errores que ya se conocen.

También se dispone de herramientas de apoyo. El componente ChaRM de SAP Solution Manager, por ejemplo, permite documentar y probar pruebas de módulos.

En primer lugar, conviene definir claramente los procesos de gestión de pruebas y las funciones en los procesos de prueba y aceptación, y proporcionar plantillas para conceptos de prueba o descripciones de casos de prueba, por ejemplo. También aquí se aplica el principio: "Menos es más".

Separación de funciones

Los pasajes largos en prosa no se leen. Son mejores las listas de comprobación, las tablas y los gráficos. Por cierto, para cumplir los requisitos normativos, es importante la estricta separación de funciones entre el departamento técnico, el de desarrollo y el de pruebas.

Los procedimientos de gestión de pruebas basados en Excel han quedado obsoletos. Las pruebas y las desviaciones deben documentarse y almacenarse de forma trazable y a prueba de auditorías. Es obligatorio el uso de herramientas integradas de gestión de pruebas como HP Application Lifecycle Management (HP ALM) Quality Center, IBM Rational Quality Manager o SAP Solution Manager Test Workbench.

Por motivos de seguridad, no se pueden utilizar datos sensibles (especialmente personales) en entornos de prueba no gestionados centralmente. Por ejemplo, los datos de los socios comerciales deben ser anónimos. Debe definirse un proceso para el acceso a los datos de las pruebas por parte de los probadores (y, en caso necesario, por parte de los desarrolladores para los análisis de errores). La asignación de identificadores de usuario y autorizaciones debe quedar registrada.

Gestión de pruebas: riesgo calculado

La gestión de riesgos es cada vez más importante. Por ejemplo, el banco también debe demostrar que se registran y evalúan los riesgos de las pruebas, como el suministro tardío del software que se va a probar o la falta de infraestructura de pruebas, y que se aplican y controlan las medidas de migración adecuadas.

El enfoque de pruebas basado en el riesgo ha demostrado su eficacia. En este procedimiento, los procesos se evalúan en función de su criticidad, como la frecuencia de llamadas o los requisitos de seguridad, así como con respecto a los cambios y ajustes en el proyecto de pruebas en curso.

De ello se derivan el alcance y la prioridad de los objetos de prueba y los casos de prueba implicados. De este modo, el riesgo se centra en las pruebas realmente importantes.

Es responsabilidad de la gestión de pruebas demostrar que se han creado los tipos de resultados obligatorios, como un concepto de prueba o una planificación de pruebas, que se han realizado las pruebas obligatorias, como las pruebas de seguridad o de recuperación tras desastres (o que se ha justificado su no realización), o que se ha completado correctamente el proceso de aceptación. Un sistema de control interno (SCI) basado en listas de comprobación resulta útil en este caso.

Aplicación y funcionamiento

Durante la implantación, es importante definir procedimientos de traspaso con una estricta separación de funciones entre el desarrollo y el funcionamiento. Para la operación, debe establecerse y operarse un sistema de gestión de la seguridad de la información que cuente con el mayor apoyo posible de herramientas. Desde el punto de vista de la gestión de las pruebas, se puede hacer referencia a los procedimientos de soporte regulares para la recuperación de desastres, por ejemplo.

Conclusión

Deben aplicarse las medidas enumeradas anteriormente para cumplir los requisitos reglamentarios. Se recomienda un enfoque holístico y la aplicación de planteamientos pragmáticos y probados.

La lista de comprobación puede utilizarse para verificar qué componentes aún deben introducirse. Además, deben utilizarse normas como las normas BSI 100-1 a 100-4, ISO 29119 (prueba) o ITIL.

Lista de control

Estos puntos proporcionan una primera visión general de si se cumplen los componentes y cuáles (no se cumplen/se cumplen parcialmente/se cumplen totalmente):

1. ¿Es obligatoria la definición de escenarios de pruebas para los requisitos?
2. ¿Se describen los cambios de funciones y permisos?
3. ¿Existen directrices de desarrollo?
4. ¿Se aplica un sistema integrado de pedidos y transporte?
5. ¿Están estrictamente separadas las funciones de desarrollo y explotación del software?
6. ¿Se realizan revisiones del código?
7. ¿Se están desarrollando herramientas de control de calidad?
8. ¿Se realizan y documentan las pruebas de los módulos?
9. ¿Se describen los procesos y funciones de las pruebas en la gestión de pruebas?
10. ¿Existe una separación estricta de funciones en la prueba entre el departamento, el de desarrollo y el de pruebas?
11. ¿Se dispone de una herramienta integrada de gestión de pruebas?
12. ¿Se protegen/anonimizan los datos sensibles en los sistemas de prueba?
13. ¿Existe un procedimiento para asignar derechos de usuario y autorización para los sistemas de prueba?
14. ¿Se documentan, evalúan y controlan los riesgos de las pruebas?
15. ¿Se da prioridad a la ejecución de los casos de prueba?
16. ¿Se controla sistemáticamente la creación de tipos de resultados obligatorios, así como de pruebas obligatorias (lista de control ICS)?
17. ¿Existe un proceso definido para acceder a los datos sensibles de las pruebas?
18. ¿Está definido el proceso de traspaso a la producción?
19. ¿Se ha establecido un sistema de gestión de la seguridad de la información?
20. ¿Se utilizan normas como ITIL, BSI o DIN ISO?