Respuesta al tema:

MINISTERIO DE DESARROLLO SOCIAL

Ver Mensaje Individual

MINISTERIO DE DESARROLLO SOCIAL





MINISTERIO DE DESARROLLO SOCIAL


SECRETARIA DE COORDINACION


Resolución NΊ 7028/2007


Bs. As., 31/7/2007


VISTO el Expediente NΊ E-27060-2007, del registro del MINISTERIO DE DESARROLLO SOCIAL, y


CONSIDERANDO:


Que el MINISTERIO DE DESARROLLO SOCIAL ha cumplido con lo establecido por la Ley NΊ 24.156 en el Art. 8 Inc. a) y c), los Decretos NΊ 103/01 que aprueban el Plan Nacional de Modernización de la Administración Pública Nacional, el NΊ 624/03 que aprueba la estructura organizativa de primer nivel de la Jefatura de Gabinete de Ministros, el NΊ 357/02 y sus modificatorios que aprueba el organigrama de la Administración Pública Nacional centralizada hasta el nivel de Subsecretaría y los objetivos de las unidades organizativas del mismo, que promueve la implementación de la Decisión Administrativa NΊ 669/04 "POLITICA DE SEGURIDAD DE LA INFORMACION" de la JEFATURA DE GABINETE DE MINISTROS.


Que por Resolución del MINISTERIO DE DESARROLLO SOCIAL NΊ 1034/05, se aprobó la constitución del COMITE DE SEGURIDAD DE LA INFORMACION del citado organismo.


Que a través de la Resolución NΊ 4264/SC/05, se designó a los representantes de las Secretarías y Subsecretarias que conforman el COMITE DE SEGURIDAD DE LA INFORMACION DEL MINISTERIO DE DESARROLLO SOCIAL.


Que la Coordinación de Informática ha elaborado la POLITICA DE SEGURIDAD DE LA INFORMACION DEL MINISTERIO DE DESARROLLO SOCIAL, que ha sido aprobada por el COMITE DE SEGURIDAD DE LA INFORMACION DEL MINISTERIO, según consta en 3Ί Acta de Reunión de Comité de Seguridad de la Información, realizada el 11 de mayo de 2006.


Que la Coordinación de Informática ha elaborado los PROCEDIMIENTOS DE SEGURIDAD DE SISTEMAS DE INFORMACION según la Política de Seguridad de la Información del Ministerio de Desarrollo Social, en el marco del MODELO DE POLITICA DE SEGURIDAD DE LA INFORMACION de la Administración Pública Nacional centralizada, de acuerdo a lo establecido por Decisión Administrativa NΊ 669/04, para ser utilizados y cumplidos en todo su ámbito.


Que los mismos han sido aprobados por el COMITE DE SEGURIDAD DE LA INFORMACION de este Ministerio, según consta en 4Ί Acta de Reunión de Comité de Seguridad de la Información, realizada el 19 de abril de 2007.


Que su implementación permite contar con una herramienta eficaz a la hora de dejar plasmada la operatoria completa y articulada de la información.


Que la DIRECCION GENERAL DE ASUNTOS JURIDICOS ha tornado la intervención de su competencia.


Que la presente resolución se dicta en uso de las facultades otorgadas por la Ley de Ministerios, sus normas complementarias y modificatorias y por el Decreto NΊ 551/06.


Por ello,


EL SECRETARIO DE COORDINACION


RESUELVE:


ARTICULO 1Ί — Apruébanse les PROCEDIMIENTOS DE SEGURIDAD DE SISTEMAS DE INFORMACION del MINISTERIO DE DESARROLLO SOCIAL, que como Anexo integran la presente Resolución.


ARTICULO 2Ί — Derogase la Resolución de esta Secretaría NΊ 1235/06 "SINTESIS DE PERMISOS DE ACCESOS", cuyo contenido ya se incluyó en los Procedimientos de: Políticas de Internet, Administración de Usuarios y Uso de Recursos.


ARTICULO 3Ί — Inclúyase el documento aprobado en el sitio www.portal.min del MINISTERIO DE DESARROLLO SOCIAL.


ARTICULO 4Ί — Por la COORDINACION DE INFORMATICA, hágase saber a la Unidad Ministro y a las Secretarías de éste Ministerio, a los fines de la notificación de sus organismos dependientes.


ARTICULO 5Ί — Regístrese, comuníquese, publíquese, dése a la DIRECCION NACIONAL DEL REGISTRC OFICIAL y archívese. — Cdor. CARLOS D. CASTAGNETO, Secretario de Coordinación, Ministerio de Desarrollo Social.


ANEXO I


Procedimientos de Seguridad de los Sistemas de Información


del Ministerio de Desarrollo Social


Marco: "Modelo de Política de Seguridad de los


Sistemas de Información para Organismos de la


Administración Pública Nacional DA 669/04"




Capítulo ADMUSU


CONTENIDO


1. OBJETIVO


2. ALCANCE


3. RESPONSABILIDADES


3.1. PROPIETARIO


3.2. RESPONSABLES DE CUMPLIMIENTO


3.3. RESPONSABLES DE ACTUALIZACION


4. REGIMEN DE REVISION Y ACTUALIZACION


5. DESARROLLO


5.1. ALTA DE UN USUARIO


5.1.1. FORMA


5.1.2. CONTENIDO


5.1.3. PERSONAS HABILITADAS PARA LA SOLICITUD DE ALTAS DE USUARIOS


5.1.4. DOCUMENTACION A PRESENTAR


5.1.5. PRESENTACION


5.1.6. REGISTRO


5.1.7. AVISO AL USUARIO


5.1.8. ACLARACIONES


5.1.9. SOLICITUD DE CREACION DE CUENTAS INSTITUCIONALES


5.2. NOMBRE DE USUARIO


5.3. CONTRASEÑA (PASSWORD)


5.3.1. ASIGNACION DE CONTRASEÑA


5.3.2. CAMBIO DE CONTRASEÑA


5.4. MODIFICACION DE UN USUARIO/PERFIL EXISTENTE


5.5. ACCIONES POR INCUMPLIMIENTO


5.5.1. BLOQUEO DE USUARIO


5.5.2. RECONEXION DE SERVICIO


5.5.3. RECOMENDACIONES GENERALES


5.6. BAJA DE UN USUARIO


6. MANEJO INTERNO DE ADMINISTRACION DE USUARIOS


6.1. RECEPCION DE DOCUMENTACION (MEMORANDUM/FORMULARIOS)


6.2. MANEJO INTERNO DE DOCUMENTACION (ACCESS)


6.3. BASE DE DATOS DE DOCUMENTACION - ACCESS


6.4. ARCHIVO DE DOCUMENTACION


6.5. ESCASEZ O PRECARIEDAD EN LA DOCUMENTACION


7. ANEXO


7.1. SOLICITUD DE ALTA DE USUARIO / MODIFICACION DE PERFIL


INSTRUCTIVO PARA COMPLETAR EL FORMULARIO


7.2. FORMULARIO DE ENTREGA DE CONTRASEÑAS


1. OBJETIVO


Documentar un proceso de solicitud, análisis, aprobación e implementación de acceso lógico a los recursos del organismo.


Estandarizar formularios para la solicitud de altas, bajas o modificaciones de accesos a los recursos de manera de contemplar todos los posibles requerimientos de un usuario.


Disponer la documentación administrativa e informáticamente organizada a los fines de establecer un sistema eficiente para los usuarios que operan en la red.


2. ALCANCE


El presente procedimiento será aplicado al control de acceso lógico a los siguientes componentes del ambiente informático:


2.1- Información del Organismo


2.2- Plataformas de procesamiento (o sistemas operativos)


2.3- Bases de datos con información del Organismo


2.4- Sistemas que procesan información del Organismo


2.5- Servicios de red informática (ej.: correo electrónico, Internet, impresoras, etc.)


3. RESPONSABILIDADES


3.1. PROPIETARIO


El propietario del este procedimiento es el Ing. Alberto Chedufau en su carácter de Responsable de Seguridad del Ministerio. Sus responsabilidades primarias son:


3.1.1- Establecer las medidas de seguridad necesarias para garantizar el adecuado almacenamiento del presente documento.


3.1.2- Definir los perfiles que tendrán acceso al documento.


3.1.3- Asegurar la accesibilidad del documento para quienes necesiten consultarlo.


3.1.4- Comunicar la existencia del documento y asesorar sobre el mismo a los responsables de su cumplimiento.


3.1.5- Solicitar actualizaciones fuera del esquema normal.


3.2. RESPONSABLES DE CUMPLIMIENTO


Son responsables del cumplimiento del este procedimiento todos los empleados del Organismo, así como terceros que hagan uso de cualquier recurso informático perteneciente al mismo.


3.3. RESPONSABLES DE ACTUALIZACION.


El responsable de la actualización del presente procedimiento es el Ing. Alberto Chedufau en su carácter de Responsable de Seguridad del Ministerio. Su responsabilidad es revisar, actualizar en caso que corresponda, y archivar el presente documento de acuerdo al esquema de revisión y actualización establecido y a las solicitudes efectuadas por el propietario del mismo.


4. REGIMEN DE REVISION Y ACTUALIZACION


El presente documento será revisado semestralmente y actualizado en el caso de detectarse la necesidad de efectuar modificaciones que permitan mantenerlo actualizado en relación a la realidad de la estructura funcional y del ambiente informático.


5. DESARROLLO


De acuerdo a lo establecido en la Política de Seguridad, todos los usuarios tendrán un identificador único (ID de usuario) solamente para su uso exclusivo, de manera que las transacciones puedan rastrearse con posterioridad hasta llegar al individuo que las haya efectuado. Los identificadores de usuario no darán ningún indicio del nivel de privilegio otorgado.


No se permite utilizar un mismo usuario identificador compartido para un grupo de personas. A continuación se definen términos que serán empleados en el presente procedimiento:


Cuenta: se entiende por cuenta, al ID de usuario y su contraseña asociada que le permiten ingresar de forma autorizada a un entorno (de red, plataforma o sistema).


Perfil: conjunto de permisos o funciones que puede realizar un usuario. Los perfiles se asocian a las cuentas de usuario.


5.1. ALTA DE UN USUARIO


El alta de una cuenta se realizará mediante los siguientes pasos:


5.1.1. Forma:


Se solicita a través de nota/memorandum a la Coordinación de Informática.


5.1.2. Contenido:


5.1.2.1- La misma deberá contener nombre y apellido del usuario.


5.1.2.2- Sector en el que prestará servicios.


5.1.2.3- Sistemas a los que debería tener acceso


5.1.2.4- Número de legajo o número de documento.


5.1.3. Personas habilitadas para la solicitud de altas de usuarios:


La solicitud de alta de usuarios, únicamente podrá ser efectuada por los Sres. Secretarios, Subsecretarios, Directores Generales, Directores y Coordinadores de áreas.


5.1.4. Documentación a presentar:


Dicha nota/memorandum, deberá acompañarse de un formulario de "Solicitud de alta de usuario". (Ver 7.1. Anexo Formulario Solicitud / Modificación / Baja de Usuarios), que completará y firmará cada usuario en particular, con la aprobación de la autoridad que corresponda. El formulario puede ser bajado desde el siguiente sitio: http://www.portal.min/usuarios.pdf.


5.1.5. Presentación:


Luego de completado, el formulario debe ser presentado al Area Informática, para su aprobación.


5.1.6. Registro:


Toda vez que se adicione un usuario, se debe registrar el cambio en sus archivos administrativos.


5.1.7. Aviso al Usuario:


Por último, se debe proveer al nuevo usuario la información necesaria para comenzar a utilizar su cuenta. Dicha información refiere al nombre de usuario y a la contraseña del recurso solicitado. De esta forma se concreta la finalización del proceso de alta.


5.1.8. Aclaraciones:


Cabe aclarar que el formulario se completa solamente de manera personalizada, mientras que la nota/memorandum puede que sea conjunta, es decir que contenga la solicitud de alta de varios usuarios a la vez.


Ante esto, es necesario otorgarle a cada nota/memorando un número interno, que permitirá operativizar su búsqueda en la documentación en papel.


Teniendo en cuenta que, varios formularios pueden remitir a una misma nota/memorando es fundamental que cada uno contenga el número interno al que se remite, para obtener un mejor control.


5.1.9. Solicitud de creación de Cuentas Institucionales


En este punto es necesario poner en conocimiento de todas las áreas del Ministerio que en el marco de la implementación de D.A. 669/2004, no tiene lugar la creación de Cuentas Institucionales compartidas por varios usuarios. A modo de tener un control en la administración y la correcta utilización de estas cuentas, se implementará la siguiente operatoria, todo aquel sector que tenga la necesidad de contar con una cuenta de esta naturaleza deberá asignar la responsabilidad de la utilización de la misma a una única persona, en este caso el Responsable del Area deberá completar el formulario y la solicitud de rigor como para los casos de altas de usuario, formulario que se encuentra accediendo a nuestro portal www.portal.min formularios, allí se completarán los datos consignados en el mismo, donde se indicará a quien se le asigna la utilización, administración y responsabilidad de esa Cuenta Institucional solicitada.


En el caso que el responsable de la cuenta se ausentará por algún motivo, el responsable del área solicitante deberá formalizar el cambio de titularidad de usuario, a los efectos de continuar con la normal operatividad de la misma.


5.2. NOMBRE DE UN USUARIO


Este nombre es asignado por el Centro de Cómputos, quien lo comunicará directamente al usuario.


Este nombre será la "identificación" del usuario y se ingresará al ejecutar el usuario el inicio del sistema operativo.


Pautas y Características:


5.2.1 Tendrá una longitud mínima de 4 (cuatro) y una longitud máxima de 16 (dieciséis) caracteres.


5.2.2 Como norma se utilizará la inicial del nombre y el apellido del usuario (Ej. Juan Pérez será jperez; en el caso de apellidos muy extensos, podrá utilizarse parte del apellido). Para los apellidos compuestos se tendrán en cuenta siempre el primer nombre y el primer apellido. Puede suceder que ya exista un usuario con la misma identidad, por lo que se utilizarán las iniciales del primero y segundo nombre para no repetir el ID del usuario.


5.3. CONTRASEÑA (PASSWORD)


5.3.1. Asignación de contraseña


Para el primer ingreso al sistema, el Sector Administración del Centro de Cómputos le comunica su nombre de usuario y le asigna como contraseña su número de documento al usuario.


Asimismo, el administrador debe tildar la opción para que el usuario al entrar por primera vez, le aparezca la advertencia de que su contraseña ha caducado y comience con el proceso de cambio de su contraseña.


5.3.2. Cambio de contraseña.


Cuando inicie la sesión de red con su nombre de usuario (por Ej.: agarcia), aparecerá una ventana indicando que su contraseña ha caducado.


Deberá hacer click en el botón Aceptar.


Luego se presentará una segunda ventana donde ya aparecerá escrita su contraseña actual en el campo correspondiente a la contraseña anterior y dos campos donde deberá ingresar la contraseña nueva.


Las reglas de la política, que rige la nueva contraseña son:


a) Longitud mínima de 8 (ocho) caracteres y máxima de 12 (doce) caracteres.


b) Puede ser alfanumérica (combinación de números y letras). Condición no excluyente.


c) Los caracteres permitidos son: letras mayúsculas y minúsculas; números entre el 0 (cero) y el 9 (nueve). No utilizar acentos y/u otros símbolos.


d) La contraseña es sensible a mayúsculas y minúsculas, es decir, ‘a’ no es lo mismo que ‘A’.


e) No podrá repetirse la contraseña anterior, al menos las correspondientes a los 3 últimos cambios.


De no cumplirse con una de estas reglas, aparecerá una ventana advirtiendo el error, y que vuelva a escribir su nueva contraseña respetando las reglas anteriormente especificadas.


Por el contrario si se cumple con las reglas, el proceso de cambio de contraseña será exitoso.


Para ingresos sucesivos, el usuario deberá identificarse, ingresando su nombre de usuario y a continuación la contraseña nueva que ha elegido.


La contraseña es confidencial, de uso exclusivo del usuario, no podrá ser igual al nombre de usuario y no debe "prestarse" a otros usuarios.


En lo referente a correo electrónico, como la contraseña de correo es la misma que la de usuario de red, al revisar su casilla de correo o hacer click en "enviar y recibir" se le solicitará también que ingrese la nueva contraseña.


Esta última operación, deberá ejecutarse por lo menos 15 minutos después de haber cambiado la contraseña de red.


Si se presenta un problema o anomalía durante el proceso deberá comunicarse con el Centro de Cómputos de su edificio.


5.4. MODIFICACION DE UNA CUENTA/PERFIL EXISTENTE


La modificación de una cuenta se realizará mediante los siguientes pasos:


5.4.1. Forma:


Se solicita a través de nota/memorandum a la Coordinación de Informática.


5.4.2. Contenido:


5.4.2.1- La misma deberá contener nombre y apellido del usuario.


5.4.2.2- Sector en el que prestará servicios.


5.4.2.3 - Perfiles o accesos que se quieren modificar.


5.4.2.4- Número de legajo o número de documento.


5.4.3. Personas habilitadas para la solicitud de modificaciones de usuarios:


La modificación de usuarios, únicamente podrá ser efectuada por los Sres. Secretarios, Subsecretarios, Directores Generales, Directores y Coordinadores de áreas.


5.4.4. Dicha nota/memorandum, deberá acompañarse de un formulario de "Solicitud de modificación de usuario". (Ver 7.1. Anexo Formulario Solicitud / Modificación / Baja de Usuarios), que completará y firmará cada usuario en particular, con la aprobación de la autoridad que corresponda. El formulario puede ser bajado desde el siguiente sitio: http://www.portal.min/usuarios.pdf.


5.4.5. Completo el formulario, debe ser presentado al Area Informática, para su aprobación.


5.4.6. Toda vez que el Centro de Cómputos modifique el perfil de un usuario, deberá registrar el cambio en sus archivos administrativos.


5.4.7. Por último, se debe proveer al nuevo usuario la información necesaria para comenzar a utilizar el sistema. Dicha información refiere al nombre de usuario y a la contraseña del recurso solicitado. La misma se entrega en un formulario sellado (Ver 7.2. Anexo Formulario Entrega de Contraseñas). Así finaliza el proceso de modificación.


5.4.8. Cabe aclarar que el formulario se completa solamente de manera personalizada, mientras que la nota/memorandum puede que sea conjunta, es decir que contenga la solicitud de modificación de varios usuarios a la vez.


Antes esto, es necesario otorgarle a cada nota/memorando un número interno, que permitirá operativizar su búsqueda en la documentación en papel.


Teniendo en cuenta que varios formularios pueden remitir a una misma nota/memorando, es fundamental que cada uno contenga el número interno al que se remite, para obtener un mejor control.


5.4.9. Por cambio de funciones


En los casos en los que un usuario cambie de función, o pase a depender de otra área o sección del Ministerio, se debe modificar el perfil con el que contaba hasta el momento. Para ello se seguirán los siguientes pasos:


a) La autoridad del usuario cuya cuenta debe ser modificada deberá enviar un memorandum con la información detallada a continuación, lo firmará y lo remitirá a Coordinación Informática.


Información a completar en el formulario:


• Datos del usuario


• Tipo de Modificación


• Fecha de Modificación: Si es "Programada" o "Inmediata" según corresponda. En caso de tratarse de una modificación programada, se indicará asimismo la fecha prevista.


