VISTO: la necesidad de realizar cambios en la normativa que respecta a las Políticas de Seguridad de la Información;

                         RESULTANDO: 1) que la Unidad de Seguridad Informática, ha solicitado cambios respecto a las Políticas de Seguridad de la Información, con la finalidad de actualizar la normativa vigente;

2) que en virtud de dicha actualización, se deben dejar sin efectos las Resoluciones Nº64/10, 65/10, 66/10, 67/10, de fecha 04 de enero de 2010; 641/10 y 642/10, de fecha 22 de febrero de 2010; 814/10, de fecha 02 de marzo de 2010 y 835/10, de fecha 27 de febrero de 2012;

3) que estos cambios tienen como objetivo principal estar alineados a los objetivos del Departamento de Desarrollo Sostenible e Inteligente;

4) que la Unidad Asesoría no tiene objeciones con las modificaciones propuestas y procede a realizar modificaciones en el texto por cuestiones de técnica legislativa;

                         CONSIDERANDO: que el Departamento de Desarrollo Sostenible e Inteligente y la División Asesoría Jurídica manifiestan su conformidad y estiman procedente el dictado de resolución en el sentido indicado;

LA INTENDENTA DE MONTEVIDEO

RESUELVE:

1º.- Dejar sin efecto las Resoluciones Nro. 64/10, 65/10, 66/10, 67/10, de fecha 04 de enero de 2010; 641/10 y 642/10, de fecha 22 de febrero de 2010; 814/10, de fecha 02 de marzo de 2010 y 835/12, de fecha 27 de febrero de 2012 ;

2º.- Sustituir el artículo R.418.17 de la Sección II "De la política de actualización de hardware y ambientes", Capítulo XVIII.3 "Del Sistema de Gestión de la Seguridad de la Información", Título Único, Parte Reglamentaria, Libro III "De la relación funcional", Volumen III "Relación Funcional", del Digesto Departamental, en la redacción dada por el numeral 1 de la Resolución Nro. 64/10, de fecha  04 de enero de 2010, el que quedará redactado de la siguiente manera:

"Artículo R.418.17.- Establecer la siguiente Política de Actualización de Hardware y Software:

a) Actualizar los componentes de la plataforma operativa según una política de reemplazo de equipamiento con un máximo de 3 (tres) años;

b) Se deberá conformar un equipo de trabajo a tales efectos, integrado por un representante de la Gerencia de Tecnología de la Información y Tecnología para Ciudades Inteligentes, que reportará anualmente a la Dirección la lista de componentes críticas que tengan más de 3 (tres) años, así como su estado de actualización tecnológica y el plan de reemplazo de los mismos;

c) Revisar periódicamente la existencia de actualizaciones y parches en el software de base y aplicaciones de forma de evitar la obsolescencia del mismo, corregir configuraciones o vulnerabilidades reportadas. La obtención de las actualizaciones debe realizarse de fuentes confiables y verificarse la integridad del software descargado. El procedimiento para aplicar las actualizaciones y parches debe ser realizado en forma controlada y con la posibilidad de revertir el estado anterior;

d) El Departamento de Desarrollo Sostenible e Inteligente será el encargado de evaluar, planificar e instrumentar las actualizaciones de los componentes de hardware y software;

e) El Departamento de Desarrollo Sostenible e Inteligente, definirá la estrategia de actualización y seleccionará los componentes sustitutos, garantizando que los mimos satisfacen las cualidades requeridas por los sistemas informáticos de la Intendencia de Montevideo;

f) Los componentes sustitutos serán probados previo a su instalación para evaluar el impacto de su aplicación y garantizar su funcionalidad y eficacia;

g) Se deberá proveer de la infraestructura de hardware y software necesario para realizar las pruebas previo a la aplicación de los cambios;

h) Roles y responsabilidades;

i. el área de Seguridad Informática es responsable de asegurar su cumplimiento;

ii. 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;

3º.- Sustituir el artículo R.418.18 de la Sección II "De la política de actualización de hardware y ambientes", Capítulo XVIII.3 "Del Sistema de Gestión de la Seguridad de la Información", Título único, Parte Reglamentaria. Libro III "De la relación funcional", Volumen III "Relación Funcional", de Digesto Departamental, en la redacción dada por el numeral 2 de la Resolución Nro. 64/10, de fecha 04 de enero de 2010, el que quedará redactado de la siguiente manera:

"Artículo R.418.18.-Establecer que la Política de Actualización de Hardware y Software deberá ser revisada cuando ocurran cambios significativos (técnicos, normativo, negocio) o al menos cada tres años para evaluar su implantación y modificación cuando así se requiera, a efectos de eficaz cumplimiento de sus objetivos.

4º.- Sustituir el artículo R.418.19 de la Sección II "De la política de Seguridad Física y del Ambiente", Capítulo XVIII.3 "Del Sistema de Gestión de la Seguridad de la Información", Título único, Parte Reglamentaria. Libro III "De la relación funcional", Volumen III "Relación Funcional", de Digesto Departamental, en la redacción dada por el numeral 1 de la Resolución Nro. 65/10, de fecha 04 de enero de 2010, el que quedará redactado de la siguiente manera:

 "Artículo R.418.19.- Establecer la siguiente Política de Seguridad Física y del Ambiente de las áreas físicas donde el Departamento de Desarrollo Sostenible e Inteligente procese información o manipule equipamiento informático, con el objetivo de evitar accesos físicos no autorizados, daños e interferencias a las instalaciones y a la información:

a) Definir como áreas seguras aquellas instalaciones de procesamiento de la información crítica para la operativa de la Organización o que requieran un tratamiento particular para preservar su clasificación de secreta, reservada o confidencial. Esto incluye pero no está limitado a; centro de cómputos. sala de servidores, centros de producción o procesamiento informático;

b) Perímetro de seguridad física:

i. las paredes del perímetro de las áreas seguras deben ser de techo a piso y deberán tener solidez física,

ii. todas las puertas y ventanas del perímetro deberán estar protegidas contra accesos no autorizados,

iii. las áreas seguras deben ubicarse de forma de evitar el acceso público,

c) Controles de acceso físico:

i. el acceso a las áreas seguras se debe limitar a personas con razones válidas para su ingreso,

ii. las áreas seguras son áreas restringidas a las que no deben ingresar personal sin acceso supervisado,

iii. se deberá contar con un área de recepción atendida por personal a los efectos de controlar el acceso a las áreas seguras,

iv. las salidas de emergencia de incendio de las áreas seguras, deberán permanecer trancadas por dentro, evitando el ingreso, y despejadas, permitiendo la salida fácil en caso de evacuación.

v. se debe contar con información que identifique el centro de cómputos, las salas de servidores o cualquier otra área segura, que no debe estar disponible al público.

d) Control de acceso físico a salas de servidores:

i. las puertas de las salas de servidores deben contar con dispositivos de control de acceso mediante huella digital para autorizar el acceso,

ii. tiene autorizado el ingreso, las áreas de ADMINISTRACIÓN DE SISTEMAS , BASE DE DATOS, OPERACIONES, SEGURIDAD Y TELECOMUNICACIONES,

