Establecer 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 de Montevideo (IM), 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:
Deberá elaborarse una ficha técnica que deberá incluir información de la arquitectura utilizada, software de aplicación, accesos de red necesarios y deberá seguir un procedimiento de autorización.
i.1) Los requerimientos de seguridad deben ser identificados en las fases de análisis y especificación 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 un a 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, ésta debe ser deshabilitada o la estructura de control propuesta debe 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 datos sensibles, información reservada, confidencial o secreta, pueden requerir controles adicionales. Tales controles deben ser determinados sobre la base de requerimientos de seguridad y evaluación del riesgo,
i.10) Previo al acceso será requerimiento la firma de un Compromiso de confidencialidad y responsabilidad sobre actuaciones realizadas con el usuario o conexiones establecidas,
i.11) Las actividades del proveedor deben ser supervisadas,
i.12) Deberán establecerse acuerdos a nivel de servicio (SLA) para aquellos casos que el soporte sea sobre los componentes críticos de la infraestructura.

ii) Requerimientos para el funcionamiento correcto de las aplicaciones:
ii.1) Se deben 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:

• Entradas duplicadas
• Valores fuera de rango
• Caracteres inválidos en campos de datos
• Datos incompletos
• Exceder límites superiores e inferiores de volumen de datos
• Datos no autorizados o incoherentes
• 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:

• Validaciones de verosimilitud para comprobar si los datos de salida son razonables, vía muestras aleatorias,
• Controles de reconciliación para asegurar el procesamiento correcto de los datos,
• Procedimientos para responder a pruebas de validación de salida,

ii.9) Se deben definir las responsabilidades de todo el personal implicado en el proceso de entrada y salida de datos o cualquier interacción con el sistema,
ii.10) Previo a la puesta en producción de una nueva aplicación o modificación de aplicaciones existentes se debe notificar el área de Seguridad Informática a los efectos de realizar los análisis de seguridad adecuados y determinar qué protecciones adicionales deberán aplicarse a la misma,
ii.11) Las aplicaciones deberán utilizar mecanismos de cifrado seguro (que no tengan problemas de seguridad reportados) de forma de proteger el tráfico.

iii) Control de software en producción:
iii.1) La actualización en producción de aplicaciones y biblioteca de programa sólo debe ser realizada por las áreas de Administración de Sistemas y Administración de Base de Datos o autorizada por las mismas,
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 debe 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) Se evaluarán periódicamente los sistemas y aplicaciones en forma manual o mediante herramientas automáticas. Se revisarán las publicaciones de nuevas vulnerabilidades descubiertas que puedan afectar las mismas. Deberá darse prioridad a la corrección de los mismos, habilitando incluso la baja temporal de los servicios vulnerables como medida de protección en caso de que los sistemas expuestos puedan ser comprometidos en cuanto a su integridad, disponibilidad o confidencialidad.

iv) Protección de datos de pruebas de sistemas:
Se aplican las disposiciones establecidas en el literal a.4 del artículo R.418.21 del presente Capítulo. de la Sección IV "De la 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 de fuente y control de versión,
v.3) El código de programas fuente y las bibliotecas de programas fuente debe 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) Debe 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 literal b) del artículo R.418.21 del presente Capítulo, Sección IV "De la 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 deben ser probados y documentados, de modo que ellos puedan ser vueltos a aplicar si fuera necesairo 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 del Departamento,
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) 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.

c) Roles y Responsabilidades
i. Todo el personal, independientemente 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 Intendencia de Montevideo debe adherirse a esta política,
ii. El área de Seguridad Informática es responsable de asegurar su cumplimiento,
iii. Es responsabilidad de las Gerencias de Tecnología de la Información y Tecnología para Ciudades Inteligentes, la correcta implementación de esta política.