b) El Responsable de Seguridad Informática controlará la existencia de toda la información requerida en el formulario y evaluará el posible impacto de la baja en otras áreas de incumbencia (por ej, la necesidad de solicitar cambios de perfiles como consecuencia).


c) Luego de finalizadas las tareas operativas, el sector a cargo de la administración de usuarios deberá Informar al superior que solicitó la modificación.


d) La nueva autoridad del usuario cuya cuenta debe ser modificada para ser utilizada eficazmente en su nueva sección de trabajo, completará el formulario de "Solicitud de Modificación de usuario" (Ver 7.1. Anexo Formulario Solicitud / Modificación / Baja de Usuarios) con la información detallada a continuación, lo firmará y lo remitirá a Coordinación Informática.


Información a completar en el formulario:


• Datos del usuario


• Tipo de Modificación


• Fecha de Modificación: Si es "Programada" o "Inmediata" según corresponda. En caso de tratarse de una modificación programada, se indicará asimismo la fecha prevista. Se continuarán con los mismos pasos b) y c), antes detallados.


5.5. ACCIONES POR INCUMPLIMIENTO


5.5.1 BLOQUEO DE UN USUARIO


Esta Coordinación de Informática cuenta con una estructura de recursos de hardware que permite realizar un monitoreo de las actividades cada servidor, motivo por el cual ante la violación de cualquiera de los puntos anteriormente descriptos, sin previo aviso se procederá a:


a) Borrado de todo tipo de archivo y/o acceso no no permitido, Ej. Música, Messenger videos, software sin licencia y otros.


b) Bloqueo de la cuenta de usuario y restricción de acceso a la red del organismo, situación que podrá revertirse, mediante la solicitud de reconexión de servicio.


5.5.2 RECONEXION DE UN USUARIO


La Reconexión de un Usuario deberá ser solicitada cuando éste último no haya cumplido con alguna de las normativas especificadas en el manual de Políticas para Internet u otras. Cuando esto sucede, al usuario se le restringe el acceso al servidor y para recuperarlo debe solicitar la reconexión.


Para esto, es necesario que se presente al área de Coordinación Informática, un memorandum especificando las causas que provocaron la restricción al servidor y solicitando la reconexión.


Dicho memorandum debe estar firmado por el solicitante y por el Responsable de la Secretaría a la que pertenece el usuario.


5.5.3 RECOMENDACIONES GENERALES


a) Se sugiere eliminar de los servidores archivos viejos, inútiles a la fecha y/o que no se utilicen.


b) Se recuerda que todos los archivos que se encuentran en discos de terminales NO son responsabilidad de está Coordinación. En caso de necesitarse un resguardo especial, éste debe solicitarse en forma puntual.


c) Para los usuarios de los Edificios Av. De Mayo, Misiones, 25 de Mayo y Paraná, remitir acciones y consultas a los responsables informáticos de cada sede.


5.6. BAJA DE UN USUARIO


5.6.1. POR DESVINCULACION


Cuando un empleado se desvincule del Organismo, la baja de su cuenta se efectuará mediante los siguientes pasos:


a) La Autoridad que tenga a su cargo al usuario que se desvincula, deberá completar el formulario de "Solicitud de baja de usuario" (Ver 7.1. Anexo Formulario Solicitud / Modificación / Baja de Usuarios) con la información detallada a continuación, lo firmará y lo remitirá a Coordinación Informática.


Información a completar en el formulario:


• Datos del usuario


• Tipo de baja


• Fecha de baja: Si es "Baja Programada" o "Baja Inmediata" según corresponda. En caso de tratarse de una baja programada, se indicará asimismo la fecha prevista de baja.


b) El Responsable de Seguridad Informática realizará lo siguiente:


- Controlar la veracidad de toda la información requerida en el formulario


- Completar la información relacionada a "Cuentas a dar de baja", detallando las cuentas a eliminar e indicando a qué sistema/ambiente pertenecen.


- Firmar el formulario y solicitar la baja al sector a cargo de la administración de usuarios.


c) El sector a cargo de la administración de usuarios procederá a realizar las tareas operativas para luego:


- Firmar el formulario y remitirlo al Responsable de Seguridad Informática


- Informar al Responsable solicitante.


Es importante que el paso (1) se realice con suma URGENCIA al momento de decidirse o recibirse la comunicación indicando la desvinculación.


NOTA: Todos los días 30 de cada mes, el Area de Recursos Humanos y la de Pasantías, deberán enviar a Coordinación de Informática, un listado actualizado de los agentes y personal que ingresen al Ministerio o se desvinculen del mismo, a fin de comparar con las altas y bajas de usuarios que se efectivizan en el Centro de Cómputos.


6. MANEJO INTERNO DE ADMINISTRACION DE USUARIOS


6.1. Recepción de Documentación


Para el inicio del procedimiento de alta-baja-modificación, se debe presentar al Centro de Cómputos los siguientes dos documentos, que deben estar firmados y sellados por el responsable del área o sector emisor:


a. Memorandum


b. Formulario de Solicitud de Usuario


a. El Memorandum debe ser presentado por duplicado, uno para Coordinación de Informática y el otro que se sellará y se devolverá para que el solicitante tenga un comprobante de la recepción del trámite. En Coordinación Informática se hará una fotocopia del memorandum y entregará dicha copia al Centro de Cómputos pare que se inicie el proceso del trámite solicitado.


b. Asimismo, el Centro de Cómputos debe recibir conjuntamente con el Memorandum respectivo, el Formulario de Solicitud del usuario/s. En el mismo, se debe detallar los mismos datos que se solicitan en el memorandum, junto a los datos personales del usuario. Si lo solicitado entre el memorandum y la solicitud no coincide, se deberá pedir al solicitante que rehaga la documentación. Hasta que esto no se cumpla no se dará curso a lo solicitado.


6.2. Manejo Interno de Documentación


Una vez ingresada la Documentación, Coordinación Informática y el centro de Cómputos, se encargarán de procesar la información de la siguiente manera:


a. Dar curso a la Solicitud


b. Cargar en "Base Solicitud de Usuarios"


c. Aviso al Usuario


d. Archivo de la Documentación


a. Los Administradores del Sistema, son los encargados de actualizar los servicios que la solicitud pide.


b. Posteriormente la información será cargada al Sistema de Solicitud de Usuarios en donde se podrá consultar la información necesaria de cada usuario en cuestión.


c. Es muy importante que el Usuario que hace el requerimiento sea avisado a la brevedad sobre el destino de la solicitud.


d. Tanto el memo, como la solicitud deberán ser archivadas, por los encargados Administrativos de la Documentación en sus respectivos biblioratos. (Ver. 6.4 ARCHIVO DE DOCUMENTACION (MEMORANDUM/ FORMULARIOS))


6.3. BASE DE DATOS DE DOCUMENTACION


Es un programa diseñado para la carga de documentación de altas/modificaciones/bajas de Usuarios. Con el mismo se podrá consultar la información respectiva de cada uno de los usuarios que se encuentra en la red del Ministerio.


6.4. ARCHIVO DE DOCUMENTACION (MEMORANDUM/FORMULARIOS)


Como del Memorandum pueden depender varias solicitudes, se le debe asignar un número interno, que será escrito también en cada formulario que derive de dicho memorandum, y deben ordenarse en el archivo de acuerdo a dicho número.


En tanto, los formularios que son personalizados, uno para cada usuario, deben archivarse por orden alfabético en sus respectivas carpetas.


De esta manera, al buscar un formulario, se puede detectar rápidamente el memorandum que lo acompaña, mediante el número interno que le fue asignado, operativizando y agilizando la búsqueda de la documentación en papel.


6.5. ESCASEZ O PRECARIEDAD EN LA DOCUMENTACION


En caso de efectuar un alta, cambio o baja de usuario, sin previa entrega de Formulario y Memorandum a Coordinación Informática, los administradores deben avisar a los encargados de los archivos (papel y base de datos), para que tomen las medidas correspondientes para adquirir la documentación.


Este caso solo se acepta de manera excepcional si la solicitud es expedida por algún alto funcionario que manifiesta urgencia en el requerimiento.


Caso contrario, todas las altas, cambios o bajas de usuario deben solicitarse mediante memorandum y formulario con anterioridad.


Sino existiese la documentación de usuarios ya existentes, se les solicitará que regularicen su situación, o en caso contrario en 48 hs. se dará de baja su cuenta automáticamente.


Si aún así no se regulariza la documentación, desde Coordinación Informática se le facilitará al usuario el formulario y memorandum, para que proceda a completarlo y hacerlo firmar por la autoridad correspondiente.


7. ANEXO


7.1 SOLICITUD DE ALTA/MODIFICACION/BAJA DE USUARIOS



Instructivo para Completar Solicitud de Alta/Modificación/Baja de Usuario


1. Hacer un círculo a la opción que corresponda.



Alta: Cuando se solicita el ingreso al sistema de una nueva persona


Modificación: Cuando la persona dispone de un usuario de red/correo, pero necesita cambiar su perfil en cuanto a ingresos a sistemas específicos, servicios, etc.


Baja: Solo se utiliza cuando la persona se desvincula del organismo


2. Debe completarse con la fecha de presentación del trámite. Es un dato indispensable para su correcta administración.


3. Este número de memorandum solo debe ser completado por Coordinación Informática.


4. Este número de Ref. interna solo debe ser completado por Coordinación Informática.


5. Hacer una cruz, en el edificio donde desempeña su actividad. Ejemplo:



6. Escribir apellido y nombres completos: Por ej: Pérez, Martín Alejandro; o, Ruiz Castro,


7. NΊ de DNI: Es indispensable para hacer efectiva el alta / modificación / baja.


8. Especificar el nombre del área a la cual pertenece el usuario.


9. Especificar el número y el ala (Moreno/Belgrano/Centro) a la cual pertenece el usuario.


10. Especificar el/los números de internos donde ubicar al usuario.


11. Si la persona utiliza un usuario genérico (compartido con otras personas) debe señalarse el "no". Pero si entrara a la PC con su nombre, es decir iniciara sesión con su usuario, debe señalar con una cruz en "si".


12. Si la persona no utiliza internet debe señalarse el "no". Pero si lo hiciese, debe señalar con una cruz en "si".


Solo puede señalar en "si", si el usuario tiene acceso a red con su propio nombre.


13. Si la persona utilizara su propia cuenta de correo electrónico debe señalarse el "si". De modo contrario, sino la desea utilizar, debe señalar con una cruz en "no".


14. Si el usuario necesitase para desarrollar su trabajo cotidiano, algún recurso compartido (un espacio en un servidor de informática), debe señalarse el "sí" y debe especificar abajo a qué recurso (nombre de carpeta) necesita acceder. Si no lo necesita debe marcar el "no".


15. Si el usuario necesita tener acceso a algún sistema específico (Sisex, Actuaciones, intimaciones, etc.) debe marcarse con una cruz en el casillero correspondiente. Debe llenarse teniendo en cuenta lo siguiente:


Ejecución: Permite acceder a todas la opciones estándar del sistema.


Modifica: Este permiso depende del sistema al que se refiere.


Solo Lectura: Le permite al usuario solo la consulta en el sistema.


Desglose/agregación: Es una opción que sólo se utiliza en el Sistema Sisex.


Si no necesita utilizar ningún sistema, no se debe completar el cuadro.


16. El Jefe o director el área debe firmar y aclarar su firma para aprobar la solicitud del usuario


17. El usuario solicitante debe firmar el formulario.


18. Al igual que los puntos (3) y (4), este recuadro debe ser completado por el centro de Cómputos, no por el usuario solicitante.


———


NOTA: En el caso del Alta de un nuevo Usuario, es importante que al término de 24 hs. de entregado el memorandun y el formulario, el usuario solicitante pase a retirar por el área de Coordinación Informática, su nombre de usuario, y contraseñas.


7.2. FORMULARIO DE ENTREGA DE CONTRASEÑAS




CONTENIDO


1. OBJETIVO


2. ALCANCE


3. RESPONSABILIDADES


3.1. PROPIETARIO


3.2. RESPONSABLES DE ACTUALIZACION


4. REGIMEN DE REVISION Y ACTUALIZACION


5. DESARROLLO


5.1. REQUISITOS DE RESGUARDO


5.2. CARACTERISTICAS DEL RESGUARDO


5.3. ESQUEMA DE RESGUARDO


5.4. ROTULADO DE DISPOSITIVOS FISICOS


5.5. ALMACENAMIENTO DE LAS COPIAS


5.6. CONTROL DEL PROCESO DE RESGUARDO


5.7. VERIFICACION DE LA RESTAURACION


6. PROCEDIMIENTOS DETALLADOS DE RESGUARDO


6.1. RESGUARDO DE RUTINAS DE BACK-UP/RESTORE


6.2. ALMACENAMIENTO DE CINTAS


1. OBJETIVO


Definir la información del Organismo que será resguardada y establecer un esquema para su resguardo. Definir los controles para verificar el correcto desarrollo de los resguardos, así como pruebas periódicas de recuperación, con el objeto de asegurar la posibilidad de recuperar la información del Organismo en caso de ocurrir algún incidente que provoque la pérdida de información


2. ALCANCE


El presente procedimiento será aplicado a toda la información almacenada en los equipos de procesamiento del Organismo.


3. RESPONSABILIDADES


3.1. PROPIETARIO


El propietario del presente procedimiento es Coordinación de Informática. Sus responsabilidades son:


- Establecer las medidas de seguridad necesarias para garantizar el adecuado almacenamiento del presente documento.


- Definir los perfiles que tendrán acceso al documento.


- Asegurar la accesibilidad del documento para quienes necesiten consultarlo.


- Comunicar la existencia del documento y asesorar sobre el mismo a los responsables de su cumplimiento.


- Solicitar actualizaciones fuera del esquema normal.


3.2. RESPONSABLES DE CUMPLIMIENTO


Es responsable del cumplimiento del presente procedimiento son los administradores de la Tecnología del Centro de Cómputos, quienes están a cargo de realizar el resguardo de información.


3.3. RESPONSABLES DE ACTUALIZACION


El responsable de la actualización del presente procedimiento es Coordinación de Informática, Grupo Administración. Su responsabilidad es revisar y actualizar en caso que corresponda, el presente documento de acuerdo al esquema de revisión y actualización establecido y a las solicitudes efectuadas por el responsable del mismo.


4. REGIMEN DE REVISION Y ACTUALIZACION


El presente documento será revisado semestralmente y actualizado en el caso de detectarse la necesidad de efectuar modificaciones que permitan mantenerlo actualizado en relación a la realidad de la estructura funcional y del ambiente informático.


Por otra parte, se realizarán las modificaciones que sean necesarias en el caso que se produjeran cambios que lo requieran, fuera de las revisiones programadas.


5. DESARROLLO


A continuación se definen en primera instancia, los requisitos de resguardo que se adoptarán para los diferentes tipos de información del Organismo. Luego se establece el esquema de resguardo para cada tipo de información, así como su rotulado y almacenamiento.


5.1. REQUISITOS DE RESGUARDO


A continuación se detallan los requisitos de resguardo para cada tipo de información, de acuerdo a lo manifestado por sus propietarios. Dichos requisitos serán los que determinen el tipo de resguardo a ser implementado para la información.


















REQUISITOS DE RESGUARDO


 


Tipo de Información


Dueño (*)


Requisitos de resguardo


Observaciones


 


 


 


 



(*) De acuerdo con lo establecido en la Política de Seguridad de la Información


Los requisitos de resguardo pueden ser, por ejemplo, asegurar la recuperación de la información del día anterior, la necesidad de guardar copias de resguardo Historiaoacute;ricos por un determinado período, etc.


5.2. CARACTERISTICAS DEL RESGUARDO


5.2.1. PERIODICIDAD


Para cada tipo de información se establece la periodicidad con la cual se realizarán los resguardos.


Los períodos establecidos son:


• ANUAL: el resguardo se realiza una vez al año, generalmente el último día hábil


• MENSUAL: el resguardo se realiza una vez al mes, generalmente el último día hábil.


• SEMANAL: el resguardo se realiza una vez a la semana, generalmente el último día hábil.


• DIARIO: el resguardo se realiza una vez al día.


• OTROS: destinado al tipo de información que requiere ser resguardada con mayor frecuencia.


5.2.2. TIPO


Los resguardos pueden ser de diferente tipo de acuerdo a la información que contienen respecto del resguardo anterior. A continuación se definen los tipos de resguardo utilizados:


• COMPLETO: se resguarda toda la información


• INCREMENTAL: se resguarda la información que se haya incorporado desde el último resguardo realizado


• DIFERENCIAL: se resguarda sólo la información que se haya modificado desde el último resguardo realizado.


5.2.3. ROTACION DE LAS COPIAS


Se establece el siguiente criterio para la reutilización de los dispositivos físicos de resguardo:


• Copias anuales: se conservarán todas las copias anuales, por lo que dichos dispositivos no tienen rotación.


• Copias mensuales: se mantienen 12 copias anuales, por lo que su rotación es anual.


• Copias semanales: se mantienen cuatro copias semanales, por lo que su rotación es mensual.


• Copias diarias: se mantienen cinco copias diarias (o bien la cantidad de días hábiles en una semana), por lo que su rotación es semanal.


Los dispositivos serán reutilizados un máximo de 12 veces.


A continuación se presenta una planilla de control de reutilización de cintas:



Aclaraciones:


- Utilización máxima se refiere a la cantidad de veces que el proveedor del dispositivo aconseja utilizarlo como máximo.


- "aaaa" corresponde al año.


Los dispositivos que deban ser dados de baja debido a la imposibilidad de reutilizarlos serán eliminados de acuerdo a lo establecido en la Política de Seguridad en relación a la eliminación segura de medios que contienen información.


5.3. ESQUEMA DE RESGUARDO


A continuación se describe el esquema de resguardo de cada tipo de información definida en 5.1. REQUISITOS DE RESGUARDO:



El esquema planteado es sólo un ejemplo.


Consideraciones:


- La "Ubicación" se refiere al equipo en el cual se ubica físicamente la información.


- En cada caso, se deberá describir el horario en el que se realizará el resguardo. En los casos en que no aplique un tipo de resguardo, se completará con "N/A".


- El "Dispositivo" se refiere al soporte físico en el cual se resguardará la información.


El "Responsable" es la persona que deberá garantizar que cada resguardo se realice de forma adecuada, en tiempo y forma.


5.4. ROTULADO DE DISPOSITIVOS FISICOS


Los resguardos serán realizados en cinta magnética.


información). En primera instancia se define la siguiente codificación para cada tipo de información:
















Tipo de información


Ubicación


Codificación (*)

     
 

 


 



(*) Consiste en tres letras


Cada unidad de resguardo contará con una etiqueta en la que se escribirá lo siguiente:



5.5. ALMACENAMIENTO DE LAS COPIAS


Las copias de resguardo serán almacenadas de acuerdo al siguiente esquema:


• Las copias anuales y mensuales se trasladarán para su almacenamiento en el sitio externo Tener en cuenta que el mismo debe contemplar las medidas de seguridad física adecuadas para la conservación de las copias y que las mismas deben permanecer accesibles en caso de ser necesario recuperarlas.


El responsable de su traslado, a dicho sitio y su recupero para la reutilización es el Responsable e Seguridad Informática Ing. Alberto J. Chedufau.


Durante el traslado se tomarán las medidas de seguridad correspondientes para resguardar los dispositivos de posibles robos o daño físico.


A continuación se detalla el personal con acceso a las copias de resguardo:
















Sitio de resguardo


Ubicación


Personal autorizado


Caja ignífuga


 


 


Sitio externo


 


 



