• No se han encontrado resultados

Seguridad de los Procesos de Desarrollo y Soporte

10. Desarrollo y Mantenimiento de Sistemas

10.5. Seguridad de los Procesos de Desarrollo y Soporte

Esta Política promueve la seguridad del software y de la información del sistema de apli- cación, por lo tanto el Responsable del Sistema de Información y el Responsable de Seguridad Informática controlarán los entornos y el soporte dado a los mismos.

10.5.1. Procedimiento de Control de Cambios.

A fin de minimizar los riesgos de alteración de los sistemas de información, se implemen- tarán controles estrictos durante la implementación de cambios imponiendo el cumplimiento de procedimientos formales. Éstos garantizarán que se cumplan los procedimientos de seguridad y control, respetando la división de funciones.

Para ello el Responsable del Sistema de Información y el Responsable de Seguridad Infor- mática establecerán un procedimiento que incluya las siguientes consideraciones:

1. Verificar que los cambios sean propuestos por usuarios autorizados y respete los términos y condiciones que surjan de la licencia de uso.

2. Mantener un registro de los niveles de autorización acordados.

3. Solicitar la autorización del Propietario de la Información, en caso de tratarse de cambios a sistemas de procesamiento de la misma.

4. Identificar todos los elementos que requieren modificaciones (software, bases de datos, hardware).

5. Revisar los controles y los procedimientos de integridad para garantizar que no serán com- prometidos por los cambios.

6. Obtener aprobación formal por parte del Responsable del Área Informática para las tareas detalladas, antes de que comiencen las tareas.

7. Solicitar la revisión del Responsable de Seguridad Informática para garantizar que no se violen los requerimientos de seguridad que debe cumplir el software.

8. Efectuar las actividades relativas al cambio en el ambiente de desarrollo.

9. Obtener la aprobación por parte del usuario autorizado y del área de pruebas mediante pruebas en el ambiente correspondiente.

10. Actualizar la documentación para cada cambio implementado, tanto de los manuales de usuario como de la documentación operativa.

11. Mantener un control de versiones para todas las actualizaciones de software.

12. Garantizar que la implementación se llevará a cabo minimizando la discontinuidad de las actividades y sin alterar los procesos involucrados.

13. Informar a las áreas usuarias antes de la implementación de un cambio que pueda afectar su operatoria.

14. Garantizar que sea el implementador quien efectúe el pasaje de los objetos modificados al ambiente operativo, de acuerdo a lo establecido en “§10.4.1 Control del Software Operati- vo.”.

En el Anexo XI se presenta un esquema modelo de segregación de ambientes de procesa- miento. Este anexo será actualizado por el Comité de Seguridad de la Información.

10.5.2. Revisión Técnica de los Cambios en el Sistema Operativo.

Toda vez que sea necesario realizar un cambio en el Sistema Operativo, los sistemas serán revisados para asegurar que no se produzca un impacto en su funcionamiento o seguridad.

Para ello, el Responsable del Sistema de Información y el Responsable del Área Informática elaborarán un procedimiento que incluya:

1. Revisar los procedimientos de integridad y control de aplicaciones para garantizar que no hayan sido comprometidas por el cambio.

10 DESARROLLO Y MANTENIMIENTO DE SISTEMAS. 73

2. Garantizar que los cambios en el sistema operativo sean informados con anterioridad a la implementación.

3. Asegurar la actualización del Plan de Continuidad de las Actividades de la UNC.

10.5.3. Restricción del Cambio de Paquetes de Software.

En caso de considerarlo necesario la modificación de paquetes de software suministrados por proveedores, y previa autorización del Responsable del Área Informática, el Propietario de la Información y el Responsable de Seguridad Informática deberán:

1. Analizar los términos y condiciones de la licencia a fin de determinar si las modificaciones se encuentran autorizadas.

2. Determinar la conveniencia de que la modificación sea efectuada por la UNC, por el pro- veedor o por un tercero.

3. Evaluar el impacto que se produce si la UNC se hace cargo del mantenimiento.

4. Retener el software original realizando los cambios sobre una copia perfectamente identi- ficada, documentando exhaustivamente por si fuera necesario aplicarlo a nuevas versiones.

10.5.4. Canales Ocultos y Código Malicioso.

Un canal oculto puede exponer información utilizando algunos medios indirectos y descono- cidos. El código malicioso está diseñado para afectar a un sistema en forma no autorizada y no requerida por el usuario.

En este sentido, el Responsable de Seguridad Informática y el Responsable del Área Infor- mática redactarán normas y procedimientos que incluyan:

1. Adquirir programas a proveedores acreditados o productos ya evaluados.

2. Examinar los códigos fuentes (cuando sea posible) antes de utilizar los programas. 3. Controlar el acceso y las modificaciones al código instalado.

4. Utilizar herramientas para la protección contra la infección del software con código mali- cioso.

10.5.5. Desarrollo Externo de Software.

Para el caso que se considere la tercerización del desarrollo de software, el Propietario de la Información, el Responsable de Seguridad Informática y el Responsable del Área Informática establecerán normas y procedimientos que contemplen los siguientes puntos:

1. Acuerdos de licencias, propiedad de código y derechos conferidos. (Ver “§12.1.2 Derechos de Propiedad Intelectual.”)

2. Requerimientos contractuales con respecto a la calidad del código y la existencia de ga- rantías.

3. Procedimientos de certificación de la calidad y precisión del trabajo llevado a cabo por el proveedor, que incluyan auditorías, revisión de código para detectar código malicioso, ve- rificación del cumplimiento de los requerimientos de seguridad del software establecidos, etc.

4. Verificación del cumplimiento de las condiciones de seguridad contempladas en el punto “§4.3.1 Requerimientos de Seguridad en Contratos de Tercerización.”.

5. Acuerdos de custodia de los fuentes del software (y cualquier otra información requerida) en caso de quiebra de la tercera parte.