Iso De La Matematicas

10.4.3 Control de acceso a las bibliotecas de programa fuente

A fin de reducir la probabilidad de alteración de programas de computadora, se debe mantener un control estricto del acceso a las bibliotecas de programa fuente, según los siguientes puntos (ver también el punto 8.3).

a) Dentro de lo posible, las bibliotecas de programas fuente no deben ser almacenadas en los sistemas que está operativo.

b) Se debe designar a un bibliotecario de programas para cada aplicación.

c) El personal de soporte de TI no debe tener acceso irrestricto a las bibliotecas de programas fuente.

d) Los programas en desarrollo o mantenimiento no deben ser almacenados en las bibliotecas de programas fuente operacional.

e) La actualización de bibliotecas de programas fuente y la distribución de programas fuente a los programadores, solo debe ser llevada a cabo por el bibliotecario designado, con la autorización del gerente de soporte de TI para la aplicación pertinente.

f) Los listados de programas deben ser almacenados en un ambiente seguro (ver 8.6.4).

g) Se debe mantener un registro de auditoria de todos los accesos a las bibliotecas de programa fuente.

h) Las viejas versiones de los programas fuente deben ser archivadas con una clara indicación de las fechas y horas precisas en las cuales estaban en operaciones, junto con todo el software de soporte, el control de tareas, las definiciones de datos y los procedimientos.

i) El mantenimiento y la copia de las bibliotecas de programas fuente deben estar sujeta a procedimientos estrictos de control de cambios (ver 10.4.1).

10.5 Seguridad de los procesos de desarrollo y soporte

Objetivo: Mantener la seguridad del software y la información del sistema de aplicación.

Se deben controlar estrictamente los entornos de los proyectos y el soporte a los mismos.

Los gerentes responsables de los sistemas de aplicación también deben ser responsables de la seguridad del ambiente del proyecto y del soporte. Los gerentes deben garantizar que todos los cambios propuestos para el sistema sean revisados, a fin de comprobar que los mismos no comprometen la seguridad del sistema o del ambiente operativo.

10.5.1 Procedimientos de control de cambios

A fin de minimizar la alteración de los sistemas de información, debe existir un control estricto de la implementación de los cambios. Se debe imponer el cumplimiento de los procedimientos formales de control de cambios. Estos deben garantizar que no se comprometan los procedimientos de seguridad y control, que los programadores de soporte solo tengan acceso a aquellas partes del sistema necesarias para el desempeño de sus tareas, y que se obtenga un acuerdo y aprobación formal para cualquier cambio. Los cambios en el software de aplicaciones pueden tener repercusiones en el ambiente operativo. Siempre que resulte factible, los procedimientos de control de cambios operativos y de aplicaciones deben estar integrados (ver también 8.1.2). Este proceso debe incluir:

a) mantener un registro de los niveles de autorización acordados;

b) garantizar que los cambios son propuestos por usuarios autorizados;

c) revisar los controles y los procedimientos de integridad para garantizar que no serán comprometidos por los cambios;

d) identificar todo el software, la información, las entidades de bases de datos y el hardware que requieran correcciones;

e) obtener aprobación formal para las propuestas detalladas antes de que comiencen las tareas;

f) garantizar que el usuario autorizado acepte los cambios antes de cualquier implementación;

g) garantizar que la implementación se lleve a cabo minimizando la discontinuidad de las actividades de la empresa;

h) garantizar que la documentación del sistema será actualizada cada vez que se completa un cambio y se archiva o elimina la documentación vieja;

i) mantener un control de versiones para todas las actualizaciones de software;

j) mantener una pista de auditoria de todas las solicitudes de cambios;

k) garantizar que la documentación operativa (ver 8.1.1) y los procedimientos de usuarios se modifiquen según las necesidades de adecuación;

l) garantizar que la implementación de cambios tenga lugar en el momento adecuado y no altere los procesos comerciales involucrados.

Muchas organizaciones mantienen un ambiente en el cual los usuarios prueban nuevo software y que esta separado de los ambientes de desarrollo y producción. Esto proporciona un medio para controlar el nuevo software y permitir la protección adicional de la información operacional que se utiliza con propósitos de prueba.

10.5.2 Revisión técnica de los cambios en el sistema operativo

Periódicamente es necesario cambiar el sistema operativo, por ej. instalar una versión nueva de software o parches. Cuando se realizan los cambio, los sistemas de aplicación deben ser revisados y probados para garantizar que no se produzca un impacto adverso en las operaciones o en la seguridad. Este proceso debe cubrir:

a) revisión de procedimientos de integridad y control de aplicaciones para garantizar que estos no hayan sido comprometidos por los cambios del sistema operativo;

b) garantizar que el plan y presupuesto de soporte anual contemple las revisiones y las pruebas del sistema que deban realizarse como consecuencia del cambio en el sistema operativo;

c) garantizar que se notifiquen los cambios del sistema operativo de manera oportuna antes de la implementación;

d) garantizar que se realicen cambios apropiados en los planes de continuidad de la empresa (ver punto 11).

10.5.3 Restricción del cambio en los paquetes de software

Se debe desalentar la realización de modificaciones a los paquetes de software. En la medida de lo posible, y de lo viable, los paquetes de software suministrados por proveedores deben ser utilizados sin modificación. Cuando se considere esencial modificar un paquete de software, se deben tener en cuenta los siguientes puntos:

a) el riesgo de compromiso de los procesos de integridad y controles incorporados;

b) si se debe obtener el consentimiento del proveedor;

c) la posibilidad de obtener del proveedor los cambios requeridos como actualizaciones estándar de programas;

d) el impacto que se produciría si la organización se hace responsable del mantenimiento futuro del software como resultado de los cambios.

Si los cambios se consideran esenciales, se debe retener el software original y aplicar los cambios a una copia claramente identificada. Todos los cambios deben ser probados

...