5.6. CONTROL DEL PROCESO DE RESGUARDO


Con el objeto de asegurar la correcta ejecución de los procesos de resguardo de información del Organismo, cada responsable de resguardo, definido en 5.3. ESQUEMA DE RESGUARDO, se verificará la ejecución de los mismos mediante las herramientas definidas a continuación:
















Tipo de información


Herramienta de


resguardo


Herramienta de control del proceso de resguardo


 


 


 


 


 


 



Ejemplos de herramientas de control son los logs del sistema operativo o de la herramienta de resguardo, o consolas propias de dichas herramientas.


Como resultado de este control, el responsable de cada resguardo completará la siguiente planilla:



(*) Indicar si el proceso se ha completado en forma correcta (C) o (I).


Esta planilla debe ser completada luego de finalizado cada resguardo, indicando si el proceso concluyó correctamente, o bien si presentó problemas y qué acciones fueron tomadas.


5.7. VERIFICACION DE LA RESTAURACION


Se realizará la verificación de la recuperación de las copias de resguardo de acuerdo al procedimiento detallado en el punto 5.2. "PROCEDIMIENTOS DETALLADOS DE RECUPERACION" del "Procedimiento - Recuperación de información", con el siguiente esquema para cada tipo de información:


• Semanalmente se restaurará una copia diaria realizada


• Trimestralmente se restaurará la última copia mensual realizada


La recuperación se realizará en un ambiente de prueba para evitar que dicho proceso afecte al ambiente de producción.


Como resultado de la prueba, se completará la siguiente planilla:



6. PROCEDIMIENTOS DETALLADOS DE RESGUARDO


A continuación se describen los procesos de resguardo para cada una de las plataformas o sistemas.


6.1. Resguardo de Rutinas de Back-up/Restore


Los contenidos de cada sistema o desarrollo deben estar correctamente resguardados a través de procedimientos específicos de almacenamiento de datos. A continuación se detallan los procedimientos de resguardo para cada uno de los sistemas:


• Sistema CONPRE:


En estos momentos el sistema Conpre se encuentra en modo sólo lectura para realizar consultas. Dicho sistema fue reemplazado por el SLU.


• Bases de datos:


Microsoft SQL SERVER (nombre del motor de base de datos)


Mediante programación de trabajos a través del propio motor de base de datos, se realiza una plan de mantenimiento que procede a realizar una copia de seguridad, generando un archivo de transacciones por hora (desde las 09:00 hasta las 21:00), de cada base de datos alojada en el servidor.


De esta forma se puede recuperar una base de datos cuando sea necesario en cualquier punto que se lo desee ya que el recupero es realizado a través de la lectura de un archivo de transacciones.


A las 22:00 hs. de cada día hábil se procede a realizar el backup full de cada base de datos.


Todo los archivos de transacciones y copia full de la base son resguardados al finalizar el día y exportados a dos servidores (uno dedicado y otro como redundancia - ambos cuentan con redundancia de disco local RAID 5) dedicado a contener todas las copias diarias del mes en curso.


Microsoft ACCESS y otros motores de BBDD


Mediante comandos del sistema operativo se procede a realizar una copia de seguridad completa (de todos aquellos sistemas que cuenten con una base de datos en Microsoft Access u algún otro motor de base de datos) a las 12:00, 15:00; 18:00 y 21:00 hs.


El destino de las copias de seguridad para cada hora de ejecución no es el mismo, motivo por el cual puede llegar a recuperarse en caso que sea necesario cualquier imagen de la base en los horarios indicados anteriormente dentro del mismo día.


• Archivos residentes en servidores del Centro de Cómputos, incluidos los anteriores:


Diariamente:


Se realiza diariamente un backup diferencial en un servidor configurado al efecto, con arreglo de discos RAID 5 para tolerancia a fallas. Esta clase de copia automática se ejecuta una vez por día durante todos los días hábiles del mes en curso.


Mensualmente:


Una vez por mes se ejecuta un vuelco en cintas de backup, de lo detallado en el punto anterior. Dicho juego de cintas se guardan durante seis meses.


Semestralmente:


En este lapso de tiempo se reutilizan las cintas mensuales. El juego de cintas semestrales se guarda hasta fin del año en curso.


Anualmente:


A fin de año se guarda para siempre el último juego de cintas mensuales del año. Este juego pasa a formar parte del archivo Historiaoacute;rico.


Almacenamiento de cintas:


Las cintas que contienen los backups full del Centro de Cómputos son almacenadas en una caja fuerte que posee Coordinación de Informática en el Banco Nación.


La Coordinación de Informática no se hace responsable del resguardo de la información contenida en discos locales de computadoras de escritorio.


6.2. Almacenamiento de Cintas


(Resguardo mensual del Centro de Cómputos)


- CONTROLADORES DE DOMINIO (sds_domain_1.Iocal)


Servidor: Ramses


Funciones que desempeña: Controlador de dominio - DNS Server - Wins Server


Carpeta de resguardo: adbackup


Ubicación de la carpeta: D:





CONTENIDO


1. OBJETIVO


2. METODOLOGIA DE TRABAJO PARA SOLICITUD DE INSUMOS


2.1. SISTEMA DEL SOFTWARE UTILIZADO


2.2. CARGA INICIAL DE INSUMOS INFORMATICOS EN EXISTENCIA


2.3. SOLICITUD DE PEDIDOS


3. IMPLEMENTACION


3.1. RETIRO DE INSUMOS DEL DEPOSITO SALGUERO


3.2. CONTROL Y SEGUIMIENTO DEL REQUERIMIENTO DE LA SOLICITUD


3.3. ACTUALIZACION DE STOCK EN EL SISTEMA SUMA


3.4. ASEGURAMIENTO EN LA ENTREGA DE INSUMOS A CADA UNA DE LAS AREAS SOLICITANTES


3.5. CONFORMIDAD DE LOS INSUMOS RECIBIDOS


4. ACLARACIONES


5. ANEXOS


5.1. FORMULARIO DE SOLICITUD DE INSUMOS


5.2. INSTRUCTIVO PARA COMPLETAR EL FORMULARIO DE SOLICITUD DE INSUMOS


PROCEDIMIENTO DE ADMINISTRACION DE INSUMOS INFORMATICOS


1. OBJETIVO


El presente manual tiene por objeto normatizar la operatoria implementada por la Coordinación de Informática para la generación de un archivo de stock de insumos informáticos que se encuentran disponibles en el "Depósito Salguero" con la posibilidad de efectuar las transacciones de: Altas, Bajas, Modificaciones de los Cαtedraálogos existentes así como también el control del stock de dicho depósito.


Para un mejor seguimiento de los pedidos que ingresan a Coordinación de Informática se diseñó un "Formulario de Solicitud de Insumos Informáticos", cuyo contenido e instructivo se detallan en las próximas páginas de este manual, como también se podrá visualizar un ejemplo del mismo para una mejor comprensión en su confección.


2. METODOLOGIA PARA LA SOLICITUD DE INSUMOS


2.1. Sistema del software utilizado


El software utilizado es el sistema SUMA mediante el cual se realiza la registración de los datos correspondientes a las Ordenes de Compra adjudicadas por el Ministerio de Desarrollo Social a sus proveedores.


Permite determinar qué Cαtedraálogos suministra cada Proveedor, Cαtedraálogos existentes para el suministro de recursos de hardware con sus cantidades, fecha en que se efectuó la recepción de estos materiales en el depósito Salguero.


SUMA permite realizar diversos reportes que colaboran en la difícil tarea de controlar la existencia en stock y su permanente actualización.


2.2. Carga inicial de Insumos Informáticos en existencia


Información necesaria para realizar dicha carga


• Contar con la documentación en este caso con las Ordenes de Compra recibidas en Depósito Salguero.


• Ingresar al SUMA y efectuar la carga de las tablas del sistema. En estas tablas se ingresarán todos los Cαtedraálogos de las diversas empresas proveedoras y los siguientes campos:


- Código (Ingresado por Coordinación de Informática)


- Descripción


- Cantidad


- Fecha de orden de compra


- En el campo observaciones se ingresa: NΊ de Orden de Compra


2.3. Solicitud de pedidos


La solicitud deberá efectuarse al área de Coordinación de Informática cumplimentando el siguiente Procedimiento:


a- El sector solicitante deberá completar el formulario (Ver ANEXOS) designado para la solicitud de Insumos Informáticos (original y copia).


b- El formulario es recibido y en Coordinación de Informática se completan los datos (original y copia).


c- Coordinación de Informática entrega copia al solicitante y trabaja con el formulario original. Se realiza un análisis de la factibilidad de existencia en stock, de existir disponibilidad se dará curso al pedido, en caso de no tener existencia en stock, se consultará al proveedor quien indicará el tiempo en que podrá darse cumplimiento a lo solicitado.


d- El personal de Coordinación de Informática efectuará los controles de las autorizaciones necesarias para el retiro de insumos.


e- Al momento de retirar los insumos el solicitante deberá contar con la copia del formulario de Solicitud de Insumos.


En Coordinación de Informática el solicitante retira el material firmando su conformidad y fecha de recepción del material.


3. Implementación


3.1. Retiro de Insumos del Depósito Salguero


El retiro de insumos del depósito Salguero se efectuará con una frecuencia Semanal el día estipulado por esta Coordinación de Informática.


3.2. Control y seguimiento del requerimiento de la solicitud


El control se efectúa desde que el insumo llega al depósito Salguero, para ello es necesario que personal de Coordinación de Informática se traslade al depósito, efectúe el control de las Ordenes de compra, y conforme se retiran los remitos correspondientes.


Cumplido este paso podrán semanalmente retirarse los insumos solicitados por las áreas usuarias y dar cumplimiento a las solicitudes.


3.3. Actualización de Stock en el sistema SUMA


Los remitos retirados de depósito Salguero llegan a Coordinación de Informática y son ingresados a sistema SUMA realizándose el proceso de actualización de la existencia de stock.


3.4. Aseguramiento en la entrega de insumos a cada una de las áreas solicitantes


Cumplido el punto 3.1 donde se realiza el retiro de los insumos, las áreas solicitantes están en condiciones al día siguiente de retirar su pedido en Coordinación de Informática.


3.5. Conformidad de los insumos recibidos


Al momento del retiro de los insumos solicitados por cada una de las áreas solicitantes, las mismas controlarán los insumos retirados y se les hará entrega del FORMULARIO DE SOLICITUD DE INSUMOS que deberán firmar prestando así su conformidad evitando reclamos.


4. Conformidad



5.2. Instructivo para completar el Formulario de Solicitud de Insumos


Campo-1 Número de Solicitud: Campo de uso interno. Es ingresado por Coordinación de Informática.


Campo-2 Edificio: Indicar con una cruz el edificio desde el cual surge el pedido de insumos.


Campo-3 Sector/Oficina Solicitante: Se debe indicar el sector desde el cual surge la solicitud de insumos. Si se utilizan siglas para el sector se debe aclarar el nombre completo.


Campo-4 Piso: Indicar el piso del sector solicitante de insumos.


Campo-5 Tel.: Indicar el número de teléfono o interno del sector solicitante.


Campo-6 Nombre del Responsable: Indicar el nombre del responsable del sector solicitante de insumos.


Campo-7 Fecha: Fecha de la solicitud de Insumo, en formato DD/MM/AA.


Campo-8 Firma y aclaración del solicitante: Persona encargada de llevar el formulario.


Campo-9 Firma y aclaración del responsable del sector solicitante: La solicitud de Insumos a Coordinación de Informática únicamente la podrán realizar los Sres. Secretarios, Subsecretarios, Directores Generales, Directores y Coordinadores de áreas. Personal con FIRMA AUTORIZADA.


Campo-10 Nombre y Apellido recepción en Coordinación de Informática: Deberá especificar el nombre y apellido del receptor de la solicitud en Coordinación de Informática.


Campo-11 NΊ de Contratación: Campo de uso interno. Es ingresado por Coordinación de Informática.


Campo-12 NΊ de Orden de Compra: Campo de uso interno. Es ingresado por Coordinación de Informática.


Campo-13 Código de Insumo: Código del Insumo que está solicitando tal como figura en la tabla del sistema. Será agregado por Coordinación de Informática, ya que cuenta con acceso a Tabla.


Campo-14 Modelo de Equipo: En este ítem que debe ser completado por el solicitante, se detallará la identificación del insumo pedido.


Campo-15 Cantidad Solicitada: El solicitante debe completar especificando la cantidad en unidades de cada insumo pedido.


Campo-16 Cantidad Autorizada: Especificar la cantidad en unidades de cada insumo que fueron autorizadas. Este campo debe ser completado exclusivamente por DGA (Dirección General de Administración).


Campo-17 Caja Chica: Campo de uso interno, que es ingresado por Coordinación de Informática. Se coloca "Exp." Si al insumo se le da curso por Expediente; o un "Sí", si se realiza por caja chica.


Campo-18 Firma y aclaración autorizante de Coordinación Informática: Autorización del Responsable de Coordinación de Informática, quien con su firma y aclaración respalda la solicitud realizada.


Campo-19 Firma y aclaración de Solicitante (quien recibe material): Debe registrar en el formulario (apellido y nombre) de la persona que recibe el insumo.


Campo-20 Fecha de Recepción: Cuando el solicitante retira el material, el personal de Coordinación de Informática ingresa manualmente la fecha del día en formato DD/MM/AA



CONTENIDO


1. OBJETIVO


2. ALCANCE


3. RESPONSABILIDADES


3.1. PROPIETARIO


3.2. RESPONSABLES DE CUMPLIMIENTO


3.3. RESPONSABLES DE ACTUALIZACION


4. REGIMEN DE REVISION Y ACTUALIZACION


5. DESARROLLO


5.1 ACTUALIZACION DEL PORTAL DEL MINISTERIO


5.1.1. A NIVEL DISEÑO, SOFTWARE Y BASES DE DATOS RELACIONADAS


5.1.2. A NIVEL ACTUALIZACION DE DATOS


5.1.3. A NIVEL SECCION COMPRAS


5.2. A NIVEL SERVIDORES Y TERMINALES


5.3. A NIVEL DE SERVICIO DE NAVEGACION


5.4. A NIVEL DE SERVICIO DE CORREO ELECTRONICO


1. OBJETIVO


Desarrollar y mantener actualizado el Portal del Ministerio.


Definir los controles para evitar la fuga o pérdida de la información del Organismo.


Los lineamientos para cumplir con este procedimiento, se encuentran descriptos en la Res. 1235/ 06 de la S.C.


2. ALCANCE


El presente procedimiento será aplicado a toda la información almacenada en los equipos de procesamiento del Organismo y a todos los usuarios que trabajan con la red de sistemas del Ministerio de Desarrollo Social.


3. RESPONSABILIDADES


3.1. PROPIETARIO


El propietario del presente procedimiento es el Ing. Alberto Chedufau. Sus responsabilidades son:


- Establecer las medidas de seguridad para garantizar el adecuado almacenamiento del presente documento.


- Definir los perfiles que tendrán acceso al documento.


- Asegurar la accesibilidad del documento para quienes necesiten consultarlo.


- Comunicar la existencia del documento y asesorar sobre el mismo a los responsables de su cumplimiento.


- Solicitar actualizaciones fuera del esquema normal.


3.2. RESPONSABLES DE CUMPLIMIENTO


Son responsables del cumplimiento del presente procedimiento todos los empleados del Organismo, así como terceros que hagan uso de cualquier recurso informático perteneciente al mismo.


3.3. RESPONSABLES DE ACTUALIZACION


El responsable de la actualización del presente procedimiento es el Ing. Alberto Chedufau. Su responsabilidad es revisar y actualizar en caso que corresponda, el presente documento de acuerdo al esquema de revisión y actualización establecido y a las solicitudes efectuadas por el propietario del mismo.


4. REGIMEN DE REVISION Y ACTUALIZACION


El presente documento será revisado semestralmente y actualizado en el caso de detectarse la necesidad de efectuar modificaciones que permitan mantenerlo actualizado en relación a la realidad de la estructura funcional y del ambiente informático. Por otra parte, se realizarán las modificaciones que sean necesarias en el caso que se produjeran cambios que lo requieran, fuera de las revisiones programadas.


5. DESARROLLO


5.1 Actualización del portal del Ministerio


La actualización del portal del Ministerio, se debe llevar adelante a través de distintos niveles. A saber:


5.1.1. A nivel diseño, software y bases de datos relacionadas:


El sector responsable de estos contenidos es la Unidad Coordinación, dependiente de la Unidad Ministro. Este sector indica los cambios estructurales a la Coordinación Informática y el equipo de Desarrollo Aplicaciones Internet, los lleva a cabo.


5.1.2. A nivel actualización de datos:


El sector responsable de mantener actualizados los contenidos de información de la portada, es la Oficina de Prensa. La misma opera un sistema de carga y edición de datos, que actualiza los contenidos del portal de Internet del Ministerio.


5.1.3. A nivel Sección Compras:


El sector Compras ejecuta dos clases de transferencia de información:


Por un lado, envía electrónicamente a una determinada cuenta de correo de la Coordinación Informática, operada por personal especializado en esta clase de carga de datos, la información de pliegos a publicar. A partir de los pliegos, se extractan los datos de: Fecha de apertura, motivo de la licitación o contratación, área involucrada y otros.


Por el otro, envía en papel copias de documentación sobre cuadros comparativos de precios, órdenes de compra, actas de apertura, actas de adjudicación, circulares modificatorias.


5.2. A nivel de Servidores y Terminales


El servicio de acceso a los servidores se encuentra regulado de acuerdo a las posibilidades de seguridad y de prestación del equipamiento existente.


La Coordinación de Informática resuelve, según sea:


• Restringir el almacenamiento de archivos de música (.mp3, .wma, etc.), videos (.avi, .mpg, etc.), y todos aquellos archivos personales y/o extra laborales en los servidores del Ministerio. Esta situación impacta en forma negativa en las operaciones e instalaciones.


• De encontrarse este tipo de archivos serán eliminados sin aviso ni contemplación, y al usuario responsable de los mismos le será restringido el acceso al almacenamiento en los servidores del Ministerio y se informará a cada jefe de Sector cada hecho con los datos del usuario.


• No se deben compartir recursos locales en la PC (Discos Rígidos, Carpetas, etc.). En caso de necesitar compartir archivos se deberá solicitar a Coordinación Informática el acceso a un recurso compartido en el servidor, ya que los archivos contenidos en este último poseen un resguardo al realizarle periódicamente backups.


• No se deben instalar programas (software) sin autorización escrita de la Coordinación de Informática.


• La Coordinación de Informática no se responsabiliza de los inconvenientes y/o destrozos que puedan sufrir los discos locales de cada PC.


5.3. A nivel de Servicio de Navegación


El servicio de navegación en Internet se encuentra regulado de acuerdo a las posibilidades de seguridad y de prestación del equipamiento existente a nivel comunicaciones, hardware y networking.


La Coordinación de Informática resuelve, según sea:


• Restringir navegación en horarios pico y todas aquellas restricciones que se hagan necesarias a efectos de mantener los niveles de velocidad en forma distribuida para todos los usuarios habilitados.


• Asimismo, está prohibida cualquier acción destinada a bajar archivos de música, videos, etc., que ponen en riesgo la seguridad informática de los equipos y de la red.


• La restricciones de navegación están implementadas sobre páginas no permitidas con contenidos pornográficos, musicales, webmails, mensajeros instantáneos, chat y otros indebidos.


5.4. A nivel de Servicio de Correo Electrónico