iii. se deberá mantener registros de acceso, en lo que se indique identificación de la persona, fecha y hora de entrada. Estos registros deberán mantenerse por un plazo mínimo de un año,

iv. el ingreso de personal de soporte de terceras partes será autorizado cuando sea requerido. Los mismos deberán estar acompañados por personal de las áreas autorizadas al ingreso. En caso que el trabajo a realizar justifique que los mismos ingresen en forma independiente, se le entregará una tarjeta de acceso individual. Para la entrega de la tarjeta de acceso, se deberá presentar un documento de identidad. Personal de Operaciones gestionará este tipo de acceso, registrando el nombre de la persona, empresa, persona que autorizó el ingreso, fecha y hora de entrega de la tarjeta, fecha y hora de devolución. La persona deberá firmar el registro al retirar la tarjeta y al momento de su devolución,

v. los derechos de acceso deben ser revisados y actualizados semestralmente y serán revocados cuando sea necesario,

vi. se deben utilizar sistemas de circuito cerrado de TV para monitorear el acceso a las salas de servidores y sus proximidades,

vii. las salas de servidores deben ser supervisadas 24 horas al día,

viii. las puertas de acceso deben contar con sistemas que aseguren su cierre automático y contar con alarma audible que permita avisar si la puerta permanece abierta por más de 30 (treinta) segundos.

e) Protección contra amenazas externas y del ambiente:

i. dentro de las salas de servidores y la sala de alimentación de energía, debe instalarse un sistema de detección y extinción de incendios. Dicho sistema deberá ser inspeccionado anualmente para garantizar su buen funcionamiento,

ii. se deberá coordinar con personal de Dirección Nacional de Bomberos los procedimientos en caso de incendio,

iii. no se deben almacenar materiales combustibles o peligrosos dentro de las salas de servidores ni en sus proximidades,

iv. se deben controlar las condiciones ambientales como temperatura y humedad, para verificar que no afecte el funcionamiento del equipamiento,

v. debe existir un mantenimiento regular del equipamiento de soporte (aire acondicionado, sistema de extinción de incendio, tableros eléctricos, UPS, etc),

vi. el equipamiento que se encuentra dentro de las salas debe estar conectado a una fuente de energía ininterrumpida (UPS) y las mismas deben ser conectadas a generadores que provean energía en caso de que el corte sea prolongado. Las UPS deben proveer energía por un tiempo suficiente para el apagado normal de los equipos,

vii. el generador y las UPS deben inspeccionarse regularmente para asegurar la capacidad y funcionamiento,

viii. todo el equipamiento crítico deberá contar con dos fuentes de energía, alimentadas desde diferentes orígenes,

ix. se debe proveer de iluminación de emergencia,

x. se debe proveer servicios telefónicos para casos de comunicaciones de emergencia,

xi. previo a la instalación de nuevo equipamiento dentro de las salas de servidores, personal de operaciones deberá asegurar que existe capacidad en los racks, eléctrica yrefrigeración.

f) Trabajo en las áreas seguras:

i. se debe evitar el trabajo no supervisado en áreas seguras,

ii. no debe permitirse la presencia de equipos de fotografía, video, audio u otras formas de registro, a menos que la misma esté expresamente autorizada,

iii. no se debe comer ni beber en las salas de servidores.

g) Seguridad en el cableado:

i. dentro de las salas de servidores, las líneas de energía y telecomunicaciones deben tenderse en canalizaciones adecuadas, por debajo del piso falso,

ii. las líneas de energía deben estar separadas de los cables de comunicaciones para evitar interferencias,

iii. el equipamiento y el cableado debe estar claramente identificado para reducir al mínimo los errores,

iv. para los sistemas críticos se deberá utilizar cableado redundante,

v. se deben realizar inspecciones periódicas para evitar la conexión de dispositivos no autorizados,

vi. se deben colocar controles para evitar el acceso no autorizado a los gabinetes de equipamiento.

h) Mantenimiento del equipo:

i. todo el equipamiento crítico debe contar con mantenimiento,

ii. sólo personal de mantenimiento debidamente autorizado debe realizar reparaciones y mantenimiento en los equipos,

iii. se debe mantener registro de todos los fallos, reales o sospechosos y de los mantenimientos preventivos y correctivos,

iv. debe cumplirse con los requisitos impuestos por pólizas de seguro,

v. el equipamiento crítico de las salas de servidores deberá estar asegurado.

i) Alojamiento externo:

En caso de utilizar servicios contratados de alojamiento físico de equipamiento, el proveedor deberá cumplir con las condiciones detalladas anteriormente y deberá estar sujeto a los controles correspondientes.

j) Retiro de bienes:

i. el equipamiento, la información o el software no deben ser retirados de la Organización sin previa autorización,

ii. las personas habilitadas para autorizar el retiro son aquellas registradas por Servicios Internos.

k) Roles y responsabilidades:

i. el personal de las Gerencias de Tecnología de la Información y Tecnología para Ciudades Inteligentes es responsable de acompañar a todos los visitantes, vendedores, personal de soporte y otras personas no autorizadas, al ingreso a las áreas seguras,

ii. el personal de Operaciones es responsable por el acceso de personal no autorizado a las salas de servidores,

iii. el área de Seguridad Informática es responsable de asegurar su cumplimiento.

5º.- Sustituir el artículo R.418.20 de la Sección II "De la política de actualización de hardware y ambientes", Capítulo XVIII.3 "Del Sistema de Gestión de la Seguridad de la Información", Título único, Parte Reglamentaria. Libro III "De la relación funcional", Volumen III "Relación Funcional", de Digesto Departamental, en la redacción dada por el numeral 2 de la Resolución Nro. 65/10, de fecha 04 de enero de 2010, el que quedará redactado de la siguiente manera:

 "Artículo R.418.20.-Establecer que la Política de Seguridad Física y del Ambiente deberá ser revisada cuando ocurran cambios significativos (técnicos, normativo, negocio) o al menos cada tres años para evaluar su implantación y modificada cuando así se requiera, a efectos de eficaz cumplimiento de sus objetivos.

6º.- Sustituir el artículo R.418.21 de la Sección IV "De la política de gestión de operaciones", Capítulo XVIII.3 "Del Sistema de Gestión de la Seguridad de la Información", Título único, Parte Reglamentaria. Libro III "De la relación funcional", Volumen III "Relación Funcional", de Digesto Departamental, en la redacción dada por el numeral 1 de la Resolución Nro. 66/10, de fecha 04 de enero de 2010, el que quedará redactado de la siguiente manera:

"Artículo R.418.21.-Establecer que la Política de Gestión de Operaciones, cuyo objetivo es asegurar la operación correcta y segura de las instalaciones de procesamiento de información, siendo el alcance de todas las instalaciones donde el Departamento de Desarrollo Sostenible e Inteligente procese información, abarcando los pasos previos a la puesta en producción de un servicio o sistema, su puesta en producción y su operación posterior.

Se deben establecer las responsabilidades y los procedimientos para la gestión y operación de las instalaciones de procesamiento de información.

