Resolución N° 641/10
Nro de Expediente:
6003-000222-10
 
PLANIFICACION
Fecha de Aprobación:
22/2/2010

Tema:
VARIOS

Resumen:
Determinar la política de Seguridad en la adquisición, desarrollo y mantenimiento de los sistemas de información, cuyo propósito es establecer los criterios que deben cumplir los procesos de adquisición, desarrollo y mantenimiento de los sistemas de información en la Intendencia Municipal de Montevideo (IMM), de forma de garantizar que la seguridad de la información sea parte integral de estos sistemas:

Montevideo, 22 de Febrero de 2010.-
 
          VISTO: las presentes actuaciones relacionadas con la importancia de identificar y proteger los activos de información de la Intendencia Municipal de Montevideo;
          RESULTANDO: que es objetivo de la Organización garantizar la continuidad de las principales operaciones y minimizar el impacto provocado por incidentes de seguridad, así como garantizar que la información distribuida o producida por la Organización mantenga su integridad y confidencialidad de forma apropiada y que la misma se encuentre disponible siempre que sea necesaria;
          CONSIDERANDO: 1º) que la Dirección de la División Tecnología de la Información, a fin de lograr estos cometidos, se ha abocado al desarrollo, implantación, mantenimiento y mejora continua de un Sistema de Gestión de la Seguridad de la Información;
          2º) que se deberán establecer los procedimientos a los efectos de asegurar que las debilidades y eventos de seguridad de la información asociados a sistemas de información de la Intendencia Municipal de Montevideo, sean comunicados para tomar acciones correctivas en tiempo y forma;
          3º) que el Director General del Departamento de Planificación se manifiesta de conformidad a lo informado, estimando procedente el dictado de Resolución al respecto;
          EL INTENDENTE MUNICIPAL DE MONTEVIDEO
          RESUELVE:
          1º. Determinar la siguiente política de Seguridad en la adquisición, desarrollo y mantenimiento de los sistemas de información, cuyo propósito es establecer los criterios que deben cumplir los procesos de adquisición, desarrollo y mantenimiento de los sistemas de información en la Intendencia Municipal de Montevideo (IMM), de forma de garantizar que la seguridad de la información sea parte integral de estos sistemas:
          a) Política:
          i) Análisis y especificación de los requerimientos de seguridad:
          i.1) Todos los requerimientos de seguridad deben ser identificados en las fases de análisis y especificación de requerimientos de cada proyecto, consensuados y documentados como parte del proceso global para un sistema de información, previo a la fase de desarrollo,
          i.2) A la hora de especificar los requerimientos de seguridad se deben considerar los controles automatizados y manuales de verificación, a ser incorporados al sistema de información,
          i.3) Los mismos criterios de seguridad deben ser aplicados para paquetes de software desarrollados o comprados,
          i.4) Los requerimientos de seguridad y control deben reflejar el valor del activo de información involucrado, y el daño potencial que podría ser resultado de una falla o ausencia de seguridad,
          i.5) Los requerimientos del sistema para la seguridad de la información y los procesos para poner en práctica los controles de seguridad deben ser integrados en las etapas tempranas de los proyectos de sistema de información,
          i.6) Si los productos son adquiridos, se debe seguir un proceso formal de pruebas previo a la aceptación de los mismos,
          i.7) Los contratos con el proveedor deben abordar los requerimientos de seguridad identificados,
          i.8) Cuando se suministra una funcionalidad adicional que causa un riesgo de seguridad, esta debería ser deshabilitada o la estructura de control propuesta debería ser revisada, para determinar si se puede obtener ventaja de la funcionalidad mejorada sin comprometer la seguridad del sistema,
          i.9) Los sistemas que procesan, o tienen impacto sobre, la información sensible, reservada, confidencial, secreta, valiosa o crítica, pueden requerir controles adicionales. Tales controles deben ser determinados sobre la base de requerimientos de seguridad y evaluación del riesgo,
          ii) Requerimientos para el funcionamiento correcto de las aplicaciones:
          ii.1) Se debe prevenir errores, pérdida, modificación no autorizada o uso inadecuado de información en aplicaciones,
          ii.2) Las aplicaciones deben contar con los controles apropiados, incluyendo la validación de datos de entrada, control del procesamiento interno y validación de datos de salida,
          ii.3) Los datos de entrada a las aplicaciones deben ser validados para asegurar que son correctos y apropiados. Para ello se debe considerar:
          1. Entradas duplicadas.
          2. Valores fuera de rango.
          3. Caracteres inválidos en campos de datos.
          4. Datos incompletos.
          5. Exceder límites superiores e inferiores de volumen de datos.
          6. Datos no autorizados o incoherentes.
          7. Respuesta a errores de validación,
          ii.4) Se debe considerar el uso de puntos únicos para la manipulación de los datos (agregar, modificar, y suprimir),
          ii.5) Cuando fuera aplicable se deben establecer procedimientos para prevenir programas que ejecuten en el orden incorrecto o luego del error de un proceso previo. Así como el empleo de programas apropiados para reponerse de errores y asegurar el tratamiento correcto de datos,
          ii.6) Se deben realizar controles que brinden protección contra amenazas de seguridad conocidas. Las mismas serán especificadas por el Área de Seguridad Informática,
          ii.7) Se debe comprobar la integridad, la autenticidad o cualquier otro rasgo de seguridad de datos o software transferido desde o hacia terceras partes incluyendo totales de verificación (hash) de registros y archivos,
          ii.8) La salida de los datos de una aplicación debe ser validada para asegurar que el procesamiento de la información es correcto, de acuerdo a los requerimientos especificados. El proceso de validación de los datos de salida puede incluir
          1. Validaciones de verosimilitud para comprobar si los datos de salida son razonables, vía muestras aleatorias,
          2. Controles de reconciliación para asegurar el procesamiento correcto de los datos,
          3. Procedimientos para responder a pruebas de validación de salida,
          ii.9) Se debe definir las responsabilidades de todo el personal implicado en el proceso de entrada y salida de datos o cualquier interacción con el sistema.
          iii) Control de software en producción:
          iii.1) La actualización en producción de aplicaciones y bibliotecas de programa sólo debe ser realizada por las áreas de Administración de Sistemas y Administración de Base de Datos,
          iii.2) Los sistemas en producción no deben tener funcionalidades en proceso de desarrollo y/o no aprobadas,
          iii.3) El software de aplicaciones y software de base sólo debe ser puesto en producción después de ser probado; se deben incluir pruebas sobre la funcionalidad, la seguridad, los efectos sobre otros sistemas y las facilidades de usuario, y deben ser realizadas en ambiente de pruebas,
          iii.4) Debe asegurarse que los entornos de producción y sus bibliotecas sean actualizados de forma coordinada con los entornos de prueba,
          iii.5) Deben separarse las bibliotecas de fuentes de producción y desarrollo,
          iii.6) Debe existir una estrategia de “vuelta atrás” antes de que los cambios sean implementados,
          iii.7) Los encargados de las actualizaciones deben mantener un registro de todos los pasajes de programas a producción,
          iii.8) Debe utilizarse un sistema de versionado para mantener el control del software implementado, archivos de configuración, así como la documentación de sistema,
          iii.9) Cualquier decisión de cambio a una nueva versión debería tener en cuenta, los requerimientos del negocio y de seguridad de la nueva versión. Los parches de software deben aplicarse cuando puedan ayudar a quitar o reducir debilidades de seguridad,
          iii.10) El acceso físico o lógico a la infraestructura y aplicaciones únicamente se debe dar a los proveedores para propósitos de soporte, cuando sea necesario, y con aprobación previa de la División,
          iii.11) Las actividades del proveedor deben ser supervisadas,
          iv) Protección de datos de prueba de sistemas:
          Se aplican las disposiciones establecidas en el articulo a.4 de la resolución Nº 66/10 de Política de Gestión de Operaciones.
          v) Control de acceso al código fuente de programas:
          v.1) El acceso al código fuente de programas y documentos asociados (como diseños, datos específicos, proyectos de verificación y proyectos de validación) debe ser controlado,
          v.2) El código fuente debe mantenerse en un almacenamiento centralizado y controlado. La herramienta de almacenamiento centralizado debe poseer funcionalidades de historial de cambios, que permitan una vuelta a estados anteriores del fuente y control de versión,
          v.3) El código de programas fuente y las bibliotecas de programas fuente deberían gestionarse según procedimientos establecidos,
          v.4) La modificación de códigos fuente sólo debe realizarse bajo supervisión de los Jefes de Desarrollo,
          v.5) Debería mantenerse un registro de las modificaciones a los códigos fuente.
          vi) Seguridad en los procesos de desarrollo y soporte:
          vi.1) Control de cambios:
          Se aplican las disposiciones establecidas en el articulo a.2 de la resolución Nº 66/10 de Política de Gestión de Operaciones.,
          vi.2) Revisión técnica de aplicaciones luego de cambios del software de base:
          1. Los controles de las aplicaciones deben ser revisados para asegurar que no han sido comprometidos por los cambios,
          2. Se debe prever en la planificación anual, los recursos para cubrir pruebas y revisiones de sistema resultantes de los cambios de software de base,
          3. Cuando no existan razones perentorias que lo impidan; la notificación de cambios al software de base debe ser realizada con suficiente antelación para permitir realizar pruebas y revisiones apropiadas antes de la puesta en producción,
          4.Se deberán revisar las vulnerabilidades, los parches y actualizaciones liberadas por los vendedores, para evaluar la necesidad de instalación de las mismas,
          vi.3) Restricciones sobre cambios a paquetes de software desarrollados por terceros:
          1. Cuando un paquete de software suministrado por un tercero necesite ser modificado se deben considerar los siguientes puntos:
          a. El riesgo de comprometer los procesos de control y de integridad existentes.
          b. Si se debe obtener o no el consentimiento del vendedor.
          c. El impacto ocasionado, si la organización se hace responsable por el futuro mantenimiento del software como consecuencia de los cambios.
          2. Se debe conservar el software original y los cambios deben ser aplicados a una copia claramente identificada,
          3. Todos los cambios deberían ser probados y documentados, de modo que ellos puedan ser vueltos a aplicar si fuera necesario a futuras mejoras de software,
          4. Las modificaciones deben ser probadas y validadas,
          vi.4) Desarrollo externo de software:
          1. El desarrollo externo de software debe ser supervisado y seguido por personal técnico capacitado de la División.
          2. Se deben establecer con el proveedor acuerdos de licencias, la propiedad del código, y derechos de propiedad intelectual
          3. Se deben establecer exigencias contractuales sobre la calidad y funcionalidades de seguridad del código.
          4. Se deben llevar a cabo pruebas antes de la instalación para detectar posibles vulnerabilidades de seguridad.
          5. Se deben cambiar las claves por defecto en los sistemas comprados a terceros, antes de ser puestos en producción.
          b) Roles y Responsabilidades:
          i) Todo el personal, independiente de su cargo o situación contractual, responsable de la adquisición, diseño, desarrollo, mantenimiento y operación de los sistemas de información de la IMM debe adherirse a esta política.
          ii) El área de Seguridad Informática será responsable de garantizar el cumplimiento de esta política.
          c) Definiciones:
          Sistemas de información: Los sistemas de información incluyen: la infraestructura, las aplicaciones de negocio y los servicios.
          Requerimientos de seguridad: Requisitos que deben cumplir los sistemas considerando las propiedades de seguridad como ser confidencialidad, integridad, disponibilidad, no repudio y trazabilidad.-
          2º. Establecer que el alcance de esta política aplica a todos los sistemas de información de la IMM, incluyendo los ubicados en el Palacio Municipal y sitios externos. La misma comprende los sistemas existentes y futuros.
          3º. Establecer que la Política de Seguridad en la adquisición, desarrollo y mantenimiento de los sistemas de información, deberá ser revisada anualmente a efectos de evaluar su implantación y modificación cuando así se requiera, a efectos del eficaz cumplimiento de sus objetivos.-
          4º. Encomendar a la Asesoría Jurídica, la realización de los procedimientos pertinentes a los efectos de su incorporación al Digesto Municipal.-
          5º. Comuníquese a Secretaría General; Asesoría Jurídica; a todos los Departamentos y pase a la División Tecnología de la Información.-
RICARDO EHRLICH, Intendente Municipal.-
ALEJANDRO ZAVALA, Secretario General.-