• Este servicio debe ser utilizado únicamente para fines laborales, quedando terminantemente prohibido su utilización en cuestiones de índole personal.


• Al momento de enviar un correo electrónico se debe tener en cuenta que sólo se manda a un máximo de 20 destinatarios, ya que ése es el límite permitido.


• La capacidad del buzón del Correo Electrónico no puede superar los 13 MB.


• Los archivos que se adjuntan para ser enviados por e-mail no pueden superar los 10 MB, de manera contraria el servidor rechazará el envío.


• De igual forma, se da a conocer que se encuentra bloqueada la descarga de archivos con extensiones dudosas como por ejemplo ".exe", ".scr", ".piff", etc., pudiendo sólo abrir archivos con extensiones convencionales como por ej. los ".doc", ".xls", y ".pdf"



CONTENIDO


1. OBJETIVO


2. ALCANCE


3. RESPONSABILIDADES


3.1. PROPIETARIO


3.2. RESPONSABLES DE CUMPLIMIENTO


3.3. RESPONSABLES DE ACTUALIZACION


4. REGIMEN DE REVISION Y ACTUALIZACION


5. DESARROLLO


5.1. SOLICITANTES DE EVENTOS A REGISTRAR


5.2. TIPOS DE EVENTOS


5.3. ACCESO A LOS REGISTROS


5.4. EVENTOS GENERALES A REGISTRAR PARA TODOS LOS USUARIOS


5.5. EVENTOS ESPECIALES


5.6. COMPLETAMIENTO DE ESPACIO DISPONIBLE PARA ALMACENAMIENTO


5.7. ACCIONES ANTE SITUACIONES DE ANORMALIDAD


5.8. DEPURACIONES


1. OBJETIVO


Definir las pautas generales para asegurar una adecuada identificación y seguimiento de los eventos de seguridad de los sistemas.


2. ALCANCE


Todo el personal del organismo y los terceros, que interactúan de manera habitual u ocasional, que accedan a información y/o a los recursos informáticos.


3. RESPONSABILIDADES


3.1. PROPIETARIO


El propietario del presente procedimiento es el Ing. Alberto Chedufau en su carácter de Responsable de Seguridad Informática del Ministerio. Sus responsabilidades son:


- Establecer las medidas de seguridad necesarias para garantizar el adecuado almacenamiento del presente documento.


- Definir los perfiles que tendrán acceso al documento.


- Asegurar la accesibilidad del documento para quienes necesiten consultarlo.


- Comunicar la existencia del documento y asesorar sobre el mismo a los responsables de su cumplimiento.


- Solicitar actualizaciones fuera del esquema normal.


3.2. RESPONSABLES DE CUMPLIMIENTO


Es responsable del cumplimiento del presente procedimiento todo el personal del Organismo, así como terceros que hagan uso de cualquier recurso informático perteneciente al mismo.


3.3. RESPONSABLES DE ACTUALIZACION


El responsable de la actualización del presente procedimiento es el Ing. Alberto Chedufau en su carácter de Responsable de Seguridad Informática del Ministerio. Su responsabilidad es revisar y actualizar en caso que corresponda, el presente documento de acuerdo al esquema de revisión y actualización establecido y a las solicitudes efectuadas por el propietario del mismo.


4. REGIMEN DE REVISION Y ACTUALIZACION


El presente documento será revisado trimestralmente y actualizado en el caso de detectarse la necesidad de efectuar modificaciones que permitan mantenerlo actualizado en relación a la realidad de la estructura funcional y del ambiente informático.


Por otra parte, se realizarán las modificaciones que sean necesarias en el caso que se produjeran cambios que lo requieran, fuera de las revisiones programadas.


5. DESARROLLO


5.1. Solicitantes de eventos a registrar


El Administrador del Centro de Cómputos es responsable de la definición de los eventos de seguridad a ser registrados automáticamente en los sistemas.


Exclusivamente los Dueños de Datos / Delegados deben solicitar al Administrador la registración de eventos adicionales en la medida que se correspondan con su información o personal a su cargo.


Para situaciones de excepción, el Dueño de Datos / Delegado del área de Recursos Humanos y/o de Auditoría Interna puede solicitar la registración de eventos de algún usuario.


El Administrador del Centro de Cómputos es el responsable de implementar todos los eventos de seguridad en cada uno de los sistemas.


5.2. Tipos de eventos


Se deben registrar todos los eventos relacionados con las configuraciones de seguridad de los sistemas.


Todo software utilizado debe permitir la registración automática y explotación de la información de los eventos de seguridad.


5.3. Acceso a los registros


Exclusivamente el Administrador del Centro de Cómputos, el Responsable de Seguridad y los Operadores (para los procesos de generación de copias de respaldo) deberían acceder a los registros de eventos de seguridad en la medida que lo permitan los sistemas.


5.4. Eventos generales a registrar para todos los usuarios


Ø Accesos fallidos de ingreso de usuarios


Ø Encendido y apagado de equipos centrales de procesamiento


Ø Desconexión forzada de usuarios


Ø Alta, baja o modificación de usuarios y grupos


Ø Cambios en la configuración de la seguridad


Ø Instalación de software de aplicación


Ø Procesos de depuración de información no automatizados


5.5. Eventos especiales


Ø Todos los accesos no autorizados a información clasificada como de acceso autorizado.


Ø Todos los eventos de un usuario cuando sean específicamente solicitados.


Ø Todos los accesos para cualquier usuario que acceda a la información clasificada como sensible.


Ø Todos los accesos del Responsable de Seguridad, de los usuarios de máximo riesgo y de los usuarios especiales del personal de Desarrollo de Sistemas cuando acceden al ambiente de Producción.


5.6. Completamiento de espacio disponible para almacenamiento


El Administrador en conjunto con los correspondientes Dueños de Datos / Delegados debe definir cuáles son los eventos que se consideren críticos que determinen la suspensión del servicio de procesamiento cuando se llegue al límite de la capacidad de almacenamiento en los equipos. Para el resto de los eventos, debe definir la opción de suspender la registración o la sobreescritura de los registros.


5.7. Acciones ante situaciones de anormalidad


El Administrador debe:


Ø analizar diariamente los eventos


Ø informar al Responsable de Seguridad ante incidentes observados


El Responsable de Seguridad debe informar al Dueño de Datos / Delegado y cuando corresponda al Dueño de Datos / Delegado del área de Recursos Humanos y de Auditoría Interna. El Oficial de Seguridad debe conservar todos los soportes enviados y eventualmente comunicar al área de Operaciones de Sistemas la necesidad de conservación de los registros de eventos por períodos mayores a los previstos.


5.8. Depuraciones


En situaciones de emergencia en la performance del equipo debido al excesivo volumen de los registros automáticos de auditoría, el área de Operaciones de Sistemas debe generar una copia de respaldo de estos registros antes de proceder a su depuración y notificar del hecho al Responsable de Seguridad.



CONTENIDO


1. OBJETIVO


2. ALCANCE


3. RESPONSABILIDADES


3.1. PROPIETARIO


3.2. RESPONSABLES DE CUMPLIMIENTO


3.3. RESPONSABLES DE ACTUALIZACION


4. REGIMEN DE REVISION Y ACTUALIZACION


5. DESARROLLO


5.1. CONEXIONES INTERNAS


5.2. CONEXIONES EXTERNAS


1. OBJETIVO


Definir las pautas generales para asegurar una adecuada protección de la información en los procesos de transmisión y recepción de datos en las redes internas y externas del Organismo.


2. ALCANCE


Todo el personal de Coordinación de Informática del organismo y los terceros que interactúan de manera habitual u ocasional que estén vinculados a los procesos de transmisión de datos en el desarrollo de sus tareas habituales.


3. RESPONSABILIDADES


3.1. PROPIETARIO


El propietario del presente procedimiento es el Ing. Alberto Chedufau en su carácter de Responsable de Seguridad del Ministerio. Sus responsabilidades son:


- Establecer las medidas de seguridad necesarias para garantizar el adecuado almacenamiento del presente documento.


- Definir los perfiles que tendrán acceso al documento.


- Asegurar la accesibilidad del documento para quienes necesiten consultarlo.


- Comunicar la existencia del documento y asesorar sobre el mismo a los responsables de su cumplimiento.


- Solicitar actualizaciones fuera del esquema normal.


3.2. RESPONSABLES DE CUMPLIMIENTO


Es responsable del cumplimiento del presente procedimiento todo el personal del Organismo, así como terceros que hagan uso de cualquier recurso informático perteneciente al mismo.


3.3. RESPONSABLES DE ACTUALIZACION


El responsable de la actualización del presente procedimiento es el Ing. Alberto Chedufau en su carácter de Responsable de Seguridad del Ministerio. Su responsabilidad es revisar y actualizar en caso que corresponda, el presente documento de acuerdo al esquema de revisión y actualización establecido y a las solicitudes efectuadas por el propietario del mismo.


4. REGIMEN DE REVISION Y ACTUALIZACION


El presente documento será revisado semestralmente y actualizado en el caso de detectarse la necesidad de efectuar modificaciones que permitan mantenerlo actualizado en relación a la realidad de la estructura funcional y del ambiente informático.


Por otra parte, se realizarán las modificaciones que sean necesarias en el caso que se produjeran cambios que lo requieran, fuera de las revisiones programadas.


5. DESARROLLO


5.1. Conexiones internas


Adicionalmente a las medidas de protección física y de acceso de usuarios ya definidas en las respectivas normas, se deben tener en cuenta las siguientes consideraciones adicionales:


Ø Utilizar switches, no sólo para conectar los distintos segmentos de la red interna, sino también para conectar las distintas estaciones de trabajo y servidores entre sí.


Ø Verificar que existan los adecuados mecanismos de encripción para la información sensible propia de los sistemas (contraseñas, bases de datos de seguridad o similares).


Ø Utilizar un esquema de direccionamiento IP teniendo en cuenta las direcciones privadas definidas en la normativa internacional respectiva para evitar que éstas sean direccionables desde el exterior.


Ø Utilizar sistemas de detección de intrusos que permitan la detección posibles ataques y tomen acciones automáticas para prevenirlos.


5.2. Conexiones externas


En forma general, todas las conexiones externas a la red del organismo deben cumplir las siguientes consideraciones:


Ø El origen de todas las conexiones remotas debe ser autenticada utilizando un nivel aceptado de autenticación.


Ø Todo acceso a la red interna de la compañía debe realizarse a través de una red segmentada (DMZ - zona desmilitarizada).


Ø Las conexiones externas podrán acceder solamente a los servicios, sistemas y/o aplicaciones a los que están autorizados.


Ø Deben transmitirse en forma encriptada todos los datos considerados de acceso autorizado y/o sensibles, a través redes virtuales permanentes utilizando clave pública y privada o certificados.


Ø Los accesos externos deben ser registrados a fin de determinar posibles intentos de accesos no autorizados.


Ø Debe incluirse en los contratos con los proveedores la utilización de otra vía alternativa ante interrupciones en el servicio.


Aspectos particulares de los distintos tipos de accesos externos:


Internet


Todo contrato con un proveedor de servicios de Internet debe contemplar la descripción de todos los servicios provistos y de todos aquellos que en un futuro pudiera requerir la compañía.


Todas las conexiones deben realizarse a través de un Firewall. En el caso particular de las conexiones salientes, éstas deben ser validadas a través de un servidor del tipo "AAA" (que verifica la autenticidad- Authentication, la autorización-Authorization y el monitoreo-Accounting de la cuenta de usuario) a fin de controlar los accesos de los usuarios, para lo cual se debe llevar un registro de los servicios utilizados y como mínimo la cuenta de usuario, la dirección IP accedida, la dirección URL accedida, la fecha y la hora.


En el caso de las conexiones entrantes, se debe llevar registro de los intentos fallidos que contenga la dirección IP de origen, el servicio requerido, el motivo del rechazo, la fecha y la hora.


Accesos remotos


El servicio de Acceso Remoto será utilizado solamente para conexiones entrantes y en función al perfil del usuario que se conecta se establecen los servicios y direcciones habilitadas para dicho usuario.


Debe registrarse todo evento relacionado con cambios de derechos de acceso y accesos exitosos y fallidos, la identificación del usuario responsable, la fecha y hora de inicio, tiempo de conexión, las líneas y protocolos empleados y, para los cambios en los derechos de acceso, el estado anterior y posterior de los cambios realizados.



CONTENIDO


1. INTRODUCCION


1.1. PORTAL DE INTRANET


1.2. INGRESO AL SITIO INTRANET WWW.PORTALMIN


1.3. SITIOS DESARROLLADOS


2. OBJETIVO


3. ALCANCE


4. RESPONSABILIDADES


4.1. PROPIETARIO


4.2. RESPONSABLES DE CUMPLIMIENTO


4.3. RESPONSABLES DE ACTUALIZACION


5. REGIMEN DE REVISION Y ACTUALIZACION


6. PAUTAS PARA EL DESARROLLO


7. PROCEDIMIENTOS TECNICOS PARA DESARROLLAR


SITIOS WEB EN INTRANET


8. ANEXO


1. INTRODUCCION


1.1. PORTAL DE INTRANET


El sitio www.portal.min desarrollado por Coordinación de Informática es el Portal Intranet del Ministerio Desarrollo Social, al que pueden acceder únicamente los usuarios de la red del mencionado Organismo.


1.2. INGRESO AL SITIO INTRANET WWW.PORTAL.MIN


Mediante este PORTAL INTERNO del Ministerio, se podrá acceder a los "sitios Web" que tengan los sectores de esta dependencia.


Puede ingresar a este portal todo usuario que se encuentre dentro de la Red de Datos del Ministerio, para ello se deberá tipear en el navegador de Internet: www.portal.min tal como se muestra en la pantalla que se detalla más abajo:



1.3. SITIOS DESARROLLADOS


Las áreas que poseen sitios propios en este Portal son:


• "Coordinación Informática"


• "Dirección General de Recursos Humanos y Organización"


• "Coordinación de Mesa de Entradas"


• "Despacho y Protocolización, y Dirección General de Administración"


1.3.1. Coordinación Informática


Dentro de este sector se puede acceder a manuales operacionales, de procedimientos, de usuarios, disposiciones, formularios y solicitudes, que se utilizan para la organización administrativa y laboral de dicho área.


1.3.2. Dirección General de Recursos Humanos y Organización


Dentro de esta página usted encontrará toda la información referida a dicha área, como el manual de contrataciones, proyectos en desarrollo, declaraciones juradas, etc.


1.3.3. Coordinación de Mesa de Entradas


Ingresando en esta página usted encontrará los manuales de procedimientos de operaciones de dicha área.


1.3.4. Despacho y Protocolización


Ingresando en el sitio de este sector, se pueden encontrar disposiciones, solicitudes, rendiciones, memorandos, etc.


1.3.5. Dirección General de Administración


2. OBJETIVO


Dar a conocer, desarrollar y mantener actualizado el Portal Interno del Ministerio de Desarrollo Social.


Definir las pautas y procedimientos para fomentar la publicación de la información del mencionado Organismo.


3. ALCANCE


Cada Secretaría, Subsecretaría, Dirección, Area, que desarrolle su página, podrá publicarla en el sitio www.portal.min, con el control de accesos que correspondan implementar para cada caso, y alineados en su totalidad con la D.A 669/2004 Política de Seguridad para los Sistemas de Información.


4. RESPONSABILIDADES


4.1. PROPIETARIO


El propietario del presente procedimiento es COORDINACION DE INFORMATICA. Sus responsabilidades son:


- Establecer las medidas de seguridad necesarias para garantizar el adecuado almacenamiento del presente documento.


- Definir los perfiles que tendrán acceso al documento.


- Asegurar la accesibilidad del documento para quienes necesiten consultarlo.


- Comunicar la existencia del presente documento y asesorar sobre el mismo a los responsables de su cumplimiento.


- Solicitar actualizaciones fuera del esquema normal.


4.2. RESPONSABLES DE CUMPLIMIENTO


Es responsable del cumplimiento del presente procedimiento todo el personal del Organismo, así como terceros que hagan uso de cualquier recurso informático perteneciente al mismo.


4.3. RESPONSABLES DE ACTUALIZACION


El responsable de la actualización del presente procedimiento es el COMITE DE SEGURIDAD. Su responsabilidad es revisar y actualizar en caso que corresponda, el presente documento de acuerdo al esquema de revisión y actualización establecido y a las solicitudes efectuadas por el propietario del mismo.


4.4. RESPONSABILIDADES SOBRE EL ESPACIO EN SERVIDOR


El propietario de cada una de las páginas que se publican en la Intranet, deberá:


• Establecer las medidas de seguridad necesarias para garantizar el adecuado almacenamiento de la información del área que desea publicar.


• Definir los perfiles que tendrán acceso a la información publicada.


• Asegurar la accesibilidad al portal para quienes necesiten efectuar consultas.


• Realizar las actualizaciones correspondientes en tiempo y forma.


5. REGIMEN DE REVISION Y ACTUALIZACION


El presente documento será revisado semestralmente y actualizado en el caso de detectarse la necesidad de efectuar modificaciones que permitan mantenerlo actualizado en relación a la realidad de la estructura funcional y del ambiente informático.


Por otra parte, se realizarán las modificaciones que sean necesarias en el caso que se produjeran cambios que lo requieran, fuera de las revisiones programadas.


6. PAUTAS PARA EL DESARROLLO


Para dar comienzo al desarrollo de una página para su posterior publicación en la Intranet wwvv.portal.min, deben llevarse a cabo los siguientes pasos:


a) Completar la SOLICITUD DE ALTA DE SITIOS WEB EN INTRANET (Ver. 8. ANEXO)


b) Documentación a presentar.


Memorandum que contenga:


Nombre del Dominio,


Espacio Físico (Cantidad de espacio en Disco)


c) Recepción de la documentación, testeo por el Area de Informática, y comienzo del pasaje de carpetas del estado de desarrollo al estado Staging (Pruebas).


d) Recepción de aprobación del usuario con la conformidad por escrito de la información a publicarse.


e) Reglas de código Web a utilizar (ver procedimiento de reglas generales de programación Web del MDS).


f) Especificaciones técnicas a tener en cuenta tanto para Servidores Web como para servidores donde se alojan las Bases de Datos. (Ver Procedimiento para Sitios Web Intranet)


7. PROCEDIMIENTOS TECNICOS PARA DESARROLLAR SITIOS WEB EN INTRANET


En el ámbito de los Sistemas Web del Ministerio de Desarrollo Social existen ciertas reglas y procedimientos a cumplir por quienes tienen incumbencia directa con el desarrollo, la producción y/o el mantenimiento de los mismos.


Actualmente existen tres ambientes bien diferenciados: DESARROLLO, STAGING y PRODUCCION (STAGING es reemplazado en una etapa posterior por ADUANA, como se describe más adelante en este documento).


Ambiente DESARROLLO: à dominio ".des"


El grupo a cargo del desarrollo del sitio Web (en adelante "el desarrollador") tiene a su disposición este ambiente para crear, modificar y probar, haciendo los ajustes que considere necesarios para que el sitio funcione correctamente. Aquí se puede realizar pruebas y ensayos que el desarrollador considere aún dudosas de funcionamiento óptimo, siempre y cuando se maneje bajo las premisas de desarrollo básicas de cualquier otro sitio dentro del organismo.


Ambiente PREVIO o "STAGING": à dominio ".pre"


Cuando se crea por primera vez un sitio Web, además de crearse el dominio en el ambiente Desarrollo, también se crea el dominio correspondiente en Staging, normalmente usado para el Startup (puesta en funcionamiento en producción por primera vez).