a) Procedimientos documentados de operación:

i. Los procedimientos de operación deben documentarse, mantenerse actualizados y ponerse a disposición de los usuarios que los necesiten.

ii. Estos procedimientos deben especificar las instrucciones necesarias para la ejecución detallada de cada tarea.

iii. Se debe incluir en la documentación información de contacto para los casos en que se presenten dificultades.

iv. Estos procedimientos deben incluir pero no limitarse a :

• procesamiento y utilización de información
• respaldo
• interdependencia, tiempos de comienzo y finalización de tareas programables
• manejo de errores o condiciones de excepción presentados durante la ejecución de una tarea
• reinicio, recuperación, verificación y validación de sistema en caso de falla

v. Los documentos de procedimientos y sus cambios deben estar debidamente aprobados por las direcciones de las áreas involucradas.

b) Gestión de cambios:

i. Deben controlarse los cambios en los sistemas operacionales, software en producción e instalaciones de procesamiento de información.

ii. Para el control de cambios debe considerarse:

• identificación y registro de los cambios significativos
• planificación y pruebas de los cambios
• evaluación de impactos potenciales, incluyendo impactos a la seguridad
• comunicaciones de los detalles del cambio a las personas involucradas
• procedimientos de vuelta atrás para abortar y recuperar los cambios sin éxito

iii. Los cambios significativos que puedan tener gran impacto en la disponibilidad, confidencialidad o integridad de los sistemas deben ser aprobados por la Dirección de la Gerencia correspondiente.

iv. En caso que se necesiten realizar cambios de emergencia, los mismos deben ser documentados y aprobados dentro de las 24 horas de resuelto el problema.

v. Se deben realizar los respaldos correspondientes a configuraciones, tablas, software, etc, previo a la realización del cambio.

vi. La introducción de nuevos sistemas y cambios mayores a sistemas existentes debe seguir un proceso formal de documentación, especificación, pruebas, control de calidad y gestión de implementación. Este proceso debe incluir una evaluación de riesgo, el análisis de los impactos de cambios y la especificación de los controles de seguridad necesarios. Este proceso también debe asegurar que los procedimientos existentes de seguridad y control no sean comprometidos.

vii. Los cambios deben efectuarse por usuarios autorizados.

viii. Identificar todo el software, la información, entidades de base de datos y el hardware que pudieran requerir enmienda.

ix. Se debe informar en lo posible a los usuarios afectados antes de la implementación de los cambios.

x. Se debe informar internamente a los directores de las áreas del Departamento de Desarrollo Sostenible e Inteligente involucradas, Mesa de Servicios y Operaciones, con anterioridad al cambio.

xi. Se debe asegurar que al terminar cada cambio, la documentación de sistema sea actualizada y que la vieja documentación sea archivada o eliminada.

xii. Cuando la naturaleza del cambio lo permite se debe mantener un respaldo de la versión anterior al cambio.

xiii. La documentación de operaciones y los procedimientos de usuario, deben ser cambiados según sea necesario para que se mantengan actualizados.

xiv. La implementación de cambios, debe ocurrir en el momento adecuado y no interferir en lo posible con los procesos de negocio implicados.

c) Segregación de tareas:

i. Se deberán segregar las tareas y áreas de responsabilidad para reducir las oportunidades de modificación no autorizada o no intencional, o el uso inadecuado de los activos.

ii. Las siguientes áreas de actividad se definirán y serán desarrolladas por grupos/personal diferente:

• Aplicaciones
• Análisis de Procesos Informáticos
• Administración de Sistemas
• Administración de base de datos
• Operaciones
• Mesa de Servicios
• Telecomunicaciones
• Arquitectura y Testing
• Seguridad informática

d) Separación de entornos para desarrollo, prueba y producción.

i. Los entornos para desarrollo, prueba y producción deben separarse para reducir el riesgo no autorizado o cambios en el sistema de operación.

ii. Deben definirse y documentarse los procedimientos para el pasaje de software en ambiente de desarrollo a producción.

iii. El ambiente de pruebas debe emular el ambiente de producción tanto como sea posible.

iv. Los usuarios deben utilizar perfiles diferentes para los sistemas en producción o prueba y se deben exhibir mensajes de identificación para reducir el riesgo de errores.

v. No se debe utilizar información clasificada como confidencial, secreta o reservada en ambientes de desarrollo o prueba.

vi. Los datos de prueba deberán ser seleccionados cuidadosamente, protegidos y controlados.

vii. Para hacer pruebas debe ser evitado el empleo de base de datos de producción o copias de las mismas.

viii. En caso de utilizar información personal o cualquier otra información clasificada como confidencial, reservada o secreta para hacer pruebas, dicho contenido debe ser eliminado o modificado (ofuscado), evitando su reconocimiento, antes del empleo.

ix. Los procedimientos de control de acceso, que se aplican a sistemas en producción, deberán aplicarse también a los sistemas de prueba de aplicaciones.

x. El área de Seguridad debe autorizar cada vez que se copie la información de producción a otro sistema para pruebas.

xi. Debe borrarse la información de producción de un sistema de prueba inmediatamente después de que las pruebas son completadas.

xii. Debe registrarse la copia y el empleo de información de producción para proporcionar una pista de auditoría.

e) Gestión de capacidad.

i. Cada actividad nueva y en curso debe identificar los requisitos de capacidad.

ii. Todos los sistemas deben planificar con anticipación los requerimientos de capacidad y realizar un seguimiento de la capacidad de los sistemas.

iii. Los requisitos de capacidad a verificar incluyen, pero no están limitados a:

• espacio de almacenamiento
• tráfico de red
• poder de procesamiento
• balanceo de carga
• requerimientos de memoria

Los requerimientos anteriores deben ser evaluados tanto en el centro de cómputos principal como en el de contingencia, para aquellos servicios en los que se requiera alta disponibilidad.

iv. Los requisitos de capacidad física para la instalación de nuevo equipamiento a verificar, incluyen pero no están limitados a:

• espacio físico para instalar nuevos servidores o dispositivos de forma adecuada
• potencia eléctrica cubierta por las UPS para alimentarlos dentro de los márgenes de seguridad recomendados por el fabricante para no incurrir en sobrecarga de las mismas
• capacidad de acondicionamiento térmico
• disponibilidad de conexiones de red
• disponibilidad de conexiones de red duales para los casos en que el servicio brindado por el nuevo equipamiento, deba tener características de alta disponibilidad.

f) Gestión de entrega de servicio por terceras partes.

i. Deben verificarse los controles de seguridad y definiciones de servicio incluidos en los acuerdos de entrega de servicios por terceras partes.

ii. Deben supervisarse regularmente los servicios proporcionados por terceras partes y realizarse auditorías regulares de los mismos, para verificar el cumplimiento de los niveles acordados.

iii. El acceso físico o lógico a la infraestructura y aplicaciones únicamente se debe dar a los proveedores para propósito de soporte, cuando sea necesario, y con aprobación de la dirección.

iv. Las actividades del proveedor deben ser supervisadas.

v. Se deben incluir acuerdos de confidencialidad en los contratos de servicio de terceras partes.