Habiendo el desarrollador considerado que el sitio, en el ambiente DESARROLLO, ha alcanzado un punto en el que se considere funcional deberá proceder a traspasar el código y la estructura de base de datos (si hubiera) al ambiente denominado STAGING.


Este ambiente (STAGING) fue concebido para que el desarrollador separe su código de pruebas y vuelque "en limpio" aquí todo el código para él considerado fiable.


De esta forma el desarrollador puede mantener código fiable separado y someter el sitio, creado ahora en STAGING, a todas las pruebas necesarias para verificar su funcionamiento, aplicar las modificaciones que crea necesarias, realizar demostraciones a las autoridades (si fuera necesario), etc.


Cuando los desarrolladores del sitio Web, después de haber realizado ajustes y revisado su funcionalidad, consideran que éste ha alcanzado el nivel en el que estaría libre de errores deberán enviar un e-mail al Centro de Cómputos dando aviso que su nuevo sitio está listo. A la recepción de este email, el Centro de Cómputos quedará notificado y contestará que iniciará las pruebas y revisiones necesarias sobre el ambiente STAGING.


Las revisiones sobre el código Web y la programación de la base de datos (si la hubiera) las llevará a cabo el Centro de Cómputos a través de un equipo conformado por responsables de los servidores Web y de base de datos conjuntamente con personal dedicado exclusivamente al monitoreo de los sitios Web de este organismo, para verificar el funcionamiento y cumplimiento de las reglas mínimas de desarrollo y seguridad.


En el posible caso en que Cómputos considere necesario que el desarrollo deba ser modificado en alguna o varias de sus partes, éste enviará un e-mail a quien figure como contacto técnico (o en su defecto a quien se señale como interlocutor válido desde el comienzo del proyecto) solicitando se lleve a cabo las modificaciones requeridas.


Una vez que el diseño es completamente aceptado como fiable al proyecto y libre de errores, el Centro de Cómputos a través de su personal procederá a generar el sitio Web definitivo en el ambiente de producción.


Ambiente PRODUCCION: à dominio ".min"


En este ambiente se aloja el sitio Web (y su respectiva base de datos si la hubiere) que está disponible al usuario final, tras haber pasado por las anteriores etapas de revisión y corrección.


Por ser considerado este ambiente como libre de errores, y ser además el más crítico, nadie debe tener acceso a los servidores.


En principio, si todo funcionó como se esperaba, a partir de este momento se da por finalizado el Start-up del nuevo sitio y, consecuentemente se deshabilita el ambiente STAGING del sitio relacionado, notificando Cómputos al desarrollador este acto.


En el supuesto caso que el desarrollador deba realizar modificaciones a su sitio procederá a realizar una serie de etapas, en la que la última la completará Cómputos, como se describe posteriormente.


MANTENIMIENTO DEL SITIO WEB:


Una vez funcionando el sitio, y luego de haber completado todas las etapas de la puesta en funcionamiento por primera vez, es posible que el desarrollador deba realizar actualizaciones a su contenido para mantenerlo vigente. En tal circunstancia hay dos casos posibles: (Caso 1) modificaciones simples sobre el contenido (caso más común), o (Caso 2) modificaciones en la estructura de su código que pueda considerarse como cambio profundo diferente al actualmente en producción.


Modificaciones al sitio Web


(Caso 1) Toda modificación a aplicarse posterior al Start-up deberá necesariamente probarse primero en el ambiente DESARROLLO, realizar todas las pruebas y modificaciones necesarias para la puesta a punto, y luego vía e-mail a Cómputos se solicitará la realización de las modificaciones pertinentes en PRODUCCION.


(Caso 2) Si ocurriera esto, personal de Cómputos deberá evaluar la necesidad de que el cambio a realizarse implique las mismas circunstancias que un proyecto nuevo (Desarrollo-Staging-Producción). Con lo cual se repetirá cada una de las instancias por las que debió pasar, para luego realizarse las modificaciones pertinentes al sitio en el ambiente en PRODUCCION.


Indistintamente cuál de los dos casos citados anteriormente sea el de modificación del sitio, en el momento en que el desarrollador solicite actualización, se concederá acceso al sistema denominado "ADUANA".


REGLAS GENERALES DE PROGRAMACION WEB DEL MDS


Reglas del código Web


Hay ciertas reglas que debe cumplir el sitio, algunas de ellas son:


• Está permitido usar lenguaje html, asp, y todo su entorno (.css, .js, .inc, etc.).


• Está permitido usar imágenes .gif y .jpg.


• Manejar los tiempos que dure la sesión del usuario anónimo en forma concisa, no keepalive.


• No está permitida la escritura en disco.


• No está permitido hacer referencias a rutas primarias (../).Está deshabilitado desde los servidores Web por cuestiones de seguridad.


• No alojar archivos de tipo ejecutables de sistema operativo (.exe, .com, .bat, .pif, etc).


• No sobrecargar el sitio Web de imágenes y archivos de capacidad importante porque puede ocasionar lentitud general sobre los servidores y los sistemas dependientes, generando alto tráfico de información y problemas a nivel disponibilidad al usuario.


• Si bien no es requisito, es buena costumbre en todo desarrollo importante comentar las distintas funciones que el programa realiza dentro del código mismo, máxime teniendo en cuenta que no siempre puede estar disponible quien desarrollara el sistema originalmente.


Reglas del programa de base de datos


• Utilizar como transporte el proveedor OLEDB.


• Los usuarios no deben tener acceso en forma directa de ningún tipo (lectura/escritura) a objetos o tablas de la base de datos, sino a través de procedimientos almacenados en el servidor.


• Hacer uso de contraseñas fuertes.


• No realizar consultas mediante páginas que publiquen libremente la sintaxis en forma directa. Usar páginas ".asp" para esta tarea.


A lo expuesto anteriormente queda clara la responsabilidad implícita de parte del desarrollador de hacer uso de los recursos a su disposición sólo con el fin de realizar el desarrollo del proyecto encomendado y previamente aprobado por las respectivas autoridades.


SISTEMAS ACTUALES DEL MDS


El Centro de Cómputos del Ministerio de Desarrollo Social cuenta actualmente con la infraestructura y capacidad para brindar al desarrollador los recursos de Hardware y Software necesarios para cumplir con diseños actuales basados en tecnologías Web.


Al respecto, los servidores, tanto Web servers, como servidores de base de datos, brindan servicios mediante las últimas versiones de sistema operativo hoy disponibles. Sobre los mismos se mantiene un estricto plan de actualizaciones y arreglos que son publicados periódicamente por los fabricantes.


ESPECIFICACIONES TECNICAS


SERVIDORES WEB


Microsoft IIS 6 con los últimos service packs y patches.


SERVIDORES DE BASE DE DATOS


Microsoft SQL Server 2000 con MDAC 2.8spl + últimos service packs y patches.


8. ANEXO



INSTRUCTIVO PARA COMPLETAR


SOLICITUD DE ALTA DE SITIOS WEB EN INTRANET


1. Debe completarse con la fecha de presentación del trámite. Es un dato indispensable para su correcta administración.


2. Este ítem debe ser completado sólo por Coordinación Informática, con la hora en que se recibió el trámite y el NΊ interno de la solicitud


3. Hacer una cruz, en el edificio donde desempeña su actividad. Ejemplo:


EDIFICIO



4. Especificar el nombre del área a la cual pertenecerá el sitio web.


5. Especificar el nombre que se sugiere para el mencionado sitio.


6. Detallar nombre y Apellido de la Autoridad responsable del Sitio


7. Detallar nombre y Apellido del Técnico responsable del Sitio


8. Detallar nombre y Apellido de la persona designada como contacto 1.


9. Especificar Teléfono y Mail de la persona designada como contacto 1.


10. Detallar nombre y Apellido de la persona designada como contacto 2.


11. Especificar Teléfono y Mail de la persona designada como contacto 2.


12. Enumerar Nombre y apellido de las personas implicadas en el Sitio.


13. Todos los datos que conforman el recuadro gris, deben ser completados exclusivamente por el Centro de Cómputos.


14. El Jefe o director el área debe firmar y aclarar su firma para aprobar la solicitud del usuario


15. El solicitante debe firmar el formulario y aclarar su firma.



CONTENIDO


1. OBJETIVO


2. ALCANCE


3. RESPONSABILIDADES


3.1. PROPIETARIO


3.2. RESPONSABLES DE CUMPLIMIENTO


3.3. RESPONSABLES DE ACTUALIZACION


4. REGIMEN DE REVISION Y ACTUALIZACION


5. DESARROLLO


5.1. CLASIFICACION DE UN INCIDENTE


5.2. DETECCION DE UN INCIDENTE


5.3. REPORTE DE UN INCIDENTE


5.4. TRATAMIENTO DE UN INCIDENTE


5.4.1. INCIDENTE CONCRETADO


5.4.2. INCIDENTE NO CONCRETADO


5.5. DOCUMENTACION DEL INCIDENTE


5.5.1. DOCUMENTACION INTERNA


5.5.2. DOCUMENTACION PARA ARCERT


5.6. CONTROL DE INCIDENTES


5.7. TABLERO DE SEGUIMIENTO


1. OBJETIVO


Establecer pautas para el reporte, registro, tratamiento y seguimiento de los incidentes ocurridos; así como la comunicación y solución de debilidades identificadas en el ambiente informático. Mitigar los efectos causados por los incidentes ocurridos en el ambiente informático.


Generar conocimiento a partir del cual sea posible reducir la posibilidad de ocurrencias de incidentes futuros.


2. ALCANCE


El presente procedimiento será aplicado ante la ocurrencia de cualquier tipo de incidente que afecte la seguridad de la información del Organismo o el correcto funcionamiento de los componentes que integran el ambiente informático. Cabe aclarar que se considerará como incidente tanto a aquel que presente consecuencias de cualquier tipo como el que haya sido detenido antes de producir un impacto, no ocasionando daños.


Asimismo, se aplicará en forma preventiva, a las debilidades detectadas en cualquier componente del ambiente informático, aunque los mismos no hayan sido víctimas de un ataque concreto.


3. RESPONSABILIDADES


3.1. PROPIETARIO


El propietario del presente procedimiento es el Ing. Alberto Chedufau (Responsable de Seguridad. Sus responsabilidades son:


3.1.1- Establecer las medidas de seguridad necesarias para garantizar el adecuado almacenamiento del presente documento.


3.1.2- Definir los perfiles que tendrán acceso al documento.


3.1.3- Asegurar la accesibilidad del documento para quienes necesiten consultarlo.


3.1.4- Comunicar la existencia del documento y asesorar sobre el mismo a los responsables de cumplimiento.


3.1.5- Solicitar actualizaciones fuera del esquema normal.


3.2. RESPONSABLES DE CUMPLIMIENTO


Es responsable del cumplimiento del presente procedimiento todo el personal del Organismo, como terceros que hagan uso de cualquier recurso informático perteneciente al mismo.


3.3. RESPONSABLES DE ACTUALIZACION


El responsable de la actualización del presente procedimiento es el Ing. Alberto Chedufau, en carácter de Responsable de Seguridad. Su responsabilidad es revisar y actualizar en caso que corresponda, el presente documento de acuerdo al esquema de revisión y actualización establecido y a solicitudes efectuadas por el propietario del mismo.


4. REGIMEN DE REVISION Y ACTUALIZACION


El presente documento será revisado semestralmente y actualizado en el caso de detectarse necesidad de efectuar modificaciones que permitan mantenerlo actualizado en relación a la realidad de la estructura funcional y del ambiente informático.


Por otra parte, se realizarán las modificaciones que sean necesarias en el caso que se produjeran cambios que lo requieran, fuera de las revisiones programadas.


5. DESARROLLO


Un evento es una ocurrencia observada u observable en un sistema, una red o en los procesos. Un evento será considerado como incidente si éste puede producir efectos adversos en el ambiente informático.


Se define a un incidente de seguridad como un evento adverso en un sistema de computadoras, o red de computadoras, que puede comprometer o compromete la confidencialidad, integridad o disponibilidad de la información. Puede ser causado mediante la explotación de alguna vulnerabilidad un intento o amenaza de romper los mecanismos de seguridad existentes.


Como se aclara en el "Alcance", un incidente puede lograr el cumplimiento del objetivo para el cual se ha producido, o bien puede ser detenido antes de ello.


5.1. CLASIFICACION DE UN INCIDENTE


Todo Incidente detectado será clasificado por el Responsable de Seguridad en el marco del procedimiento descrito en puntos subsiguientes.


Se establecen tres niveles en base a la criticidad e impacto del incidente sobre el ambiente informático:



5.2. DETECCION DE UN INCIDENTE


La primera etapa del proceso de manejo de incidentes es la detección, en la cual se produce conocimiento por parte del usuario, de la ocurrencia de un incidente. La detección de un incidente puede ser efectuada en cualquier área del Organismo, tanto por usuarios funcionales como por usuarios del Area Informática. Por otra parte, existe también la posibilidad de que un incidente sea detectado por un componente de control automático, implementado en el ambiente informático, como ser algún software de monitoreo de red con alarma.


A continuación se citan algunos de los incidentes que pueden ser detectados:


5.2.1- Infección de virus, gusanos o troyanos


5.2.2- Modificación de la página Web (Web-defacement)


5.2.3- Interrupción o denegación de servicio por medios electrónicos


5.2.4- Escaneos de puertos o pruebas maliciosas


5.2.5- Intercepción de las comunicaciones


5.2.6- Acceso no autorizado a archivos de datos o sistemas


5.2.7- Modificación de archivos de datos o sistemas


5.2.8- Fraude por medios electrónicos


5.2.9- Robo electrónico de información confidencial


5.2.10- Robo de equipamiento


5.2.11- Fallas de hardware


5.2.12- Cαtedraástrofes naturales


Cabe destacar que este procedimiento se aplicará asimismo al manejo de debilidades o anomalías que, sin ser incidentes, representan un riesgo para la seguridad del ambiente de sistemas. Es por ello que los usuarios deberán efectuar asimismo el reporte de:


- debilidades identificadas en los componentes informáticos


- anomalías en materia de seguridad del software o hardware


El usuario recolectará toda aquella información susceptible de ser perdida, que fuera de utilidad para el análisis del incidente o anomalía, como ser, pantallas de error. Por el contrario, el usuario no realizará ninguna modificación ni intento de reparación del problema.


5.3. REPORTE DE UN INCIDENTE


Una vez detectado el incidente, se procederá al reporte del mismo.


1) El usuario que haya detectado el incidente es responsable de reportar inmediatamente el mismo a la Mesa de Ayuda (de no existir, indicar área o persona –nombre y cargo- destinada la atención de reportes de incidentes).


2) Mesa de Ayuda procederá a notificar el incidente al Responsable de Seguridad, quien evaluará si realmente se trata de un incidente o sólo es un evento que no presenta efectos adversos. En el caso de tratarse de un incidente, procederá a su clasificación. Ver "5.1. CLASIFICACION DE UN INCIDENTE".


Una vez clasificado el incidente, comunicará el nivel asignado a la Mesa de Ayuda.


3) Mesa de Ayuda efectuará las siguientes tareas:


3.1.- Notificar el incidente al propietario de la información afectada por el mismo (de corresponder)


3.2- Documentar el incidente. Ver "5.5. DOCUMENTACION DEL INCIDENTE".


Una vez finalizado el tratamiento del incidente y habiendo provisto una adecuada solución al mismo, el empleado designado como contacto con ARCERT — Coordinación de Emergencias en Redes Teleinformáticas — efectuará el reporte del incidente y su solución en https: // www.organismos.arcert.gov.ar.


5.4. TRATAMIENTO DE UN INCIDENTE


5.4.1. INCIDENTE CONCRETADO


ACCION INMEDIATA


En primer lugar, el Responsable de Seguridad junto con el Responsable del Area Informática llevarán a cabo las acciones necesarias para mitigar los efectos del incidente:


1) Habiendo tomado conocimiento del incidente ocurrido, se evaluará la criticidad del impacto del incidente y la necesidad de solicitar la asistencia de ArCERT para la solución del mismo.


Podrá efectuarse una comunicación telefónica con personal especializado de ArCERT al 43439001 internos 512/514.


2) Se identificarán los componentes afectados aislándolos de la red para evitar la propagación de los daños.


3) Se definirán las medidas a ser implementadas para la restauración de los daños ocasionados. El Responsable del Area Informática tendrá a cargo la implementación de las medidas definidas de acuerdo a los procedimientos operativos existentes. El Responsable de Seguridad Informática efectuará un seguimiento de dichas actividades.


ACCIONES POSTERIORES


Una vez solucionado el incidente se seguirán los siguientes pasos:


1) El Responsable de Seguridad Informática procederá a:


- Efectuar un análisis de las causas que ocasionaron la ocurrencia del incidente con el objeto de implementar medidas tendientes a prevenir la repetición del mismo en un futuro.


- Notificar a las Autoridades y a la Mesa de Ayudas el cierre del incidente.


2) Mesa de Ayudas realizará lo siguiente:


- Comunicar al propietario de la información afectada (de corresponder) las medidas llevadas a cabo para la solución del incidente


- Comunicar al usuario que efectuó el reporte, el cierre del incidente


- Finalizar la documentación del incidente. Ver "5.5. DOCUMENTACION DEL INCIDENTE".


5.4.2. INCIDENTE NO CONCRETADO


En el caso de que el incidente no se hubiera concretado, es decir, que no hayan ocurrido daños a ser reparados, sólo se efectuará el reporte y documentación del mismo.


Estos casos pueden corresponder a:


- Incidentes cuyo efecto fue detenido por alguna medida de seguridad existente.


- Debilidades identificadas en los componentes informáticos.


- Anomalías en materia de seguridad del software o hardware


5.5. DOCUMENTACION DEL INCIDENTE


La documentación de los incidentes de seguridad es muy importante en el proceso de manejo de incidentes, dado que permite efectuar una gestión eficiente de los mismos, realizar análisis estadísticos y disminuir su ocurrencia y efectos producidos.


5.5.1. DOCUMENTACION INTERNA


La documentación interna de los incidentes será efectuada por la Mesa de Ayudas, en función a la información reportada por el usuario acerca del incidente, y por el Responsable de seguridad Informática acerca de su tratamiento y solución.


Se utilizará para la documentación un Registro de Incidentes con la siguiente información:


Ø Datos del incidente


- Identificador único: se asignará un identificador por incidente documentado.


- Categoría: tipo de incidente. El objetivo es agrupar en una misma categoría varios incidentes de manera de facilitar su posterior análisis.


- Descripción: definición detallada del incidente.


- Concretado / No Concretado


- Nivel de criticidad: Ver "5.1. CLASIFICACION DE UN INCIDENTE".


Ø Datos del reporte


- Informado por: nombre del usuario que reportó el incidente


- Fecha


- Hora


Ø Efectos producidos: detalle de las consecuencias producidas por el incidente concretado.


Ø Datos sobre la atención


- Responsable: será la persona responsable de la atención del incidente


- Encargado: será la persona asignada a la atención del incidente.


Ø Datos sobre la solución


- Estado:



















Pendiente


Si bien el incidente ha sido reportado, aún no se lo ha comunicado al Responsable de Seguridad Informática.


Informado


El incidente ha sido reportado al Responsable de Seguridad Informática pero aún no se lo ha tratado.


En curso


El incidente ha sido reportado al Responsable de Seguridad Informática y se encuentra en tratamiento.


Resuelto


El incidente ha sido resuelto.


Demorado


El tratamiento ha sido interrumpido por motivos a detallar.



- Encargado: designado para la solución del incidente


- Fecha de cierre


- Detalle: se describe en detalle y cronológicamente, indicando la fecha correspondiente, cada una de las tareas efectuadas para la solución del incidente, así como los gastos insumidos (de corresponder)


5.5.2. DOCUMENTACION PARA ARCERT


El empleado designado como contacto con ArCERT accederá al sitio https: // www.organismos.arcertgov.ar para el ingreso del incidente. En la opción "Nuevo incidente" del menú principal encontrará el formulario para la carga de la siguiente información:


Ø Fecha del incidente: se indicará la fecha en la que ocurrió el incidente


Ø Estado del incidente


Ø Tipo de incidente: se seleccionará del combo de opciones.


Ø Dirección IP e información de puertos: esta información se completará en el caso que fuese aplicable de acuerdo al ataque sufrido


- Dirección origen


- Dirección destino


- Puerto TCP


- Puerto UDP


- Puertos ICMP


- Otros protocolos


Ø Principal plataforma afectada


- Tipo de equipo: se seleccionará del combo, en el caso que corresponda, de lo contrario se indicará como "No aplicable"


- Sistema operativo / Versión


- Otros aplicativos (tipo / versión)


Ø Detalles del incidente: descripción de lo sucedido lo más detallada y descriptiva posible.


En lo posible se detallarán métodos utilizados para la intrusión, herramientas utilizadas, detalle de vulnerabilidades explotadas, extractos de archivos de logs, etc.


5.6. CONTROL DE INCIDENTES


El control de incidentes será efectuado por el Responsable de Seguridad Informática, mediante la utilización de un Tablero de Seguimiento (planilla disponible en el sitio). El objetivo de dicho control es efectuar un análisis periódico de los incidentes ocurridos, de manera de:


- Detectar debilidades y vulnerabilidades en los componentes informáticos


- Analizar patrones de ataques


- Delinear medidas para reducir la cantidad de incidentes ocurridos y mitigar sus consecuencias


- Efectuar reportes al Comité de Seguridad de la Información con información estadística respecto de los incidentes ocurridos


Para ello, mensualmente se completará la Tabla de Seguimiento de incidentes con la siguiente información (gran parte de la cual surgirá del Registro de Incidentes):


Ø Datos del incidente:


- Identificador único: se asignará un identificador por categoría de incidente.


- Categoría: tipo de incidente.


- Concretado / No Concretado


- Nivel de criticidad: Porcentaje de incidentes con nivel de criticidad ALTO/MEDIO/BAJO en el período.


Ø Métrica: unidad utilizada para contabilizar los incidentes, por ejemplo, cantidad de incidentes por mes.


Ø Cantidad registrada:


- Esperada: este valor debe ser establecido al comienzo del período evaluado, en función de los objetivos establecidos. Luego se buscará, mediante la implementación de medidas adecuadas, el logro de la cantidad esperada.


- Período actual: cantidad de incidentes registrados en el período al que corresponden los datos.


- Período anterior: cantidad de incidentes registrados en el período anterior.


Ø Tendencia:


- Creciente: en el caso en que la cantidad de incidentes registradas en el período anterior sea menor a la registrada en el actual.


- Decreciente: en el caso en que la cantidad de incidentes registradas en el período anterior sea mayor a la registrada en el actual.


Ø Alerta: criticidad definida en función a los incidentes registrados. Será evaluado de acuerdo a un criterio establecido en función a un análisis de impacto de los incidentes registrados. Un posible criterio a utilizar son las consecuencias potenciales o efectivas sufridas a causa de los incidentes ocurridos.


Ø Comentarios


El Responsable de Seguridad Informática emitirá un reporte mensual del presente tablero, para ser entregado al Comité de Seguridad de la Información.




CONTENIDO


1. OBJETIVO


2. ALCANCE


3. RESPONSABILIDADES


3.1. PROPIETARIO


3.2. RESPONSABLES DE CUMPLIMIENTO


3.3. RESPONSABLES DE ACTUALIZACION


4. REGIMEN DE REVISION Y ACTUALIZACION


5. DESARROLLO


5.1. AMBIENTES DE PROCESAMIENTO


5.2. SEGREGACION DE AMBIENTES


5.3. PASAJE DE INFORMACION ENTRE AMBIENTES


5.4. DEFINICIONES


1. OBJETIVO


Definir una segregación entre los diferentes ambientes de procesamiento: desarrollo, prueba y producción, con el objeto de controlar el acceso a los mismos y proteger la información que cada uno contiene.


2. ALCANCE


El presente procedimiento será aplicado a todos los entornos que cuenten con más de una instancia de procesamiento, por ejemplo, producción y desarrollo o producción y prueba, etc.


3. RESPONSABILIDADES


3.1. PROPIETARIO


El propietario del presente procedimiento es el Ing. Alberto Chedufau en su carácter de Responsable de Seguridad Informática del Ministerio. Sus responsabilidades son:


- Establecer las medidas de seguridad necesarias para garantizar el adecuado almacenamiento del presente documento.


- Definir los perfiles que tendrán acceso al documento.


- Asegurar la accesibilidad del documento para quienes necesiten consultarlo.


- Comunicar la existencia del documento y asesorar sobre el mismo a los responsables de su cumplimiento.


- Solicitar actualizaciones fuera del esquema normal.


3.2. RESPONSABLES DE CUMPLIMIENTO


Es responsable del cumplimiento del presente procedimiento todo el personal del Organismo, así como terceros que hagan uso de cualquier recurso informático perteneciente al mismo.


3.3. RESPONSABLES DE ACTUALIZACION


El responsable de la actualización del presente procedimiento es el Ing. Alberto Chedufau en su carácter de Responsable de Seguridad Informática del Ministerio. Su responsabilidad es revisar y actualizar en caso que corresponda, el presente documento de acuerdo al esquema de revisión y actualización establecido y a las solicitudes efectuadas por el propietario del mismo.


4. REGIMEN DE REVISION Y ACTUALIZACION


El presente documento será revisado semestralmente y actualizado en el caso de detectarse la necesidad de efectuar modificaciones que permitan mantenerlo actualizado en relación a la realidad de la estructura funcional y del ambiente informático.


Por otra parte, se realizarán las modificaciones que sean necesarias en el caso que se produjeran cambios que lo requieran, fuera de las revisiones programadas.


5. DESARROLLO


Se definen tres ambientes de procesamiento:


• Producción: Es donde se ejecutan las transacciones reales, con datos válidos y actuales


• Pruebas: Es donde se realizan las pruebas sobre posibles cambios o actualizaciones a implementar en el ambiente de Producción


• Desarrollo: Es donde se efectúan tareas de programación, modificación o mantenimiento de los sistemas.


Cabe aclarar que en ocasiones es posible implementar sólo dos ambientes: Producción y Desarrollo/ Prueba, incorporando las tareas realizadas en ambos en un mismo ambiente.


El objetivo de segregar los ambientes mencionados es proteger la información almacenada en cada uno de ellos de accesos indebidos, modificación no autorizada, eliminación errónea o pérdida. Separando los ambientes es posible otorgar acceso a los mismos sólo a los usuarios que lo necesitan de acuerdo a sus funciones.


Como premisas generales, y citando lo definido en la Política de Seguridad de la Información, se definen:


- El personal de desarrollo (programadores) no accede al ambiente de Producción, sino únicamente al ambiente de Desarrollo.


- Los usuarios finales no acceden al ambiente de Desarrollo sino únicamente al ambiente de Producción y a través de las aplicaciones.


- El ambiente de Prueba es accedido por los usuarios, "testers" y demás personal que tiene cargo la prueba del sistema en cuestión. Los usuarios encargados de probar los sistemas serán aquellos que tengan conocimiento del mismo y cuenten con la capacidad de evaluarlo.


- Los administradores del Centro de Cómputos acceden a todos los ambientes.


NOTA: "Tester": Persona encargada de probar un sistema con el objeto de verificar que cumple sus funciones adecuadamente y de detectar posibles aspectos a mejorar, modificar o corregir.


5.1. AMBIENTES DE PROCESAMIENTO


A continuación luce la planilla modelo que deberá mantenerse actualizada como documentación en el Centro de Cómputos :
























Sistema


Ambientes de Procesamiento


Producción


Prueba


Desarrollo


 


 


 


 


 


 


 


 


 


 



Por cada sistema se indicará en qué ambiente se encuentra la versión más actualizada.


5.2. SEGREGACION DE AMBIENTES


De acuerdo a lo definido en la Política de Seguridad de la Información, los diferentes ambientes de procesamiento de un sistema serán segregados físicamente si es posible, o lógicamente como mínimo.


El administrador del Centro de Cómputos mantendrá actualizada la siguiente planilla a efectos de poder realizar con comodidad y seguridad las operaciones necesarias con cada sistema donde la "Ubicación" se refiere al lugar donde se ubica el ambiente: servidor y ruta.


Los accesos a los diferentes ambientes para los sistemas del Organismo serán solicitados de acuerdo a lo definido en el "Procedimiento - Administración de usuarios".



CONTENIDO


1. OBJETIVO


2. ALCANCE


3. RESPONSABILIDADES


3.1. PROPIETARIO


3.2. RESPONSABLES DE CUMPLIMIENTO


3.3. RESPONSABLES DE ACTUALIZACION


4. REGIMEN DE REVISION Y ACTUALIZACION


5. DESARROLLO


5.1. USO DE LA INFORMACION


5.2. USO DEL EQUIPAMIENTO


5.3. ALMACENAMIENTO DE INFORMACION


5.4. USO DE LOS SISTEMAS


5.5. USO DEL ACCESO A INTERNET


5.6. USO DEL CORREO ELECTRONICO


5.7. MONITORO


5.8. UTILIZACION DE ANTIVIRUS


1. OBJETIVO


Establecer pautas para regular el uso de los recursos informáticos pertenecientes al Organismo.


2. ALCANCE


El presente procedimiento se aplica al equipamiento informático (Hardware), a la información (archivos), a los servicios (ejemplo Internet y correo electrónico), a los sistemas (software) del Organismo.


3. RESPONSABILIDADES


3.1. PROPIETARIO


El propietario del presente procedimiento es el Ing. Alberto Chedufau en su carácter de Responsable de Seguridad Informática del Ministerio. Sus responsabilidades son:


- Establecer las medidas de seguridad necesarias para garantizar el adecuado almacenamiento del presente documento.


- Definir los perfiles que tendrán acceso al documento.


- Asegurar la accesibilidad del documento para quienes necesiten consultarlo.


- Comunicar la existencia del documento y asesorar sobre el mismo a los responsables de su cumplimiento.


- Solicitar actualizaciones fuera del esquema normal.


3.2. RESPONSABLES DE CUMPLIMIENTO


Es responsable del cumplimiento del presente procedimiento todo el personal del Organismo, así como terceros que hagan uso de cualquier recurso informático perteneciente al mismo.


3.3. RESPONSABLES DE ACTUALIZACION


El responsable de la actualización del presente procedimiento es el Ing. Alberto Chedufau en su carácter de Responsable de Seguridad Informática del Ministerio. Su responsabilidad es revisar y actualizar en caso que corresponda, el presente documento de acuerdo al esquema de revisión y actualización establecido y a las solicitudes efectuadas por el propietario del mismo.


4. REGIMEN DE REVISION Y ACTUALIZACION


El presente documento será revisado anualmente y actualizado en el caso de detectarse la necesidad de efectuar modificaciones que permitan mantenerlo actualizado en relación a la realidad de la estructura funcional y del ambiente informático.


Por otra parte, se realizarán las modificaciones que sean necesarias en el caso que se produjeran cambios que lo requieran, fuera de las revisiones programadas.


5. DESARROLLO


El Organismo brinda a su personal y a toda persona externa que realice trabajos para el mismo, las herramientas necesarias para su desempeño. Es responsabilidad de los depositarios de dichas herramientas, el uso apropiado de las mismas.


5.1. USO DE LA INFORMACION


La información perteneciente al Organismo será utilizada únicamente dentro del marco de las actividades propias del mismo. Con lo cual, se encuentran prohibidas, entre otras actividades:


• Utilizar la información del Organismo para beneficio propio.


• Efectuar daños o destrucción de información del Organismo o cualquier acción que pueda impedir el acceso legítimo a la misma.


Se respetarán las pautas de manejo y resguardo de información establecida en la Política de Seguridad de la Información.


Los Propietarios de la Información mantendrán actualizada la clasificación de la misma, y el resto del personal conocerá el nivel de clasificación de cada tipo de información que deba manejar, almacenar o transferir.


5.2. USO DEL EQUIPAMIENTO


El Organismo provee al personal de equipamiento para el desarrollo de sus tareas, como ser, PCs, impresoras, scanners, CDs y otros dispositivos informáticos. El usuario dará el tratamiento que corresponde a dicho equipamiento, de forma de evitar cualquier daño físico o lógico al mismo como consecuencia de un uso inadecuado.


El equipamiento del Organismo será utilizado únicamente para propósitos relacionados con las actividades del mismo. Entre las actividades que se prohíben detallamos:


• Utilizar los recursos del Organismo para desarrollar cualquier actividad comercial personal.


• Utilizar la red para fomentar o conducir al personal a la realización de actividades lucrativas.


• Realizar actividades tendientes a obtener mayores derechos de acceso que los otorgados por las autoridades.


• Desarrollar actividades (ej.: ejecución de programas) que produzcan la disminución en el rendimiento de la red.


• Iniciar cualquier actividad que comprometa la seguridad de la red o de cualquiera de sus componentes.


• Otorgar acceso a la red o a cualquiera de sus componentes y equipamiento a una persona no autorizada.


• Realizar cambios en la configuración del equipamiento, excepto expresa y previa autorización. En caso de detectarse fallas se deberá seguir el Procedimiento correspondiente


• Efectuar la conexión o desconexión de equipamiento, como ser, PCs, impresoras, etc. En caso de ser necesario, el usuario deberá comunicarse con la Coordinación de Informática


• Entorpecer o detener la verificación periódica efectuada por el software antivirus en equipos. Respondiendo a la política de pantallas limpias establecida en la Política de Seguridad, los usuarios deberán bloquear el acceso a su PC durante períodos prolongados de inactividad. Se entiende como "período prolongado" aquél mayor a 30 minutos.


Se recomienda lo siguiente:


• Evitar que alimentos (sólidos y líquidos) se encuentren cerca del equipamiento.


• Evitar que celulares y radios se encuentren cerca del equipamiento.


• No obstruir la salida de ventilación de los equipos.


5.3. ALMACENAMIENTO DE INFORMACION


Los usuarios disponen de los siguientes tipos de medios de almacenamiento:


De red


- Espacio privado: cada usuario puede poseer un directorio privado en el servidor de archivos, en el cual puede almacenar información de manera que sólo él pueda accederla. Dicho directorio posee una capacidad máxima de almacenamiento.


- Espacio compartido: el servidor de archivos presenta carpetas compartidas entre algunos o todos los usuarios, de manera de facilitar el proceso de compartir información.


La información almacenada en el servidor de archivos es resguardada periódicamente de acuerdo al Procedimiento de Resguardo de la información.


- Espacio Local


Se trata del/los discos locales de cada PC. Cada usuario es responsable de administrar el espacio de su/sus propios discos. Cabe destacar que la información de los discos locales no es resguardada periódicamente, por lo que cada usuario debe copiar al servidor de archivos la información importante que desee resguardar.


En caso de requerir la restauración de una copia de resguardo, el usuario deberá comunicarse con la Coordinación de Informática para efectuar el pedido.


Se encuentra prohibido el almacenamiento, tanto en la red como a nivel local, de material no relacionado con las actividades laborales de los usuarios, como ser:


- Material pornográfico


- Material que evidencia tendencias políticas, religiosas u otras ideologías


- Software u otro material protegido por la Ley de Propiedad Intelectual


- Software gratuito no relacionado con las actividades del Organismo


- Fotografías personales


- Archivos multimedia (música, video, etc.) no relacionados con las actividades laborales


5.4. USO DE LOS SISTEMAS


El Organismo provee a su personal el software para el desarrollo de sus actividades laborales, el cual es instalado por el Area Informática y debe ser utilizado únicamente para propósitos relacionados con las actividades del Organismo. Entre las actividades que se prohíben detallamos:


• Mantener software no licenciado en equipamiento del Organismo.


• Efectuar copias ilegales de software perteneciente al Organismo.


• Adquirir software sin la autorización previa y expresa del funcionario que corresponda.


• Intentar el acceso a información o sistemas restringidos dentro del Organismo.


• Atentar contra el correcto funcionamiento de los sistemas, por ejemplo, mediante la introducción de código malicioso.


5.5. USO DEL ACCESO A INTERNET


El Organismo otorga acceso a Internet a parte de su personal con el objeto de que dicho servicio beneficie el desarrollo de sus actividades. Por ello, el acceso a Internet por parte de los usuarios habilitados, así como su utilización deben responder únicamente a necesidades laborales. Entre las actividades que se prohíben detallamos:


• Instalar y/o utilizar herramientas de navegación que no son las aprobadas por el Area de Informática.


• Acceder a sitios que contengan material pornográfico o en cualquier aspecto obsceno o agresivo.


• Publicar información del Organismo o de su personal, excepto autorización previa y expresa.


• Transmitir por Internet o descargar:


- Material pornográfico


- Material que evidencia tendencias políticas, religiosas u otras ideologías


- Software u otro material protegido por la Ley de Propiedad Intelectual (infringiendo derechos de autor de terceros)


- Software gratuito no relacionado con las actividades del Organismo


- Fotografías personales


• Utilizar cualquier software de "chat" o participar de foros de "chat" en línea.


• Participar en listas de discusión y otros servicios que no se encuentren relacionados con sus actividades en el Organismo.


• Realizar actividades ilegales en el ámbito de Internet.


• Los servicios de Internet se encuentran operativos desde los días Lunes a las 07:00 hasta los Viernes a las 23:00 hs.


Con el objeto de minimizar el riesgo de violación a la seguridad a través del uso incorrecto del servicio de correo electrónico, se requiere el cumplimiento de lo siguiente:


• Analizar los archivos descargados con la herramienta antivirus instalada en las estaciones clientes.


• Desactivar la ejecución automática de código Java, JavaScript y ActiveX en la herramienta de navegación utilizada.


• Evitar el ingreso de datos personales confidenciales en sitios Web, excepto que los mismos cuenten con mecanismos de encripción para la transferencia de su información. Ante la duda, solicitar asistencia a Coordinación de Informática.


5.6. USO DEL CORREO ELECTRONICO


La casilla de correo otorgada al usuario es propiedad del Organismo, por lo que su utilización debe relacionarse sólo con fines laborales, relacionados con las actividades del Organismo.


Entre las actividades que están prohibidas las detallamos a continuación:


• Enviar o recibir correo electrónico con contenido relacionado con temas ajenos a las actividades que el usuario desempeña en el Organismo. Algunos ejemplos son:


- Saludos personales


- Material fotográfico


- Cadenas


- Anuncios comerciales


- Material pornográfico u obsceno


- Material que evidencie tendencias políticas, religiosas u otras ideologías


- Software u otro material protegido por la Ley de Propiedad Intelectual


- Software gratuito no relacionado con las actividades del Organismo


- Fotografías personales


• Utilizar el correo electrónico para efectuar amenazas u hostigamiento.