g)Aceptación del sistema.

i. Se deben establecer los criterios de aceptación para nuevos sistemas, actualizaciones y nuevas versiones. Las pruebas y controles deben tener en cuenta:

• requisitos de rendimiento y capacidad
• procedimientos de recuperación de errores y reinicio
• planes de contingencia
• metodologías y procedimientos de prueba
• controles y medidas de seguridad instalados
• evaluación de impacto en sistemas e infraestructura existente
• capacitación al área de operaciones y soporte a usuarios

h) Respaldo.

i. Deben realizarse regularmente respaldos de la información y del software y probarse regularmente de acuerdo a la política de respaldo.

i) Documentación de sistemas.

i. La documentación de sistemas que contengan información clasificada como secreta, reservada o confidencial, debe almacenarse en forma segura y tener restringido su acceso.

j) Roles y responsabilidades.

i. El área de Seguridad Informática es responsable de asegurar su cumplimiento.

ii. 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.

7º.- Sustituir el artículo R.418.22 de la Sección IV "De la política de Gestión de Operaciones", Capítulo XVIII.3 "Del Sistema de Gestión de la Seguridad de la Información", Título único, Parte Reglamentaria. Libro III "De la relación funcional", Volumen III "Relación Funcional", de Digesto Departamental, en la redacción dada por el numeral 2 de la Resolución Nro. 66/10, de fecha 04 de enero de 2010, el que quedará redactado de la siguiente manera:

"Artículo R.418.22.-Establecer que la Política de Gestión de Operaciones deberá ser revisada cuando ocurran cambios significativos (técnicos, normativo, negocio) o al menos cada tres años para evaluar su implantación y modificación cuando así se requiera, a efectos de eficaz cumplimiento de sus objetivos.

8º.- Sustituir el artículo R.418.23 de la Sección V "De la política de antivirus", Capítulo XVIII.3 "Del Sistema de Gestión de la Seguridad de la Información", Título único, Parte Reglamentaria. Libro III "De la relación funcional", Volumen III "Relación Funcional", de Digesto Departamental, en la redacción dada por el numeral 1 de la Resolución Nro. 67/10, de fecha 04 de enero de 2010, el que quedará redactado de la siguiente manera: 

 "Artículo R.418.23.-Establecer la siguiente Política de protección de puestos de trabajo, a los efectos de establecer los requerimientos que deben cumplir todas las computadoras conectadas a la red de la Intendencia de Montevideo (IM) de forma de garantizar la detección y prevención de cualquier tipo de código malicioso (virus, troyanos, etc.). El alcance será de aplicación a todos los puestos de trabajo conectados a la red de la Intendencia de Montevideo, incluyendo los ubicados en el edificio sede, sitios externos y VPN, comprendiendo los equipos existentes y los futuros:

a) Política

i. Todas las computadoras conectadas a la red de la Intendencia de Montevideo deben tener instalado el antivirus estándar soportado.

ii. Las computadoras que no tengan instalado el producto antivirus estándar soportado serán desconectadas de la red o conectadas a la subred de visitantes en la cual tendrán accesos restringido.

iii. Nadie podrá desinstalar ni detener la ejecución del programa antivirus, verificaciones de virus o actualizaciones, salvo los administradores en tareas de soporte.

iv. El producto antivirus será configurado para una protección en tiempo real.

v. Las definiciones de virus serán actualizadas como mínimo una vez por día.

vi. Se realizarán verificaciones de virus automáticas, en todas las computadoras y servidores, como mínimo una vez por mes.

vii. Las computadoras infectadas podrán ser desconectadas de la red hasta que se verifique que están libres de virus.

viii. Los mensajes de correo de tipo spam (no solicitados) que representan un riesgo para la seguridad de los equipos o usuarios, serán eliminados por un sistema automático previamente al ingreso de los mismos. Deberá mantenerse un registro resumen de los mensajes eliminados.

b) Roles y responsabilidades.

i. Todos los usuarios de computadoras conectadas a la red de la Intendencia de Montevideo son responsables de minimizar el riesgo de infección de estas computadoras u otros sistemas o archivos, por el incumplimiento de las políticas establecidas y el seguimiento de las recomendaciones.

ii. El área de Seguridad Informática es responsable de asegurar su cumplimiento.

iii. Es responsabilidad de la Gerencia de Tecnología de la Información la correcta implementación de esta política.

c) Definiciones.

i. Código Malicioso / Malware (software malicioso): hardware, firmware o software que es incluido o insertado intencionalmente en un sistema con el propósito de provocar daño.

ii. Virus: un programa de de computadora auto-extraíble que se propaga infectando otros programas, por ejemplo, insertando una copia de sí mismo.

iii. Troyanos: un programa de computadora que parece tener una función útil, pero oculta una potencial funcionalidad que evade mecanismos de seguridad.

iv. Antivirus: programas de computadora que intentan identificar, neutralizar o eliminar software malicioso (Malware).

v. Spam: envío indiscriminado de correo no solicitado, no deseado, irrelevante inapropiado o potencialmente peligroso.

9º.- Sustituir el artículo R.418.24 de la Sección V "De la política de antivirus", Capítulo XVIII.3 "Del Sistema de Gestión de la Seguridad de la Información", Título único, Parte Reglamentaria. Libro III "De la relación funcional", Volumen III "Relación Funcional", de Digesto Departamental, en la redacción dada por el numeral 2 de la Resolución Nro. 67/10, de fecha 04 de enero de 2010, el que quedará redactado de la siguiente manera: 

 "Artículo R.418.24.-Establecer que la Política de protección de puestos de trabajo, deberá ser revisada cuando ocurran cambios significativos (técnicos, normativo, negocio) o al menos cada tres años para evaluar su implantación y modificada cuando así se requiera, a efectos de eficaz cumplimiento de sus objetivos.

10º.- Sustituir el artículo R.418.25 de la Sección VI "De la política de control de acceso de usuarios", Capítulo XVIII.3 "Del Sistema de Gestión de la Seguridad de la Información", Título único, Parte Reglamentaria. Libro III "De la relación funcional", Volumen III "Relación Funcional", de Digesto Departamental, en la redacción dada por el numeral 1 de la Resolución Nro. 68/10, de fecha 04 de enero de 2010, el que quedará redactado de la siguiente manera: 

 "Artículo R.418.25.-Establecer la siguiente Política de Control de Acceso de Usuarios a los efectos de garantizar el acceso de usuarios autorizados y prevenir el acceso no autorizado a los sistemas informáticos:

a) Gestión de acceso de usuarios

a.1) Registro de usuarios

i. Debe existir un procedimiento claro para las altas y bajas de permisos de acceso a los usuarios.

ii. Todo usuario debe tener una identificación única que permita asociarlo con sus acciones.

iii. Los permisos a otorgar a cada usuario deberán ser aprobados por un supervisor responsable con la justificación adecuada. Dicha aprobación debe estar debidamente documentada.

iv. El nivel de acceso otorgado debe estar acorde con el principio de mínimo privilegio, siendo éste el mínimo necesario para cumplir con las actividades asociadas a su tarea dentro de la Organización.

v. Se deben modificar o revocar inmediatamente los permisos de acceso de usuarios que cambian de roles o dejan la Organización.

a.2) Gestión de privilegios

i. La definición de Roles o Permisos y la administración de acceso a los sistemas será responsabilidad de los administradores de cada sistema.

ii. Asignar a los usuarios un rol o permiso dentro de los que tiene definido cada sistema, que les habilite las posibilidades de realizar acciones en el mismo.

iii. Están habilitados a solicitar la asignación de roles o permisos a los nuevos usuarios, los Directores de Departamento, División o Servicio, los que deberán indicar para cuál de éstos se solicita acceso.

iv. Es responsabilidad de los Directores de Departamento, División o Servicio informar cuando un usuario ya no puede tener más acceso a la red o a un rol en particular.

v. Debe existir un proceso de autorización y registro de los privilegios otorgados a usuarios. Los privilegios deben otorgarse a una vez finalizado el proceso de autorización.

a.3) Gestión de contraseñas

i. Para trabajar en los Sistemas Informáticos de la Intendencia de Montevideo es necesario tener un usuario y su correspondiente contraseña que solamente conoce cada persona,

ii. Constituirá falta grave la divulgación de la contraseña, aunque ésta no llegase a ser utilizada,

iii. La contraseña debe tener una vigencia máxima de un año. En caso que el usuario omita realizar este cambio u olvide su contraseña solicitará la asignación de una nueva contraseña temporal.

iv. La contraseña debe tener un mínimo de 8 (ocho) caracteres y debe ser el resultado de una combinación alfanumérica, incluir mayúsculas, minúsculas, no contener secuencias numéricas o de teclado, nombre, apellido o número de cédula del titular.

v. Se dará a los usuarios inicialmente, una contraseña segura temporal para el ingreso a los sistemas, la cual deben cambiar inmediatamente.

vi. Las contraseñas temporales deben ser únicas para cada usuario y generadas en forma aleatoria.

vii. Las contraseñas temporales serán entregadas en forma segura, se debe evitar el uso del correo electrónico que no sea el corporativo o no protegidos (texto claro).

viii. Para el cambio de contraseña se debe solicitar a la persona una identificación que permita verificar la identidad de la misma.

ix. Los usuarios deben acusar el recibo de la entrega de la contraseña.

x. En todo sistema de autenticación, que lo permita, se debe verificar automáticamente el vencimiento del plazo para el cambio de contraseña, el largo, la repetición y la no trivialidad de la misma.

xi. Para aquellos sistemas que se consideren críticos o habiliten el acceso a información clasificada como secreta, reservada o confidencial, podrá requerirse el uso de mecanismos adicionales para el acceso, como ser un segundo factor de autenticación.

xii. Para los accesos remotos de usuarios se requerirá un segundo factor de autenticación.

a.4) Revisión de permisos de acceso

i. Cada 6 (seis) meses, se deben bloquear las cuentas de usuario que no fueron accedidas durante este período.

ii. Se bloquearán los accesos una vez finalizada la relación de empleo de los usuarios.

iii. Los permisos de acceso deben ser revisados y reasignados cuando se modifica la condición laboral del usuario, por ejemplo una promoción, degradación o terminación de empleo.

iv. Se mantendrá registro de los intentos de acceso fallido, a sistemas considerados críticos.

v. Constituirá falta grave el intento de obtener accesos no autorizados.

a.5) Autorizaciones de accesos a datos de actuaciones de terceros

El acceso a datos referentes a las actuaciones de terceros, como ser: información acerca de archivos borrados o modificados, accesos a aplicaciones o internet, información de listas de correo, marcas de reloj horario/control de acceso, etc. requiere ser autorizado por el Director de Departamento, División o Servicio correspondiente.

a.6) Autorizaciones de acceso a información de cuentas de correo y/o documentos en carpetas personales de terceros

Dichas solicitudes deben contar con el "consentimiento expreso del titular" o en su defecto ser autorizadas por la División de Asesoría Jurídica.

a.7) Eliminación de contenido de cuentas y documentos personales de usuarios que finalizaron su relación laboral

Determinar a dos años, el plazo de retención de correos y documentos en carpetas personales de usuarios que hayan finalizado se relación laboral con la Organización, luego del cuál los mismos podrán ser eliminados definitivamente.

b) Responsabilidades del usuario

b.1) Uso de contraseña: los usuarios son responsables de:

i. Mantener la confidencialidad de la contraseña.

ii. Evitar registrar las contraseñas en papel o archivos de forma no segura.

iii. Cambiar las contraseñas en el período establecido.

iv. Evitar el uso de contraseñas ya utilizadas anteriormente.

v. Cambiar las contraseñas temporales en la primer conexión.

vi. No utilizar la misma contraseña que utiliza para propósitos particulares.

vii. Seleccionar contraseñas que:

• Sean fáciles de recordar
• No pueden ser adivinadas fácilmente, conteniendo información relacionada a la persona, por ejemplo nombres, números telefónicos, fechas
• Mantengan el largo mínimo establecido
• No sean palabras incluidas en diccionarios
• Sean alfanuméricas
• No contengan caracteres idénticos sucesivos

viii. No ingresar nombre de usuario o contraseña en sitios web que no hayan sido validados como los institucionales o enviarlos en correos electrónicos.

b.2) Estaciones de trabajo

i. Deberán estar configuradas para bloquearse luego de 10 (diez) minutos de inactividad, de forma de limitar el acceso a las mismas,

ii. Los usuarios deben asegurarse de:

• Desconectarse de las aplicaciones o servidores una vez finalizado el trabajo
• Cerrar o bloquear la sesión del sistema operativo en caso de alejarse del mismo

b.3) Los usuarios no deberán conectar ningún dispositivo a la red cableada que no pertenezca al equipamiento distribuido por el Departamento de Desarrollo Sostenible e Inteligente o autorizado por Seguridad Informática, ya que puede implicar un riesgo para la seguridad de la información o a la red en general, dichos dispositivos podrán ser desconectados o retirados por las áreas de Seguridad Informática o Telecomunicaciones.

c) Definiciones

i. Permiso de acceso: privilegio que asociado a un usuario le permita acceder, borrar o modificar cualquier recurso informático, o realizar acciones a través de los distintos sistemas tales como enviar un correo, disparar un proceso, modificar un dato, etc.

ii. Contraseña segura: aquella contraseña que cumple con las directivas establecidas en esta política.

iii. Se entiende por administrador de sistema a quién o quienes decidan sobre la finalidad, contenido y uso del sistema. No incluye a los técnicos informáticos.

iv. Segundo factor de autenticación: mecanismo utilizado para verificar que un usuario es quien dice ser, combinando dos componentes diferentes, como ser una contraseña y un mensaje o código obtenido desde un dispositivo móvil.

d) Roles y responsabilidades