• Leer, interceptar o revelar comunicaciones electrónicas pertenecientes a otro usuario sin autorización previa expresa del mismo.


• Instalar y/o utilizar herramientas de navegación que no son las aprobadas por el Area de Informática.


• Utilizar lenguaje inapropiado en cualquier mensaje.


• Emitir juicio u opinar en forma personal frente a terceros. Tener en cuenta que al utilizar las direcciones de correo electrónico del Organismo están actuando en su representación.


• Enviar información perteneciente al Organismo a un tercero externo al mismo, excepto autorización previa expresa.


• Emitir comentarios peyorativos acerca del Organismo o su personal en foros públicos u otros medios de publicación electrónica.


• Utilizar el servicio de correo electrónico para ejercer actividades ilegales.


• Violar la Política de Seguridad del Organismo en cuanto a la seguridad de la información. Con el objeto de minimizar el riesgo de violación a la seguridad a través del uso incorrecto del servicio de correo electrónico, se requiere el cumplimiento de lo siguiente:


• Eliminar los mensajes de origen desconocido que contengan adjuntos, sin abrirlos y/o guardarlos localmente.


• Analizar los archivos recibidos antes de su descarga o ejecución con la herramienta antivirus instalada en las estaciones clientes.


• Bloquear la notificación automática de mensajes recibidos.


• Utilizar técnicas criptográficas en los casos en que se necesite garantizar autenticación, integridad y confidencialidad de la información incluida en el mensaje.


Con el objeto de optimizar el funcionamiento del servicio de correo electrónico, es deseable:


• Controlar la cantidad de destinatarios de los mensajes, enviando correos masivos sólo si es necesario y se cuenta con una adecuada justificación. El máximo de destinatarios no puede superar las (20) direcciones de correo.


• No adjuntar archivos mayores a 7MB. Es conveniente utilizar herramientas de compresión para minimizar el tamaño de los adjuntos.


• Solicitar la confirmación de un mensaje enviado sólo cuando sea necesario.


• Guardar los mensajes enviados sólo cuando sea de utilidad o necesidad.


• Realizar resguardos parciales de la casilla de correo con el objeto de asegurar la disponibilidad de los mensajes almacenados en la misma en caso de falla del servidor de correo, y liberar espacio ocupado innecesariamente en el servidor de correo.


• Eliminar los mensajes (enviados y recibidos) que no sea necesario conservar.


• La capacidad del buzón del Correo Electrónico no puede superar los 13 MB.


5.7. MONITOREO


Dado que tanto el equipamiento como los sistemas y los servicios de Internet y correo electrónico mencionados en el presente procedimiento son propiedad del Organismo, el mismo puede monitorear y/o auditar:


• El uso de la red y el equipamiento informático.


• El uso de los sistemas.


• El uso del servicio de acceso y navegación en Internet.


• El uso del servicio de correo electrónico, así como los mensajes enviados y recibidos por los usuarios. Para ello, el Organismo puede hacer uso de herramientas específicas diseñadas para tal fin.


5.8. UTILIZACION DE ANTIVIRUS


Es norma del Organismo:


En Programas Automáticos


• Se debe implementar un sistema automático de control antivirus para prevenir y eliminar las consecuencias de la acción de los virus informáticos.


• Los programas deben ser instalados por el área de Coordinación de Informática en los equipos centralizados de procesamiento y en las estaciones de trabajo de modo residente para que estén activados durante su uso.


Actualizaciones


• Se deben actualizar periódicamente las versiones de los programas antivirus y dicha situación debe estar reflejada en los contratos con el proveedor.


Archivos enviados y recibidos


• Los programas antivirus deben permitir la detección de virus en archivos enviados y recibidos vía el servicio de correo electrónico o desde otras redes de datos/Internet.


Otras medidas complementarias


• Adicionalmente se pueden realizar una ejecución periódica de otro programa antivirus en los equipos de procesamiento centralizado a los efectos de reforzar el control sobre todo el disco.


• El horario de operación de red es de 08:00 a 22:00 hs. En caso de excepciones, éstas deberán solicitarse por escrito a la Coordinación de Informática y serán analizadas.


• En el Ministerio de Desarrollo Social se encuentra instalado un antivirus automático y centralizado. Cabe destacar que el mencionado antivirus sólo puede instalarse en equipos con sistema operativo superior a Windows 98. Para las terminales que poseen versiones anteriores, se utilizan productos sin automatización.



CONTENIDO


1. OBJETIVO


2. ALCANCE


3. RESPONSABILIDADES


3.1. PROPIETARIO


3.2. RESPONSABLES DE CUMPLIMIENTO


3.3. RESPONSABLES DE ACTUALIZACION


4. REGIMEN DE REVISION Y ACTUALIZACION


5. DESARROLLO


6. METODOLOGIA DE TRABAJO


6.1. DESARROLLO DE SISTEMAS DE SOFTWARE


6.1.1. CAMBIO O ACTUALIZACION DE UN SISTEMA PREEXISTENTE


6.1.2. DESARROLLO DE UN NUEVO SISTEMA


6.2. PLANEAMIENTO DE PROYECTOS DE DESARROLLO DE SOFTWARE


6.2.1. INGENIERIA DE REQUERIMIENTOS


6.2.2. DETERMINACION DEL CICLO DE VIDA DEL PROYECTO


6.2.3. ANALISIS DE RIESGOS


6.2.4. DETERMINACION DE TAREAS


6.2.5. ESTIMACION DE TAREAS


6.2.6. SELECCION DEL PERSONAL


6.2.7. IMPLEMENTACION


6.3. CONTROL Y SEGUIMIENTO DE PROYECTOS DE DESARROLLO DE SOFTWARE


6.3.1. CONTROL DE CAMBIOS Y VERSIONES


6.3.2. SEGUIMIENTO DE TAREAS Y RIESGOS


6.3.3. REGISTRO Y ANALISIS DE METRICAS


6.3.4. ASEGURAMIENTO DE LA CALIDAD


6.3.5. TESTING


7. ANEXOS


ANEXO 1 - FORMULARIO DE SOLICITUD DE MODIFICACIONES A SISTEMAS


ANEXO 2 - FORMULARIO DE SOLICITUD DE NUEVO SISTEMA


ANEXO 3 - FORMULARIO DE PRUEBA DE USUARIO


1. OBJETIVO


Establecer pautas para regular la actividad de desarrollo de sistemas de la Coordinación de Informática.


2. ALCANCE


El presente procedimiento se aplica a todos los recursos humanos y autoridades del Organismo.


3. RESPONSABILIDADES


3.1. PROPIETARIO


El propietario del presente procedimiento es el Ing. Alberto Chedufau en su carácter de Responsable de Seguridad del Ministerio. Sus responsabilidades son:


- Establecer las medidas de seguridad necesarias para garantizar el adecuado almacenamiento del presente documento.


- Definir los perfiles que tendrán acceso al documento.


- Asegurar la accesibilidad del documento para quienes necesiten consultarlo.


- Comunicar la existencia del documento y asesorar sobre el mismo a los responsables de su cumplimiento.


- Solicitar actualizaciones fuera del esquema normal.


3.2. RESPONSABLES DE CUMPLIMIENTO


Es responsable del cumplimiento del presente procedimiento todo el personal del Organismo, así como terceros que hagan uso de cualquier recurso informático perteneciente al mismo.


3.3. RESPONSABLES DE ACTUALIZACION


El responsable de la actualización del presente procedimiento es el Ing. Alberto Chedufau en su carácter de Responsable de Seguridad del Ministerio. Su responsabilidad es revisar y actualizar en caso que corresponda, el presente documento de acuerdo al esquema de revisión y actualización establecido y a las solicitudes efectuadas por el propietario del mismo.


4. REGIMEN DE REVISION Y ACTUALIZACION


El presente documento será revisado semestralmente y actualizado en el caso de detectarse la necesidad de efectuar modificaciones que permitan mantenerlo actualizado en relación a la realidad de la estructura funcional y del ambiente informático.


Por otra parte, se realizarán las modificaciones que sean necesarias en el caso que se produjeran cambios que lo requieran, fuera de las revisiones programadas.


5. DESARROLLO


6. METODOLOGIA DE TRABAJO


6.1. DESARROLLO DE SISTEMAS DE SOFTWARE.


6.1.1. Cambio o actualización de un sistema preexistente.


Información necesaria:


• Nombre del sistema en el cual se desean realizar las modificaciones.


• Nombre del sector del Ministerio de Desarrollo Social solicitante.


• Nombre del funcionario a cargo del sector solicitante - Firma.


• Detalle de los requerimientos:


• Cambios a realizar (descripción lo más detallada posible acerca de los cambios que se requieren del sistema).


• Justificación.


• Disponibilidad horaria del funcionario o personal designado, responsable de suministrar la información según sea necesario, para responder a las consultas que surjan en el desarrollo del sistema.


Formulario (Ver anexo 1)


Procedimiento.


El sector solicitante deberá completar el formulario designado para modificación de un sistema existente que se remitirá a Coordinación Informática (ver anexo 1) donde se detallará la solicitud de modificación del sistema.


Se realizará un análisis de la factibilidad técnica para realizar dicha modificación teniendo en cuenta los siguientes factores:


• Tecnología necesaria (hardware, software y red).


• Disponibilidad temporal de desarrolladores y analistas.


• Impacto sobre el funcionamiento actual del sistema.


• Impacto sobre otras aplicaciones concurrentes al sistema a modificar.


• Disponibilidad de código fuente del sistema.


• Prioridades.


Asimismo, se podrá llevar a cabo un análisis de factibilidad económica, en el caso de ser necesaria la adquisición de software, hardware u otro elemento necesario para desarrollar el cambio en el sistema.


Una vez aprobadas las instancias anteriores, se procederá a designar la tarea a el/los desarrollador/ es dependiendo del perfil requerido.


A continuación, se procede al planeamiento y desarrollo del sistema por parte del personal designado, indicando la duración estimada, etapas, entregables e hitos de control.


En el proceso de desarrollo se debe incluir la fase de prueba del sistema por parte de los programadores.


Documentación:


• Documento técnico: Detalle de los procedimientos, funciones, versiones de software, código fuente, librerías, lenguaje de programación, etc. Se podrá anexar cualquier información extra que el desarrollador considere importante destacar.


• Documento de usuario: Descripción funcional del sistema, con orientación no técnica.


Una vez terminado el desarrollo se procede a la instalación o actualización del sistema. El mismo estará en estado de prueba por un período predefinido, en el cual el sector implicado deberá informar sobre el funcionamiento. De ser necesario, se capacitará a los usuarios del sistema.


Pasada esta etapa el sistema pasará al estado Funcionando, se dará por concluido el desarrollo liberando los recursos afectados.


De ser necesario, quedará personal afectado al soporte técnico para los usuarios del sistema.


6.1.2. Desarrollo de un nuevo sistema.


Información necesaria:


• Nombre del sector del Ministerio de Desarrollo Social solicitante.


• Nombre del funcionario a cargo del sector solicitante - Firma.


• Detalle de los requerimientos:


• Funciones que debe realizar el sistema (descripción lo más detallada posible acerca de las necesidades funcionales que se requieren del sistema).


• Justificación.


• Disponibilidad horaria del funcionario o personal designado responsable de suministrar la información, según sea necesario para responder a las consultas que surjan en el desarrollo del sistema.


Formulario (Ver anexo 2)


Procedimiento.


El sector solicitante deberá completar el formulario designado para el desarrollo de un sistema existente que se remitirá a Coordinación Informática (ver anexo 2), donde se detallará la solicitud de modificación del sistema.


Se realizará un análisis de la factibilidad técnica para realizar dicha modificación, teniendo en cuenta los siguientes factores:


• Tecnología necesaria (hardware y software).


• Disponibilidad temporal de desarrolladores y analistas.


• Impacto sobre otras aplicaciones concurrentes al sistema a modificar.


• Lenguaje de programación en el cual se desarrollará el sistema.


• Prioridades.


Análisis de factibilidad económica: en el caso de ser necesaria la adquisición de software, hardware u otro elemento necesario para desarrollar el cambio en el sistema.


Una vez aprobadas las instancias anteriores, se procederá a designar la tarea a el/los desarrollador/ es dependiendo del perfil requerido para la tarea.


Documentación:


• Documento técnico: Detalle de los procedimientos, funciones, versiones de software, código fuente, librerías, lenguaje de programación, etc. Se podrá anexar cualquier información extra que el desarrollador considere importante destacar.


• Documento de usuario: Descripción funcional del sistema, con orientación no técnica.


Se procede al planeamiento y desarrollo del sistema por parte del personal designado, indicando la duración estimada, etapas, entregables e hitos de control.


En el proceso de desarrollo se debe incluir la fase de prueba del sistema llevada a cabo por los programadores.


Una vez terminado el desarrollo se procede a la instalación o actualización del sistema. El sistema estará en estado de prueba por un período predefinido en el cual el sector implicado deberá informar sobre el funcionamiento.


De ser necesario se capacitará a los usuarios del sistema.


Pasada esta etapa el sistema pasará al estado Funcionando, se dará por concluido el desarrollo liberando los recursos afectados.


De ser necesario, quedará personal afectado al soporte técnico para los usuarios del sistema.


6.2. PLANEAMIENTO DE PROYECTOS DE DESARROLLO DE SOFTWARE.


Aprobada la realización de un proyecto por parte de Coordinación Informática se llevará a cabo la realización del planeamiento, desarrollo, implementación y seguimiento teniendo en cuenta la magnitud y escala del proyecto.


El proyecto de desarrollo de software deberá incluir en su ciclo de vida las siguientes etapas:


Planeamiento



6.2.1. Ingeniería de Requerimientos.


Del análisis de requerimientos se desprenderá la siguiente documentación: Lista de requerimientos, objetivos, alcances y roles.


Se determinarán dos tipos de requerimientos:


• Funcionales: Contienen las características que debe tener el sistema que describirán su funcionalidad, es decir, lo que debe hacer el sistema.


• No Funcionales: No describen el funcionamiento del sistema pero son igualmente importantes, pueden ser performance, disponibilidad, seguridad, interfaz, escalabilidad, volumen, robustez, recuperabilidad, etc.


• Restricciones: Por ejemplo, presupuesto, tiempo, software y hardware existentes.


Etapas de la ingeniería de requerimientos:


• Extracción de requerimientos.


• Análisis y especificación de requerimientos.


• Verificación y validación de requerimientos.


En la etapa de extracción de requerimientos, se hará un análisis del dominio del problema. Se utilizarán técnicas como entrevistas, encuestas, cuestionarios observaciones y prototipos.


En el análisis y especificación de requerimientos, se atacarán los problemas de ambigüedad, consistencia, completitud y correctitud.


La verificación asegurará que se cumplió el proceso de obtención de los requerimientos, mientras que la validación será el control de la etapa de análisis.


Es aconsejable el uso de herramientas como diagramas de transición de estados o diagramas de flujo de datos, para analizar y verificar requerimientos.


6.2.2. Determinación del ciclo de vida del proyecto


En el momento de determinar el ciclo de vida del proyecto, se debe también plantear las etapas por las que pasará el mismo.


Al dividir un proyecto complejo en etapas se consigue una mejor forma de administración, división de tareas, control y estimación de tiempos y costos.


Deberán plantearse las siguientes etapas, y ubicar a las actividades dentro de esa estructura:


• Idea


• Análisis de requerimientos.


• Diseño de la arquitectura.


• Diseño detallado.


• Codificación.


• Testing del sistema.


Pueden variar algunos conceptos, pero la estructura se debe mantener. Cabe la posibilidad de retroceder, pero no saltear etapas, aunque éstas pueden solaparse en la práctica.


6.2.3. Análisis de Riesgos


Se deben prever los posibles problemas que podrá enfrentar el proyecto. Un riesgo es un problema con probabilidad de ocurrencia.


El proceso consta de las siguientes etapas:






Identificación à Análisis à Planificación à Seguimiento à Control




A continuación se describen las etapas que se deben cubrir en el análisis de Riesgos.


Identificación del riesgo:


Identificar cada una de las condiciones que se deben cumplir para que exista la posibilidad de un problema.


Se puede documentar de la siguiente forma, enumerando cada riesgo:






Determinada Condición à Consecuencias




De esta manera, se podrán encontrar las fuentes de los riesgos.


Análisis de los Riesgos


• Evaluar los riesgos:


- Probabilidad: muy probable / poco probable.


- Impacto: alto / medio / bajo.


- Tiempo: corto plazo / medio plazo / largo plazo.


- Exposición al riesgo: Probabilidad x Impacto.


• Clasificar los riesgos (por ejemplo: por etapas, por causas, etc.)


• Definir Prioridades.


Planificación de Riesgos


• Asignar un responsable.


• Determinar el alcance y acciones.


• De ser posible eliminar riesgos.


• Seleccionar estrategias para reducir el impacto (si es imposible eliminarlo), ya sea reduciendo la probabilidad o el impacto.


• Planificar contingencias determinando el plan y el evento disparador.


Seguimiento de Riesgos


• Seguir el plan acordado.


• Seleccionar métricas.


• Elegir el evento disparador.


Control de riesgo


• Controlar las métricas.


• Controlar el evento disparador.


En esta parte del desarrollo, se utilizará esta metodología para realizar el seguimiento del proyecto y controlar los riesgos inherentes al mismo. Cabe destacar, que esta metodología puede ser usada en otros aspectos, como por ejemplo el análisis de planes de contingencias.


6.2.4. Determinación de Tareas


• Descomponer el proyecto en tareas (no deben ser ni muy grandes ni muy reducidas).


• Asignar dependencias.


• Asignar Recursos.


• Determinación de grupos de trabajo (organigrama funcional - roles)


• Elaboración del plan de implementación (distribución de software, migración de sistemas, instalación de hardware)


• Elaboración del plan (determinación de tiempos).


• Cumplimiento del plan.


6.2.5. Estimación de Tareas


En esta etapa, se procede a estimar el tiempo de las tareas y, consecuentemente poder determinar el tiempo total del proyecto y su costo asociado.


Los pasos a seguir son:


• Estimar tamaño: En este punto se pretende llegar a un número que describa la escala del proyecto, la unidad de medida podría ser líneas de código, puntos de función, etc.


• Estimar tiempos: Del tamaño del software se puede desprender los tiempos requeridos para llevarlos a cabo.


• Estimar costos.


6.2.6. Selección del personal


Una vez analizado el problema, Coordinación Informática determinará los roles y las características que tendrá el equipo de desarrollo, definiendo un organigrama funcional del proyecto.


Convocará a los seleccionados para que emprendan la elaboración y desarrollo del proyecto de software.


6.2.7. Implementación


En este punto, se procede a la instalación del software en las terminales de los sectores solicitantes, a la renovación de hardware y software necesarios para su correcto funcionamiento, a la capacitación de los usuarios y entrega de manual de operaciones del software.


6.3. CONTROL Y SEGUIMIENTO DE PROYECTOS DE DESARROLLO DE SOFTWARE.


Con el fin de poder establecer una rutina de control de la cartera de proyectos que maneja Coordinación Informática, en el seguimiento de proyectos de software se tendrán en cuenta las siguientes actividades:


Control Seguimiento


§
Control de cambios y versiones.


§
Seguimiento de tareas y riesgos.


§
Registro y análisis de métricas.


§
Aseguramiento de la calidad.


§
Testing.


§
Control de versiones.


De cada una de las acciones anteriores, se desprenderá la documentación pertinente, que describirá las tareas realizadas; como por ejemplo, el documento de la etapa de desarrollo será el código fuente.