i. Los usuarios son responsables de minimizar el riesgo mediante el incumplimiento de las políticas establecidas y el seguimiento de las recomendaciones.

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.

 11º.- Sustituir el artículo R.418.26 de la Sección VI "De la política de control de acceso de usuarios", Capítulo XVIII.3 "Del Sistema de Gestión de la Seguridad de la Información", Título único, Parte Reglamentaria. Libro III "De la relación funcional", Volumen III "Relación Funcional", de Digesto Departamental, en la redacción dada por el numeral 2 de la Resolución Nro. 68/10, de fecha 04 de enero de 2010, el que quedará redactado de la siguiente manera: 

  "Artículo R.418.26.-Establecer que la Política de Control de acceso de usuarios deberá ser revisada cuando ocurran cambios significativos (técnicos, normativo, negocio) o al menos cada tres años para evaluar su implantación y modificada cuando así se requiera, a efectos de eficaz cumplimiento de sus objetivos.

12º.- Sustituir el artículo R.418.27 de la Sección VII "De la política de seguridad en la adquisición, desarrollo y mantenimiento de los sistemas de información", Capítulo XVIII.3 "Del Sistema de Gestión de la Seguridad de la Información", Título único, Parte Reglamentaria. Libro III "De la relación funcional", Volumen III "Relación Funcional", de Digesto Departamental, en la redacción dada por el numeral 1 de la Resolución Nro. 641/10, de fecha 22 de febrero de 2010, el que quedará redactado de la siguiente manera: 

  "Artículo R.418.27.-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 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, é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.

 13º.- Sustituir el artículo R.418.28 de la Sección VII "De la política de seguridad en la adquisición, desarrollo y mantenimiento de los sistemas de información", Capítulo XVIII.3 "Del Sistema de Gestión de la Seguridad de la Información", Título único, Parte Reglamentaria. Libro III "De la relación funcional", Volumen III "Relación Funcional", de Digesto Departamental, en la redacción dada por el numeral 2 de la Resolución Nro. 641/10, de fecha 22 de febrero de 2010, el que quedará redactado de la siguiente manera: 

  "Artículo R.418.28.-Establecer que el alcance de esta Política aplica a todos los sistemas de información de la Intendencia de Montevideo, incluyendo los ubicados en el Palacio y sitios externos. La misma comprende los sistemas existentes y futuros.

 14º.- Sustituir el artículo R.418.29 de la Sección VII "De la política de seguridad en la adquisición, desarrollo y mantenimiento de los sistemas de información", Capítulo XVIII.3 "Del Sistema de Gestión de la Seguridad de la Información", Título único, Parte Reglamentaria. Libro III "De la relación funcional", Volumen III "Relación Funcional", de Digesto Departamental, en la redacción dada por el numeral 3 de la Resolución Nro. 641/10, de fecha 22 de febrero de 2010, el que quedará redactado de la siguiente manera: 

  "Artículo R.418.29.-Establecer que la Política de seguridad en la adquisición, desarrollo y mantenimiento de los sistemas de información deberá ser revisada cuando ocurran cambios significativos (técnicos, normativo, negocio) o al menos cada tres años para evaluar su implantación y modificada cuando así se requiera, a efectos de eficaz cumplimiento de sus objetivos.

 15º.- Sustituir el artículo R.418.30 de la Sección VIII "De la política de Gestión de Incidentes de la Seguridad de la Información", Capítulo XVIII.3 "Del Sistema de Gestión de la Seguridad de la Información", Título único, Parte Reglamentaria. Libro III "De la relación funcional", Volumen III "Relación Funcional", de Digesto Departamental, en la redacción dada por el numeral 1 de la Resolución Nro. 642/10, de fecha 22 de febrero de 2010, el que quedará redactado de la siguiente manera: 

   "Artículo R.418.30.- Determinar la siguiente Política de Gestión de Incidentes de la Seguridad de la Información, a los efectos de establecer los procedimientos a seguir para asegurar que las debilidades y eventos de seguridad de la información asociados a sistemas de información de la Intendencia de Montevideo, sean comunicados para permitir tomar acciones correctivas a tiempo.

a) Política:

a.1) Notificación de eventos de seguridad de la información

I) Los eventos de seguridad de la información deben ser notificados a la Mesa de Servicios tan pronto como sea posible. Mesa de Servicios deberá notificar al Área de Seguridad Informática, en caso de confirmar o sospechar que sea un evento de seguridad de la información.

II) Alternativamente se recibirán consultas a través de la dirección de correo: seguridad.informatica@imm.gub.uy,

III) Todo funcionario, proveedor, usuario de terceras partes y personal contratado, debe ser puesto en conocimiento de los puntos de contacto establecido en I) y II), así como también deben ser informados de su obligación de comunicar estos eventos.

IV) Se debe notificar a aquellos que reportaron eventos de seguridad, del resultado obtenido una vez procesado el reporte y cerrado el evento.

V) El comportamiento correcto a llevar a cabo por aquellos que reportan un posible evento de seguridad de la información, consiste en observar todos los detalles importantes, reportar inmediatamente el mismo y no realizar ninguna acción.

VI) Frente a la sospecha de una vulnerabilidad de un sistema o equipamiento, la misma no debe ser probada, sino que tal sospecha debe ser comunicada a los puntos de contacto definidos en I) y II), a los efectos que se investigue y mitigue dicha vulnerabilidad. La no observación de este punto podría conducir a fallas del sistema que deriven en responsabilidades para la persona que probó la vulnerabilidad.

VII) El formato de registro de incidentes definido por el Área de Seguridad Informática, será utilizado a la hora de registrar estos eventos. El Área de Seguridad Informática debe documentar los incidentes de seguridad.

a.2) Responsabilidad y procedimientos

I) El Área de Seguridad Informática establecerá, y la Dirección del Departamento de Desarrollo Sostenible e Inteligente aprobará, los procedimientos a seguir para la gestión de diversos tipos de incidentes de seguridad de la información.

Las acciones para contener, mitigar o detener el impacto pueden implicar pérdida temporal, parcial o total de servicios afectados debido a desconexión de equipos, servicios o red de datos, hasta el normal restablecimiento de los mismos.

Se establecerán controles que permitan evitar incidentes de seguridad, los mismos podrán generar bloqueo de accesos, usuarios, equipos, sitios o servicios que puedan causar un perjuicio por tratarse de contenido malicioso, comportamientos anómalos, actividades extrañas, accesos sospechosos, o actividades que puedan provocar fallas temporales, lentitud de servicios o consumo excesivo de ancho de banda de los enlaces de comunicaciones. Estas acciones serán informadas al usuario, grupo, Directores y Mesa de Servicio.

Toda la actividad desde y hacia internet deberá pasar a través de los controles establecidos de seguridad, como ser Firewalls, Antivirus, Sistemas de Protección de Intrusos (IPS), Protección de aplicaciones, etc. Además, se podrá analizar todo el tráfico cifrado a excepción de sitios bancarios, salud o de privacidad personal, a los efectos de proteger los sistemas de ataques o infecciones a los sistemas de información.

II) Estos procedimientos, además de incluir los planes de contingencia normales, deben también cubrir los siguientes puntos:

• Análisis e identificación de la causa del incidente.
• Contención.
• Planificación e implementación de la acción correctiva para prevenir la repetición del evento.
• Comunicación con aquellos afectados por o implicados en la recuperación del incidente.
• Reporte del evento a la autoridad apropiada.