6.3.1. Control de cambios y versiones.


Los objetivos de esta etapa son: determinar e identificar aquellas entidades de los productos de software que necesitan ser controladas.


Asegurarse que:


• Exista documentación y definiciones correctas.


• Los cambios sean realizados de manera controlada.


• Están siendo usadas versiones correctas de entidades o productos de software.


• Se sabe el punto exacto en el que se encuentra un producto de software (ej.: Testing, completado, en cambio, etc.)


Los pasos a seguir para llevar a cabo el control del software en desarrollo son:


Identificar los ítems a ser controlados, generalmente son código fuente y documentación (puede ser especificación de requerimientos, diseños, manual de usuarios, juegos de datos para realizar pruebas, resultados de pruebas, listas de usuarios, etc.


6.3.2. Seguimiento de tareas y riesgos.


6.3.3. Registro y análisis de métricas.


6.3.4. Aseguramiento de la Calidad.


6.3.5. Testing.


Esta etapa, se basa en el proceso de ejecutar un producto en evolución a fin de comprobar que los resultados que produce son los que se esperaba que produzca.


Los objetivos del testing son:


• Encontrar defectos en el producto.


• Hacer al producto eficiente.


• Hacer al producto eficaz.


El procedimiento de testing se realizará básicamente en dos entornos predefinidos: por un lado se realizará la prueba del producto en el ambiente de desarrollo; y por el otro, la prueba también será llevada a cabo por los usuarios finales del software. Con esto se logrará verificar los resultados esperados con los reales, para así cubrir cualquier excepción no contemplada.


A. Procedimiento de prueba en el ambiente de desarrollo


Seleccionar los casos de prueba: Lotes de datos que funcionarán como entrada al proceso, forzando a que se produzca una determinada situación.


Definir las condiciones en las que se realizará la prueba, analizar los ambientes en los cuales se realizará la prueba. En este punto se deberá tener en cuenta exactamente, cuál es el objetivo de la prueba.


Se definirá la magnitud del sistema de software en desarrollo, para determinar cuál es el tipo de pruebas conveniente para llevar adelante. Se dividirán en dos tipos diferentes de alcances: Pruebas de pequeña escala y pruebas de gran escala.


Pruebas de pequeña escala que se realizarán son:


• Prueba de caja negra


En esta prueba se contemplarán los datos de entrada, los reales y los esperados de salida.


El software funcionará como una "caja negra", en donde no se tendrá en cuenta el algoritmo ni el código del programa. Sólo se verificarán los datos entregados por el software y se evaluará si es lo que se esperaba obtener.


Se deben realizar tantas pruebas como juegos de datos se contemplen, que sean significativos para obtener información.


El procedimiento que se debe seguir en este caso, será el siguiente:


• Obtener los casos de prueba (es decir la información necesaria para correr el programa bajo una determinada condición).


• Ejecutar el programa con esos casos de prueba, y documentar los resultados obtenidos.


• Analizar los resultados que deberían haberse obtenido.


• Comparar ambos resultados.


• Documentar.


• Informar al desarrollador de los resultados obtenidos.



Esquema para la realización de la prueba de caja negra.


Todo el test se debe documentar de la siguiente forma:


Modelo de documentación:


§
Código o identificador de la prueba: (Nombre Sistema - Número de Prueba)


§
Nombre del sistema:


§
Objetivos de la prueba:


§
Datos de Entrada:


§
Resultados reales:


§
Resultados esperados:


§
Análisis de la prueba:


Se completará el formulario con la información de la prueba según se redactó anteriormente.


§
Prueba de caja blanca


La diferencia que tendrá esta prueba con la de caja negra, es que se realizará teniendo en cuenta el funcionamiento del software.


Mediante una prueba de escritorio basada en los algoritmos de funcionamiento del software se verificarán los resultados con los procesados por el programa. Esta prueba se llevará a cabo por los mismos programadores ya que deben tener el conocimiento del lenguaje de desarrollo y saber exactamente qué es lo que debería hacer el programa testeado.


El procedimiento que se debe seguir en este caso será el siguiente:


• Obtener los casos de prueba (es decir la información necesaria para correr el programa bajo una determinada condición).


• Mediante el algoritmo, código fuente y pruebas de escritorio, obtener un juego de datos que serán los resultados esperados del test.


• Ejecutar el programa con esos casos de prueba, documentar los resultados obtenidos.


• Comparar los resultados obtenidos con los resultados esperados


• Documentar y modificar el software.


La documentación de esta prueba es muy similar a la de la prueba de caja negra.


Modelo de Documentación:


§
Código o identificador de la prueba: (Nombre Sistema - Número de Prueba)


§
Nombre del sistema:


§
Objetivos de la prueba:


§
Datos de Entrada:


§
Resultados reales:


§
Resultados esperados:


§
Análisis de la prueba:


• Prueba de condiciones de borde


Esta prueba se realizará a partir de la premisa de analizar los resultados obtenidos ante un juego de datos, que sobrepasa las condiciones necesarias de los tipos de datos.


Se verificarán las variables utilizadas y se probarán con juegos de datos que no correspondan a esa variable. Por ejemplo, si el programa requiere del ingreso un número y se le ingresa una cadena de caracteres, el sistema debería alertar al usuario de la equivocación.


Un error grave sería que el sistema pase por alto esta verificación, y entregue un resultado incorrecto a este requerimiento. Si bien parece trivial, es muy importante que se verifiquen todos los controles y validaciones.


De esta prueba resultará un sistema más estable y confiable.


El procedimiento es el siguiente:


§
Detectar las variables modificadas por el ingreso de datos por parte del usuario.


§
Analizar los tipos de datos requeridos.


§
Provocar errores intencionales en el ingreso de datos.


§
Documentar y realizar las modificaciones necesarias.


Modelo de Documentación:


§
Código o identificador de la prueba: (Nombre Sistema - Número de Prueba)


§
Nombre del sistema:


§
Objetivos de la prueba:


• Variable testeada:


§
Resultados:


§
Análisis de la prueba:


Queda a criterio del programador o analista, la elección de las variables críticas que serán puestas a prueba.


Las pruebas de gran escala que se realizarán son:


Para sistemas complejos se realizarán pruebas especiales, que abarcarán tanto a los módulos del sistema como también al funcionamiento global.


A continuación se describen las partes que se deben contemplar en una prueba a gran escala.


• Prueba unitaria


Cada módulo que comprende al sistema, será probado en forma independiente, a través de las pruebas de caja blanca y de caja negra, descriptas anteriormente.


El objetivo es comprobar el funcionamiento de cada módulo en forma individual, para aislar errores de código y/o lógica del programa, sin que estos se propaguen más allá del módulo, objeto o función.


• Prueba de integración


Una vez que ya estén integrados al sistema, se verificará la comunicación e interacción entre los módulos, objetos y funciones. Se deben utilizar pruebas de caja negra y caja blanca para verificar este punto.


• Pruebas de Sistema


Se realizarán una serie de pruebas con el sistema funcionando. Apuntarán a los requerimientos no funcionales del sistema. Entre ellas se encuentran las siguientes:


§
Prueba de estrés: se intenta exceder los límites del sistema para verificar sus reacciones, por ejemplo capacidad, procesamiento, almacenamiento, acceso a través de una red, etc.


§
Prueba de rendimiento: verifica que el sistema soporta los volúmenes básicos definidos en la cuantificación de los requerimientos.


Junto con la realización de las pruebas, de debe entregar a Coordinación Informática, la documentación de todas las pruebas realizadas. Estos documentos formarán parte de la documentación del sistema.


B. Procedimiento de prueba por el usuario final.


Aparte de la realización de pruebas en un ambiente controlado, el usuario final encargado de la colaboración en el desarrollo, deberá probar el software. De este modo, se asegurará que se ajuste a los requerimientos, y también que el software no es susceptible a fallas, errores u omisiones no contempladas anteriormente.


Entre las pruebas que deben realizar los usuarios, se encuentran las siguientes:


• Pruebas de versión alfa y beta


Se les entregará una primera versión funcional del sistema a los usuarios. No será la versión final, tendrá funcionalidad completa o parcial según se requiera.


Prueba de versión alfa: será realizada por el usuario, pero en un ambiente controlado y de laboratorio.


Prueba de versión beta: la realizará el usuario, pero en sus instalaciones, donde funcionará la versión final del sistema.


• Prueba de aceptación del usuario


En esta prueba se verificará que la funcionalidad del sistema, cumpla con lo que fue requerido por el usuario.


El usuario completará un formulario (Anexo 3), que será remitido a Coordinación Informática, en el cual dejará constancia de la aceptación o requerimiento de modificación del software probado.


7. ANEXOS


• ANEXO 1 - FORMULARIO DE SOLICITUD DE MODIFICACIONES A SISTEMAS.



Instructivo Formulario 2 - Formulario de solicitud de nuevo sistema.


1- Sector Solicitante: Se debe indicar el sector desde el cual surge el requerimiento y que hará uso del sistema en cuestión. Si se utilizan siglas para denominar al sector se debe aclarar el nombre completo.


2- Tareas a realizar: Describir lo más completo posible el requerimiento sobre el sistema, es decir, explicar cuáles son las tareas que se requieren que el sistema realice. Este punto es de suma importancia ya que de lo que se detalle aquí se desprenderá el resultado del desarrollo.


3- Justificación: En este ítem se detallará las necesidades por la cual es necesario la modificación del sistema. Se podrán contemplar los beneficios, beneficiarios y supuestos (resultantes de la no actualización del sistema).


4- Personal a cargo de consultas: Es de gran importancia designar a una persona encargada para ser el responsable de contestar dudas a los desarrolladores acerca del funcionamiento del sector que esté implicado al sistema. La cooperación e implicación de esta persona es vital para el éxito del sistema. Cabe destacar que el encargado de esta tarea deberá conocer el sistema en cuestión o ser el usuario directo del mismo.


5- Disponibilidad: En este punto se debe completar el rango horario en el cual, el encargado estará dispuesto a colaborar con el desarrollador o analista.


6- Firma y aclaración del responsable del sector: La solicitud únicamente la podrán realizar los Sres. Secretarios, Subsecretarios, Directores Generales, Directores y Coordinadores de áreas.


• ANEXO 3 - FORMULARIO DE PRUEBA DE USUARIO.



CONTENIDO


1. OBJETIVO


2. ALCANCE


3. RESPONSABILIDADES


3.1. PROPIETARIO


3.2. RESPONSABLES DE ACTUALIZACION


4. REGIMEN DE REVISION Y ACTUALIZACION


5. DESARROLLO


5.1. INSTRUMENTACION DE LA FIRMA DEL COMPROMISO


5.2. MODIFICACION DEL COMPROMISO


6. ANEXO


1. OBJETIVO


Desarrollar y mantener actualizado un "Compromiso de confidencialidad y aceptación de la Política de Seguridad de la Información" a ser firmado por todos los usuarios.


2. ALCANCE


El "Compromiso de confidencialidad y aceptación de la Política de Seguridad de la Información" será firmado por todo el personal del Organismo, cualquiera fuese su situación de revista.


3. RESPONSABILIDADES


3.1. PROPIETARIO


El propietario del presente procedimiento es el Ing. Alberto Chedufau, responsable de la Seguridad de la Información del Ministerio. Sus responsabilidades son:


3.1.1- Establecer las medidas de seguridad necesarias para garantizar el adecuado almacenamiento del presente documento.


3.1.2- Definir los perfiles que tendrán acceso al documento.


3.1.3- Asegurar la accesibilidad del documento para quienes necesiten consultarlo.


3.1.4- Comunicar la existencia del documento y asesorar sobre el mismo a los responsables de su cumplimiento.


3.1.5- Solicitar actualizaciones fuera del esquema normal.


3.2. RESPONSABLES DE ACTUALIZACION.


El responsable de la actualización del presente procedimiento es el Ing. Alberto Chedufau, responsable de la Seguridad de la Información del Ministerio. Su responsabilidad es revisar, actualizar en caso que corresponda, y archivar el presente documento de acuerdo al esquema de revisión y actualización establecido y a las solicitudes efectuadas por el propietario del mismo.


4. REGIMEN DE REVISION Y ACTUALIZACION


El presente documento será revisado anualmente y actualizado en el caso de detectarse la necesidad de efectuar modificaciones que permitan mantenerlo actualizado en relación a la realidad de la estructura funcional y del ambiente informático.


Por otra parte, se realizarán las modificaciones que sean necesarias en el caso que se produjeran cambios que lo requieran, fuera de las revisiones programadas.


5. DESARROLLO


5.1. INSTRUMENTACION DE LA FIRMA DEL COMPROMISO


Una copia del Modelo de Compromiso adjunto en el Anexo a este documento, o su versión adaptada por el organismo, será firmada por todo el personal actual del Organismo y aquel que se incorpore en adelante, cualquiera fuese su situación de revista.


La Dirección General de Recursos Humanos y Organización será la encargada de instrumentar la firma y de archivar las copias de Compromisos firmados en los respectivos legajos del personal.


5.2. MODIFICACION DEL COMPROMISO


En caso que el Compromiso sea modificado, el Responsable de Actualización (designado previamente) informará a la Dirección General de Asuntos Jurídicos sobre la existencia de una nueva versión del Compromiso.


La Dirección General de Asuntos Jurídicos evaluará si las modificaciones ameritan la renovación de la firma por parte de los empleados. De ser así, lo comunicará a la Dirección General de Recursos Humanos y Organización, donde se instrumentará la nueva firma para todo el personal. Cabe aclarar que la Dirección General de Asuntos Jurídicos, por su competencia en el marco legal que reviste el compromiso, puede solicitar modificaciones al mismo en caso de que lo crea conveniente o necesario. En este caso, se deberá coordinar la modificación con el Responsable de Actualización.


6. ANEXO



CONTENIDO


1. OBJETIVO


2. ALCANCE


3. RESPONSABILIDADES


3.1. PROPIETARIO


3.2. RESPONSABLES DE CUMPLIMIENTO


3.3. RESPONSABLES DE ACTUALIZACION


4. REGIMEN DE REVISION Y ACTUALIZACION


5. DESARROLLO


6. ANEXO


6.1. FORMULARIO DE SOLICITUD DE RECUPERACION DE INFORMACION


1. OBJETIVO


Definir los pasos a seguir para procesar la solicitud de recuperación de información perdida o dañada.


2. ALCANCE


El presente procedimiento será aplicado en cualquier caso que se requiera la recuperación de información del Organismo, la cual haya sido contemplada en los esquemas de resguardo Establecidos.


3. RESPONSABILIDADES


3.1. PROPIETARIO


El propietario del presente procedimiento es el Ing. Alberto Chedufau en su carácter de Responsable de Seguridad Informática. Sus responsabilidades son:


- Establecer las medidas de seguridad necesarias para garantizar el adecuado almacenamiento del presente documento.


- Definir los perfiles que tendrán acceso al documento.


- Asegurar la accesibilidad del documento para quienes necesiten consultarlo.


- Comunicar la existencia del documento y asesorar sobre el mismo a los responsables de su cumplimiento.


- Solicitar actualizaciones fuera del esquema normal.


3.2. RESPONSABLES DE CUMPLIMIENTO


Es responsable del cumplimiento del presente procedimiento todo el personal del Organismo, así como terceros que hagan uso de cualquier recurso informático perteneciente al mismo.


3.3. RESPONSABLES DE ACTUALIZACION


El responsable de la actualización del presente procedimiento es el Ing. Alberto Chedufau en su carácter de Responsable de Seguridad Informática. Su responsabilidad es revisar y actualizar en caso que corresponda, el presente documento de acuerdo al esquema de revisión y actualización establecido y a las solicitudes efectuadas por el propietario del mismo.


4. REGIMEN DE REVISION Y ACTUALIZACION


El presente documento será revisado semestralmente y actualizado en el caso de detectarse la necesidad de efectuar modificaciones que permitan mantenerlo actualizado en relación a la realidad de la estructura funcional y del ambiente informático.


Por otra parte, se realizarán las modificaciones que sean necesarias en el caso que se produjeran cambios que lo requieran, fuera de las revisiones programadas.


5. DESARROLLO


5.1. SOLICITUD DE RECUPERACION DE INFORMACION


La información del Organismo, almacenada y/o manejada por la tecnología informática (sistemas, servidores, etc.) puede sufrir pérdidas o daños causados por amenazas existentes, como ser, fallas de hardware, error humano, ataques a la seguridad, etc.


En los casos en que un usuario detecte la pérdida o daño de información del Organismo seguirá el siguiente procedimiento con el objeto de solicitar su recuperación a partir de las copias de resguardo.


a) El usuario completará el formulario de "Solicitud de la recuperación de información" (Ver 6.1. SOLICITUD DE RECUPERACION DE INFORMACION") con la siguiente información:


- Datos del usuario solicitante


- Información afectada: indicando una breve descripción de la información en cuestión, su nivel de criticidad de acuerdo a la clasificación oficial de la misma, la fecha en la cual se ha generado y la última fecha de actualización de la misma.


- Motivo: se indicará la causa por la cual se solicita la recuperación de la información. Ej.: pérdida por fallas de hardware, eliminación accidental, etc.


b) El usuario firmará el formulario y lo enviará al Propietario de la información afectada.


c) El Propietario de la información afectada autorizará la recuperación de considerarlo apropiado y enviará el formulario al Responsable Técnico del entorno informático donde se ubica la información.


d) El Responsable Técnico evaluará la posibilidad de efectuar la recuperación de la información en el entorno productivo o si es necesario realizar el proceso en otro entorno con el objeto de no afectar la normal operatoria.


e) Finalmente el formulario será derivado al operador a cargo de la realización de la recuperación, quien ejecutará las acciones técnicas. Una vez finalizadas dichas tareas, firmará el formulario, lo entregará al Responsable de Seguridad Informática para su archivo y comunicará a los usuarios involucrados en la solicitud la conclusión del proceso.


6. ANEXO


6.1. SOLICITUD DE RECUPERACION DE INFORMACION


SOLICITUD DE RECUPERACION DE INFORMACION



INSTRUCTIVO PARA COMPLETAR


SOLICITUD DE RECUPERACION DE INFORMACION


1- Debe completarse con la fecha de presentación del trámite. Es un dato indispensable para su correcta administración.


2- Este ítem debe ser completado sólo por Coordinación de Informática, con la hora en que se recibió el trámite y el número de solicitud que corresponda.


3- Escribir apellido y nombres completos: Por Ej. Pérez, Martín Alejandro.


4- Especificar el edificio donde se desempeña su actividad. Ejemplo: 9 de Julio.


5- Especificar el nombre del área a la cual pertenece el usuario.


6- Especificar el número y el ala (Moreno- Belgrano -centro) a la cual pertenece el usuario.


7- Especificar el/los números de internos donde ubicar al usuario.


8- En este punto se detallan características y ubicación de la información a recuperar.


9- Se debe hacer una cruz en el casillero que corresponda según la importancia de la información.


10- Especificar la fecha en la que fue creado el archivo.


11- Especificar la fecha en la que fue modificado el archivo.


12- Fundamentar el porqué es necesaria la recuperación de la Información


13- El jefe o Director del área debe firmar y aclarar su firma para aprobar la solicitud del usuario.


14- El usuario solicitante debe firmar el formulario.


15- El jefe o Director debe aclarar la firma.


16- El solicitante debe aclarar la firma


e. 14/8 NΊ 553.890 v. 14/8/2007


Responder Tema "Citar Tema"
Respuestas