III) Se deben procurar recoger pistas de auditoría y evidencia pertinente de forma apropiada para que sea útil, para:

• Análisis interno del problema.
• Uso como evidencia forense en lo referente a una violación potencial de un contrato o de un requisito regulador o legal.

IV) Las acciones para la recuperación de las violaciones de seguridad y la corrección de las fallas del sistema deben estar cuidadosa y formalmente controladas; los procedimientos deben asegurar que:

• Solamente al personal claramente identificado y autorizado se le permite el acceso a los sistemas en producción y a sus datos.
• Son documentadas detalladamente todas las medidas de urgencia tomadas.
• Las mismas se reportarán a la Dirección del Departamento de Desarrollo Sostenible e Inteligente y se repasarán de una manera ordenada.
• La integridad de los sistemas y de los controles se verificarán lo antes posible.

V) Los objetivos para la gestión de incidentes de seguridad de la información serán acordados con la Dirección del Departamento de Desarrollo Sostenible e Inteligente, de forma que los responsables de la gestión de los mismos entiendan las prioridades de la Organización para manejar incidentes de seguridad de la información.

a.3) Análisis de los incidentes de seguridad

I) Una vez cerrado el incidente se debe proceder a la valoración de los mismos, estimando requerimientos y gastos asociados al incidente.

II) Se debe establecer la posibilidad de que el mismo se repita, así como implementar las medidas correctivas necesarias que disminuyan la posibilidad de ocurrencia futura o mitiguen su impacto.

III) A la luz de la experiencia ganada se deben evaluar los procedimientos en un marco de mejora continua.

b) Definiciones:

Evento de seguridad informática: ocurrencia identificada de un estado de un sistema, servicio o red que indica una posible violación de la política de seguridad de la información, la falla de una medida de seguridad o una situación previamente desconocida que pueda ser relevante para la seguridad (Ref. Decreto de fecha 28 de setiembre de 2009 - Regulación del Centro Nacional de Respuesta e Incidencias de Seguridad Informática).

Incidente de seguridad informática: violación o amenaza inminente de violación a una política de seguridad de la información implícita o explícita, así como un hecho que comprometa la seguridad de un sistema (confidencialidad, integridad, disponibilidad). (Ref. Decreto de fecha 28 de setiembre de 2009 - Regulación del Centro Nacional de Respuesta e Incidencias de Seguridad Informática).

c)Roles y responsabilidades

I) Todos los usuarios de recursos informáticos de la Intendencia de Montevideo deben 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.

 16º.- Sustituir el artículo R.418.32 de la Sección VIII "De la política de Gestión de Incidentes de la Seguridad de la Información", Capítulo XVIII.3 "Del Sistema de Gestión de la Seguridad de la Información", Título único, Parte Reglamentaria. Libro III "De la relación funcional", Volumen III "Relación Funcional", de Digesto Departamental, en la redacción dada por el numeral 3 de la Resolución Nro. 642/10, de fecha 22 de febrero de 2010, el que quedará redactado de la siguiente manera: 

  "Artículo R.418.32.-Establecer que la Política de Gestión de Incidentes de la Seguridad de la Información deberá ser revisada cuando ocurran cambios significativos (técnicos, normativo, negocio) o al menos cada tres años para evaluar su implantación y modificada cuando así se requiera, a efectos de eficaz cumplimiento de sus objetivos.

 17º.- Sustituir el artículo R.418.33 de la Sección IX "De la política de continuidad del negocio", Capítulo XVIII.3 "Del Sistema de Gestión de la Seguridad de la Información", Título único, Parte Reglamentaria. Libro III "De la relación funcional", Volumen III "Relación Funcional", de Digesto Departamental, en la redacción dada por el numeral 1 de la Resolución Nro. 814/10, de fecha 02 de marzo de 2010, el que quedará redactado de la siguiente manera: 

  "Artículo R.418.33.- Determinar la siguiente política de continuidad operativa de TI, a los efectos de establecer los requerimientos que debe cumplir el proceso de gestión de continuidad, para minimizar el impacto y garantizar la recuperación ante desastres, fallas de seguridad, pérdida de servicio, disponibilidad y pérdida de activos de información en la Intendencia de Montevideo, hasta un nivel aceptable, mediante la combinación de controles preventivos y de recuperación:

a) Alcance

El alcance de la misma es aplicable a todos los procesos, sistemas y aplicaciones mediante los cuales el Departamento de Desarrollo Sostenible e Inteligente brinda servicios en la Intendencia de Montevideo.

b) Definiciones:

Riesgo: combinación de la probabilidad de ocurrencia de un acontecimiento y de su consecuencia. [Guía ISO/IEC 73:2002].

Evaluación de riesgos: proceso completo de análisis de riesgos y evaluación de riesgos. [Guía ISO/IEC 73:2002].

Plan de continuidad operativa de TI: colección de procedimientos para mantener las operaciones esenciales del negocio mientras se recupera de un desastre significativo. [NIST SP-800-34].

Recuperación de desastres: proceso de recuperación de la operación o infraestructura luego de un desastre. [SANS].

Propietario de la información: individuo o entidad responsable ante la Organización de controlar la producción, desarrollo, mantenimiento, uso y seguridad de la información.

c) Política: todas las áreas del Departamento de Desarrollo Sostenible e Inteligente adherirán a esta política para garantizar la continuidad operativa de TI:

i) Proceso de gestión de la continuidad operativa de TI.

Se debe desarrollar y mantener un proceso de gestión para la continuidad operativa de TI que reúna al menos los siguientes elementos:

Análisis y determinación de los riesgos que enfrenta la Organización en términos de probabilidad de ocurrencia de las amenazas e impacto. incluyendo la identificación y la determinación de la prioridad de los procesos críticos del negocio.

Identificación y evaluación de implantación de controles preventivos y de reducción de riesgo.

Identificación de recursos financieros, organizacionales, técnicos y ambientales suficientes para tratar los requisitos identificados de la seguridad de la información.

Garantizar la seguridad del personal y la protección de los servicios de procesamiento de información y de la propiedad de Organización.

Formulación y documentación de los planes de continuidad operativa de TI.

Prueba y actualización regular de los planes y procesos establecidos.

Garantizar que la gestión de la continuidad operativa de TI está incorporada en los procesos y la estructura de la Organización.

ii) Continuidad operativa de TI y evaluación de riesgos.

Se debe realizar un análisis de riesgos para determinar los requerimientos y prioridades de contingencia.

En el análisis de riesgo se deben:

• Identificar los procesos críticos del negocio.
• Identificar los activos involucrados en los procesos críticos del negocio.
• Identificar los eventos o cadenas de eventos que puedan ocasionar interrupciones en los procesos de negocio.
• Analizar y evaluar la probabilidad de ocurrencia y el impacto que puedan tener las interrupciones causadas por incidentes de seguridad de la información.

Las evaluaciones deben efectuarse con la plena participación de los dueños de los recursos y procesos de negocio.

Las evaluaciones deben considerar todos los procesos de negocios, no limitándose a los servicios de procesamiento de la información.

Se debe identificar, cuantificar y priorizar los riesgos frente a los criterios y los objetivos pertinentes para la organización, incluyendo:

• Recursos críticos
• Impacto de las interrupciones
• Duración permitida de corte
• Prioridades de recuperación

A partir de los resultados de esta evaluación de riesgos, se deben desarrollar los planes de continuidad operativa de TI.

iii) Desarrollo e implementación de planes de continuidad.

La Dirección del Departamento de Desarrollo Sostenible e Inteligente debe aprobar los planes de continuidad operativa de TI previo a su implementación, así como crear y respaldar un plan para la implementación de los mismos.

En el proceso de planificación de la continuidad operativa de TI se deben:

• Identificar todos los recursos y servicios relacionados al proceso de restauración incluyendo personal, respaldos, acuerdos con terceras partes, y recursos no relacionados con el procesamiento de la información.
• Identificar prioridades y tiempos de recuperación para cada activo y/o procesos.
• Identificar, acordar y documentar todos los roles y responsabilidades, tanto internos como de empresas u organizaciones externas, para la ejecución del Plan.
• Identificar la pérdida aceptable de información y servicios.
• Establecer, documentar e implementar los procedimientos operativos a seguir, para permitir la recuperación y restauración de las operaciones del negocio y la disponibilidad de la información en las escalas de tiempo requeridas.
• Capacitar, de manera apropiada al personal, en los procedimientos y procesos acordados, incluyendo el manejo de crisis.
• Realizar revisiones, pruebas y actualización de los planes. Los resultados de las revisiones deben ser documentados.

Las copias de los planes de continuidad operativa de TI y el material necesario para la ejecución de los mismos, deben ser almacenados en un lugar seguro a salvo de desastres del local principal y protegidas con el mismo nivel de seguridad que el local principal.

• Las copias de los planes de continuidad operativa de TI deben estar actualizadas.

iv) Estructura de los planes de continuidad operativa de TI

Se debe mantener una sola estructura de los planes de continuidad operativa de TI para asegurar que todos son consistentes.

Cada plan debe tener un responsable/dueño específico, responsable de su mantenimiento, revisión, prueba, selección de criterios para la ejecución y requerimientos para la activación.

Los planes deben incluir los siguientes aspectos:

• Las condiciones que se deben dar para la activación de cada plan.
• Los procedimientos de emergencia que describen las acciones a realizar tras un incidente que ponga en peligro las operaciones del negocio.
• Los procedimientos de respaldo que describen las acciones a realizar para desplazar las actividades esenciales del negocio, o servicios de soporte a lugares temporales alternos y para devolver la operatividad de los procesos de negocio en los tiempos requeridos.
• Los procedimientos operativos temporales a seguir mientras se termina la recuperación y restauración.
• Los procedimientos de restauración que describen las acciones a realizar para que las operaciones del negocio vuelvan a la normalidad.
• Un cronograma de mantenimiento que especifique cuándo y cómo se realizaran pruebas del plan y el proceso para el mantenimiento del mismo.
• Concientización, educación y formación del personal para comprender los procesos de continuidad operativa de TI y garantizar que los mismos sean eficaces.
• Deben quedar establecidas las responsabilidades de las personas, en particular deberá quedar determinado quién es responsable de la ejecución de cada componente del plan, así como sus suplentes si fuera necesario y el plan de escalada.
• Los activos y recursos críticos necesarios para ejecutar los procedimientos de emergencia, respaldo y restauración.

v) Pruebas, mantenimiento y revisión de los planes de continuidad de TI.

Los planes de continuidad operativa de TI se deben someter a pruebas, semestrales para los procesos de máxima criticidad y riesgo y anuales para el resto, y actualizar periódicamente.

Las pruebas deben asegurar que todos los miembros del equipo de recuperación y otro personal pertinente son conscientes de los planes y sus responsabilidades así como su actividad y rol a la hora de ejecutar el plan.

La programación de las pruebas para los planes de continuidad operativo de TI debe indicar cómo y cuándo se va a probar cada elemento del plan.

Las pruebas deben incluir las siguientes técnicas para garantizar que los planes funcionaran en condiciones reales:

• Prueba sobre papel de varios escenarios (utilizando distintos ejemplos de interrupciones).
• Simulaciones (efectivas para la formación de personal).
• Pruebas de recuperación técnica (garantizando que los sistemas de información se puedan restaurar eficazmente)
• Pruebas de recuperación en lugar alterno.
• Pruebas de recursos y servicios de los proveedores externos (asegurando que los servicios y productos proporcionados externamente cumplirán el compromiso contraído).
• Ensayos completos, en los que se verificará que la organización, el personal. el equipo, las instalaciones y los proceso pueden hacer frente a las interrupciones.

Se debe asignar responsabilidades para las revisiones regulares de cada plan de continuidad.

El proceso formal de control de cambios deberá garantizar la distribución y el refuerzo de los planes actualizados.

Se debe tener atención con los cambios en:

• El equipamiento, incluyendo adquisición de equipos nuevos.
• Los sistemas.
• El personal.
• Las direcciones o números telefónicos.
• La estrategia del negocio.
• Los lugares, dispositivos o recursos.
• La legislación.
• Los proveedores y clientes principales.
• Los procesos existentes, nuevos o retirados.
• Los riesgos.

d) Roles y responsabilidades

i. La implementación de esta política es responsabilidad del Departamento de Desarrollo Sostenible e Inteligente en su conjunto.

ii. El área de Análisis de Procesos Informáticos en conjunto con el Área de Seguridad Informática serán responsables de la realización del análisis de riesgos y la planificación, elaboración y seguimiento de los planes de continuidad operativa de TI.

iii. Las áreas operativas (Operaciones, Mesa de Servicios, Administración de Sistemas, Relacionamiento interno, Telecomunicaciones, Aplicaciones y Administración de Bases de Datos) serán responsables de la ejecución, documentación, mantenimiento y prueba de los planes.

vi. La Administración es responsable de colaborar, evaluar e informar de cambios que afecten a los planes de continuidad oportunamente definidos.

18º.- Sustituir el artículo R.418.34 de la Sección IX "De la política de continuidad del negocio", Capítulo XVIII.3 "Del Sistema de Gestión de la Seguridad de la Información", Título único, Parte Reglamentaria. Libro III "De la relación funcional", Volumen III "Relación Funcional", de Digesto Departamental, en la redacción dada por el numeral 2 de la Resolución Nro. 814/10, de fecha 02 de marzo de 2010, el que quedará redactado de la siguiente manera: 

  "Artículo R.418.34.- Establecer que la Política de continuidad operativa de TI deberá ser revisada cuando ocurran cambios significativos (técnicos, normativo, negocio) o al menos cada tres años para evaluar su implantación y modificada cuando así se requiera, a efectos de eficaz cumplimiento de sus objetivos.

19º.- Comuníquese al Departamento de Secretaria General; a la División Asesoría Jurídica y a todos los Departamentos y pase al Departamento de Desarrollo Sostenible e Inteligente.-