informe de auditorÍa · objeto de analizar la seguridad y la calidad de la información almacenada...
TRANSCRIPT
1
INFORME DE AUDITORÍA
Al Sr. Secretario de Hacienda del
Ministerio de Economía
D. Juan Carlos Pezoa
En uso de las facultades conferidas por el artículo 118 de la Ley Nº 24.156, la
AUDITORÍA GENERAL DE LA NACIÓN (AGN) procedió a efectuar un examen en el
ámbito de la SECRETARÍA DE HACIENDA (SH), con el objeto que se detalla en el
apartado 1.
1. – OBJETO DE LA AUDITORÍA
Auditoría informática del Sistema Integrado de Información Financiera de la Secretaría de
Hacienda dependiente del Ministerio de Economía y Finanzas Públicas de la Nación con el
objeto de analizar la seguridad y la calidad de la información almacenada e informada por
el mismo.
Período auditado: Año 2009.
2. – ALCANCE DEL EXAMEN
El examen fue realizado de conformidad con normas de auditoría externa de la
AUDITORÍA GENERAL DE LA NACIÓN, aprobadas por la Resolución Nº 145/93,
dictadas en virtud de las facultades conferidas por el artículo 119, inciso d) de la Ley Nº
24.156.
Para la evaluación se tomaron como referencia los estándares internacionales de auditoría,
en particular, COBIT (Control Objectives for Information and Related Technology),
referido a los controles en la Tecnología de la Información (TI).
2.1 Relevamiento
Documentación solicitada:
Informes de auditoría interna.
Informes de auditoría externa.
2
Plan de desarrollo y mantenimiento de sistemas de información. Estado de situación
del proyecto SIDIF.
La lista de todas las relaciones actuales, en el tema informático, con terceros y
copias de los contratos con proveedores, referentes a servicios de desarrollo de
aplicaciones, si existen; los contratos con el proveedor de intercambio electrónico
de datos; los contratos de alquiler o arrendamiento; de mantenimiento del hardware
y software y los contratos de seguros vinculados con la función de servicios de
información.
La política de calidad, el manual de calidad y el plan de calidad de la función
servicios de información.
Plan de administración de la configuración. Inventario de la configuración:
hardware, software del sistema operativo, software de aplicación, instalaciones y
archivos de datos (a nivel interno y externo).
Modelo de la arquitectura de la información.
Diccionario de Datos del Organismo.
Esquema de la red de comunicaciones.
La evaluación del riesgo tecnológico que pudiera causar errores en el cumplimiento
de la misión del organismo.
El plan de continuidad de la función servicios de información.
Política de seguridad, manual de seguridad informática.
Política, procedimientos y metodología de ciclo de vida de sistemas.
Informes de monitoreo de la infraestructura tecnológica: red de comunicaciones,
desempeño de servidores, control interno y otros.
Diagrama de Entidad-Relación del SIDIF.
Manuales del Usuario del SIDIF.
2.2. – Entrevistas realizadas
Dentro de la estructura del proyecto e-SIDIF:
Directora del Proyecto.
Responsable de la Coordinación de Análisis.
3
Responsable de la Coordinación Diseño y Desarrollo.
Responsable de la Coordinación de Testing.
Responsable de la Coordinación Ingeniería.
Responsable de Arquitectura de Aplicación.
Responsable de Arquitectura Física.
Responsable de la Coordinación de Mantenimiento.
Responsable de Convivencia.
Coordinador del Grupo de Orientación al Desarrollo (GOD).
Unidad informática:
Director de la Unidad Informática.
Subdirector de la Unidad Informática.
Responsable de la Coordinación de Bases de Datos.
Responsable de la Coordinación de Producción.
Responsable de la Coordinación de Seguridad.
Responsable de la Coordinación de Unix y Comunicaciones.
Coordinador de Administración de Servidores Windows.
Coordinador de Calidad.
Contaduría General de la Nación:
Dirección de Auditoría de Sistemas (DAS).
Además, se llevaron a cabo visitas a usuarios del SIDIF en la Auditoría General de la
Nación y en el INCUCAI con el propósito de relevar el nivel de satisfacción de los
usuarios.
Por otra parte, se solicitó a personal de la AGN asesoramiento en temas de Contabilidad
Pública.
Las tareas de campo abarcaron desde mayo del 2010 hasta noviembre del 2010.
3. – ACLARACIONES PREVIAS
3.1. – El SIDIF
3.2.1. – SIDIF Central
4
En el marco de la Reforma Administrativa y Financiera del Sector Público (Ley Nº 24.156,
del 29 de octubre de 1992) y con el financiamiento del Banco Mundial (préstamo 3362-
AR) y el Banco Interamericano de Desarrollo (préstamo 826/OC-AR), se diseñó, desarrolló
e implementó a partir de 1993 el SIDIF (Sistema Integrado de Información Financiera), un
sistema a medida que permitió la formulación del presupuesto nacional y sus
modificaciones, la programación de la ejecución presupuestaria, la ejecución presupuestaria
de gastos y recursos y la contabilidad general a nivel transaccional, movimientos de fondos,
órdenes de pago y deuda exigible, conciliación bancaria, transferencia electrónica de pagos,
embargos y cesiones, entre otros.
De esta manera, la administración financiera integró el presupuesto con la contabilidad y la
tesorería agregando funcionalidades como la obtención de balance conforme al método de
la partida doble y la programación financiera.
3.2.2. – SIDIF Locales
Para su gestión presupuestaria y contable, los Servicios Administrativo-Financieros (SAF)
de las distintas jurisdicciones de la Administración Central han contado, en su gran
mayoría, con sistemas locales provistos por la UI como CONPRE (Consolidación
Presupuestaria), SIDIF OD –organismos descentralizados–, SIGRAC –específico para la
administración central y recientemente dado de baja–, y a partir de 2001 el SLU (SIDIF
Local Unificado). Otros organismos adoptaron soluciones diferentes, como sistemas
comprados a terceros o desarrollos propios. Funcionalmente, los sistemas mencionados son
distintos e independientes, pero cada uno de ellos permite realizar transacciones en
conexión con el SIDIF Central utilizando para ello un sistema de transferencia de datos
denominado TRANSAF.
3.2.3. – El SIDIF Internet (e-SIDIF)
En Noviembre del año 2003 la Subsecretaría de Presupuesto comenzó a estudiar la
factibilidad de desarrollar la actualización tecnológica del SIDIF, aprovechando los
avances en materia de comunicaciones y nuevas tecnologías de entorno web. El objetivo
planteado fue generar un nuevo producto –el SIDIF Internet– que cubriera la funcionalidad
de la administración financiera del Estado tanto para el nivel central como para los
5
organismos, acorde con los requerimientos de la Ley de Administración Financiera y
Sistema de Control.
3.2.4. – Convivencia
La estrategia de implementación se ha definido como gradual y por lo tanto de coexistencia
con los actuales sistemas SIDIF (Central y Locales).
3.2.5. – Metodología de Desarrollo
El sistema se desarrolla como un sistema orientado a objetos y documentado utilizando el
lenguaje de modelado UML (Unified Modeling Language). Se ha adoptado el Proceso
Unificado Racional (RUP –Rational Unified Process–) como marco genérico para el
desarrollo del sistema.
3.2.6. – Centro de Cómputos
EL procesamiento del sistema es realizado por la Unidad Informática (UI) que cuenta con
locales en sede de la SH y, como respaldo, en AFIP (Administración Federal de Ingresos
Públicos). El proyecto e-SIDIF ocupa espacio de procesamiento en los equipos de la UI
para las tareas de desarrollo y testing.
4. – COMENTARIOS Y OBSERVACIONES
Los Objetivos de Control describen los resultados que debe alcanzar un organismo
implantando procedimientos de control en los procesos de TI.
Para cada una de las Observaciones se menciona el nivel de madurez que le corresponde,
conforme al Modelo de Madurez de la Capacidad incluido en el Anexo IV. En el punto 6,
se encuentran las Recomendaciones para mejorar el ambiente de control y reducir los
riesgos.
Además, para cada uno de los objetivos de control, se indica qué requerimientos de la
información (detallados en el Anexo V) son afectados.
Se destaca que cada objetivo de control va acompañado de su nivel de riesgo genérico
(alto, medio o bajo) que le es propio, poniendo en evidencia el impacto provocado por su
incumplimiento y sin estar vinculado con la situación del organismo. Ese nivel genérico es
modificado por el índice de madurez correspondiente (dependiente de las observaciones
realizadas) para establecer el riesgo específico para ese objetivo, en el caso particular.
6
Puede observarse en los gráficos del anexo que un objetivo de control que tiene implícito
un riesgo genérico alto y fue calificado con un índice de madurez alto, genera un riesgo
específico menor que aquel que tenga un riesgo genérico medio o bajo y un índice de
madurez bajo.
4.1. – Planificación y Organización
4.1.1. – Evaluación de riesgos
Objetivo de control: La máxima autoridad debe definir un proceso por el cual el
organismo se ocupa de identificar los riesgos de Tecnología de la Información y analizar su
impacto, involucrando funciones multidisciplinarias y adoptando medidas eficaces en
función de costos a fin de su mitigación.
Este objetivo de control afecta, primariamente:
la confidencialidad
la integridad
la disponibilidad
y en forma secundaria:
la eficacia
la eficiencia
el cumplimiento
la confiabilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de madurez: Repetible. Se identificaron mediciones básicas que deben monitorearse.
Se definieron métodos y técnicas de recopilación y evaluación, pero los procesos no se
adoptaron en todo el organismo. Se crean funciones de planificación y administración para
evaluar los procesos de monitoreo, pero las decisiones se toman sobre la base de la pericia
de personas clave. Se eligen e implementan herramientas limitadas para recopilar
información. La función de servicios de información se administra como un centro de
costos, sin evaluar su contribución a las áreas sustantivas del organismo.
Observaciones: No existen procedimientos formales para la generación de informes
internos referentes a la utilización de los recursos informáticos (personal, instalaciones,
7
sistemas de aplicación, tecnología y datos), ni para realizar controles del desempeño a fin
de brindar información confiable en forma oportuna.
4.1.2. – Administración de calidad
Objetivo de control: Se debe elaborar un sistema de administración de calidad con
procesos y estándares probados de desarrollo y de adquisición. Los requerimientos de
calidad se deben manifestar y documentar con indicadores cuantificables y alcanzables. La
mejora continua se logra por medio del constante monitoreo, corrección de errores y la
comunicación de los resultados a los interesados.
Este objetivo de control afecta, primariamente:
la eficacia
la eficiencia
la integridad
y en forma secundaria:
la confiabilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de madurez: Repetible. El organismo se vale de informes de control informales para
iniciar las acciones correctivas. La evaluación depende de las habilidades de personas
clave. Se comenzaron a establecer indicadores básicos. La gestión de servicios de
información realiza el monitoreo de la eficacia de los controles internos críticos. Se
empiezan a usar metodologías y herramientas específicas para el ambiente de TI, aunque
no uniformemente.
Observaciones: No existen procedimientos formales para monitorear los controles
internos, evaluar su eficacia y realizar informes en forma periódica.
4.2. – Adquisición e Implementación
4.2.1. – Adquisición y Mantenimiento del Software de Aplicación
Objetivo de control: Las aplicaciones deben estar disponibles de acuerdo con los
requerimientos del organismo. Este proceso cubre su diseño, la inclusión apropiada de
controles aplicativos y requerimientos de seguridad, y el desarrollo y la configuración en sí
de acuerdo a los estándares. Esto permite a las organizaciones apoyar la operatividad de sus
objetivos, de forma apropiada con las aplicaciones automatizadas correctas.
8
Se deben establecer estrategias de adquisición de software y evaluación de requerimientos
y especificaciones para la contratación de terceros proveedores de servicios.
La adquisición y mantenimiento del software aplicativo debe realizarse por medio de la
definición específica de requerimientos funcionales y operativos con una implementación
por etapas de prestaciones claras.
Este objetivo de control afecta, primariamente:
la eficacia
la eficiencia
y en forma secundaria:
la integridad
el cumplimiento
la confiabilidad
Nivel de riesgo: [ ] Alto [X] Medio [ ] Bajo
Nivel de madurez: Definido. Existe un proceso claro, definido y de comprensión general
para la adquisición y mantenimiento de software aplicativo. Este proceso va de acuerdo con
la estrategia de TI y del negocio. Se intenta aplicar los procesos de manera consistente a
través de diferentes aplicaciones y proyectos. Las metodologías son, por lo general,
inflexibles y difíciles de aplicar en todos los casos, por eso es muy probable que se salten
pasos. Las actividades de mantenimiento se planean, programan y coordinan
Observaciones: En relación a los sistemas residuales que van a ser desafectados en el
futuro, la aplicación de la metodología de Ciclo de Vida de Desarrollo de Sistemas
(CVDS) es más laxa en relación al aseguramiento de la calidad del software.
Además, el SLU, que será reemplazado por el e-SIDIF, presenta inconvenientes en la
interpretación de algunas pantallas que no disponen de ayuda en línea.
4.2.2. – Desarrollo y Mantenimiento de Procedimientos
Objetivo de control: Se debe aplicar un enfoque estructurado para el desarrollo de
procedimientos del usuario y de operaciones, requerimientos de servicios y materiales de
capacitación. La metodología del Ciclo de Vida de Desarrollo de Sistemas del organismo
debe garantizar la definición oportuna de los requerimientos operativos y niveles de
9
servicio, la preparación de manuales del usuario y de operaciones y el desarrollo de
materiales de capacitación.
Este objetivo de control afecta, primariamente:
la eficacia
la eficiencia
y en forma secundaria:
la integridad
el cumplimiento
la confiabilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de madurez: Definido. Existe un esquema bien definido, aceptado y comprendido
para documentación del usuario, manuales de operación y materiales de entrenamiento
establecidos en la metodología de Ciclo de Vida de Desarrollo de Sistemas (CVDS). Se
guardan y se mantienen los procedimientos en un reservorio formal y cualquiera que
necesite saber tiene acceso a ellos. Se encuentran disponibles fuera de línea y se pueden
acceder y mantener en caso de desastre. Las correcciones a la documentación y a los
procedimientos se realizan por reacción. Existe un proceso que especifica las
actualizaciones y los materiales de entrenamiento para que sea un entregable explícito de
un proyecto de cambio. Se mantienen las distintas versiones. Los usuarios se involucran en
la generación participando en las distintas etapas del CVDS. Se utilizan herramientas
automatizadas en la generación y distribución. Se planea y programa tanto el entrenamiento
del negocio como de los usuario.
Observaciones: Debido a que existen una cantidad difícil de manejar de usuarios externos,
la actualización de la documentación se informa a través de la distribución de boletines
informativos. La inclusión de todos los usuarios del sistema en esta distribución no está
garantizada. Tampoco es controlada la recepción de los envíos.
4.3. – Entrega y Soporte
4.3.1. – Definición y Administración de los Niveles de Servicio
10
Objetivo de control: La máxima autoridad debe definir un marco que promueva el
establecimiento de acuerdos de nivel de servicio y formalice los criterios de desempeño en
virtud de los cuales se medirá su cantidad y calidad.
Este objetivo de control afecta, primariamente:
la eficacia
la eficiencia
y en forma secundaria:
la confidencialidad
la integridad
la disponibilidad
el cumplimiento
la confiabilidad
Nivel de riesgo: [ ] Alto [X] Medio [ ] Bajo
Nivel de madurez: Proceso Definido. Las responsabilidades están bien definidas, pero con
autoridad discrecional. Existe un proceso de desarrollo de acuerdos de nivel de servicio con
puntos de verificación para reevaluar los niveles de servicio y la satisfacción de los
clientes. Los criterios de niveles de servicio están definidos y convenidos con los usuarios,
y son cada vez mas estandarizados. Se identifican las deficiencias en los niveles de
servicio, aunque la planificación de resolución es todavía informal. El nivel de servicio se
basa cada vez más en las comparaciones y tal vez no aborde todas las necesidades
específicas del organismo.
Observaciones: En todos los organismos donde se instalan las aplicaciones UEPEX, SLU
o e-SIDIF se firma un acta acuerdo con la Secretaria de Hacienda en la cual figuran las
obligaciones de cada una de las partes.
Dentro de las obligaciones de la Secretaria de Hacienda se pueden mencionar:
Definir los tiempos, asumir los costos de implantación y establecer la modalidad de
mantenimiento del sistema instalado.
Designar un equipo de Réplica responsable de las tareas de: realizar el cronograma
de implantación, su seguimiento, realizar la capacitación a usuarios, efectuar el
11
proceso de réplica del sistema, etc.
Se compromete a brindar seguridad y confiabilidad a la base de datos y resguardad
la privacidad de los datos.
Verificación de hardware necesario para el correcto funcionamiento del aplicativo
instalado.
Administrar la red de comunicaciones involucrada en la conexión del aplicativo con
la base de datos de la Secretaria de Hacienda.
Mantener y actualizar los aplicativos instalados.
Dentro de las obligaciones a cago del organismo están:
Adoptar explícitamente los aplicativos instalados, e incorporarlos a la gestión
adoptando las normativas y procedimientos necesarios establecidos por la Secretaria
de Hacienda.
Designar un interlocutor del proyecto.
Designar un grupo de usuarios para que estos reciban la capacitación
correspondiente.
Proveer de espacios físicos y libre acceso al Persona de la Secretaria de Hacienda.
Proveer del hardware necesario para la instalación de los aplicativos según las
especificaciones de las NUI-3 de la Unidad informática.
Contratar las licencias de bases de datos, sistemas operativos y software de base
necesarios para el normal funcionamiento del sistema.
Contratar un servicio de enlace digital entre el organismo y la Secretaria de
Hacienda.
Prestar conformidad a la implantación del sistema y su comunicación con los
sistemas de la Secretaria de Hacienda.
Estas actas no incluyen acuerdos de niveles de operación ni como serán monitoreados
estos acuerdos.
No se recibieron estadísticas de monitoreo que permitan identificar tendencias.
No se encontró evidencia de la realización de revisiones de los acuerdos que garanticen
que son efectivos.
12
4.3.2. – Administración de Servicios Prestados por Terceros
Objetivo de control: El directorio debe implementar medidas de control orientadas a la
revisión y al monitoreo de los contratos y procedimientos existentes para garantizar su
eficacia y el cumplimiento de la política del organismo.
Este objetivo de control afecta, primariamente:
la eficacia
la eficiencia
y en forma secundaria:
la confidencialidad
la integridad
la disponibilidad
el cumplimiento
la confiabilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de madurez: Repetible. El proceso de supervisión de los proveedores de servicios y
la prestación de los servicios es informal. Se usa un contrato firmado pro forma con
términos y condiciones estándares para los proveedores y una descripción de los servicios a
prestar. Se toman mediciones, pero no son relevantes. Hay informes disponibles, aunque
no dan soporte a los objetivos de las actividades sustantivas del organismo.
Observaciones: No existen políticas formalmente definidas referidas a las relaciones con
terceros. El Organismo realiza las adquisiciones cumpliendo con el Régimen de
Contrataciones de la Administración Nacional y con las recomendaciones de la ONTI para
los elementos informáticos. No se encontraron en las órdenes de compra analizadas
documentación que defina la relación entre contratistas y subcontratistas. En la
documentación recibida no se encontraron informes sobre el desempeño de los
proveedores.
4.3.3 – Garantía de la Seguridad de los Sistemas
Objetivo de control: La necesidad de mantener la integridad de la información y de
proteger los activos de TI, requiere de un proceso de administración de la seguridad. Este
13
proceso incluye el establecimiento y mantenimiento de los roles y responsabilidades, las
políticas, estándares y procedimientos de seguridad y pruebas periódicas así como realizar
acciones correctivas sobre las debilidades o incidentes identificados.
Este objetivo de control afecta, primariamente:
la confidencialidad
la integridad
y en forma secundaria:
la disponibilidad
el cumplimiento
la confiabilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de madurez: Proceso Definido. La dirección tiene conciencia de la seguridad y la
promueve. Se estandarizaron y formalizaron sesiones informativas sobre temas de
seguridad. Los procedimientos de seguridad de TI están definidos e integrados en una
estructura de políticas y procedimientos de seguridad. Las responsabilidades de la
seguridad de TI están asignadas, aunque no se observan en forma consistente. Existe un
plan de seguridad de TI con análisis de riesgos y soluciones de seguridad. El informe de la
seguridad de TI se concentra en la función de TI y no en la misión del organismo. Se
realizan pruebas de intrusión ad hoc.
Observaciones: Existe el Equipo Prácticas de Seguridad Informática (EPSI) formado por 2
representantes de la coordinación de Seguridad Informática, un representante de
Desarrollo, representantes por los Órganos Rectores, de la Subsecretaria de Presupuesto y
de la Subsecretaria de Relaciones con Provincias.
La seguridad de los módulos del sistema SIDIF depende de distintas áreas y organismos.
En los SAF la responsabilidad de la seguridad les corresponde a los administradores
locales, la misma fue delegada por los administradores centrales de la Secretaria de
Hacienda. La coordinación de Seguridad es la única que puede dar altas a y administrar los
permisos de los administradores locales del sistema.
14
En dicha secretaria los datos utilizan la red de datos del Ministerio de Economía, encargada
de su defensa perimetral. Los datos se almacenan en servidores que dependen de la Unidad
Informática de la Secretaria de Hacienda, responsable de su custodia. Los servicios de
Internet y correo electrónico dependen del Ministerio de Economía
Los sistemas SIDIF Central, SLU y e-SIDIF autentifican al usuario mediante nombre y
contraseña que debe tener un mínimo de 7 caracteres y debe incluir mayúsculas,
minúsculas, números y caracteres especiales que debe cambiarse obligatoriamente cada 30
días.
Las cuentas se bloquean automáticamente en el caso en que hubiera cuatro intentos fallidos
de acceso o cuando la cuenta no registra actividad durante dos meses. A los 150 días de no
utilizarse la cuenta se da de baja.
Las solicitudes de alta de usuarios externos se realiza por medio de un mail firmado
digitalmente que incluye un formulario en Word que contiene los datos del empleado y el o
los aplicativos que serán utilizados. El centro de atención a usuarios valida el pedido y lo
deriva a ARAT para que verifique que el administrador local este habilitado o sea
autorizado por el Director General de Administración.
El área de Seguridad Informática de la Unidad Informática adopta las recomendaciones de
la ONTI en lo referente a Políticas de Seguridad de la Información.
Mediante la Resolución 71 publicada el 5 de Abril de 2010 se aprobó la Política de
Seguridad de la Información de la Secretaria de Hacienda que estará vigente hasta que el
Ministerio de Economía tenga aprobada una que abarque a todo el organismo.
Existe y esta implementada una política de pantallas y escritorios limpios.
Se realizan distintas tareas de concientización sobre seguridad informática que incluyen
correos electrónicos, mensajes, los protectores de pantallas poseen imágenes y textos que
hacen mención a la importancia de la seguridad informática.
No llevan estadísticas ni realizan informes periódicos sobre incidentes de seguridad,
solamente se realizan informes a solicitud de la Coordinación General en casos
particulares.
No se hacen reportes sobre incidentes menores, estos quedan almacenados en el Sistema de
Gestión de Reclamos (SGR).
15
4.3.4 – Administración de Datos
Objetivo de control: La máxima autoridad debe establecer y mantener una combinación
eficaz de controles generales y de aplicación sobre las operaciones de Tecnología de la
Información para asegurar que los datos permanezcan durante su entrada, actualización y
almacenamiento completos, precisos y válidos.
Este objetivo de control afecta, primariamente:
la integridad
la confiabilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de madurez: Proceso Definido. Se entiende y se acepta la necesidad de integridad de
los datos a lo largo del organismo. Hay normas de entrada, procesamiento y salida de datos
formalizadas que se hacen cumplir. El proceso de identificación y corrección de errores es
automatizado. Se asignó la responsabilidad sobre los datos y la integridad y seguridad son
controladas por la parte responsable. Se usan técnicas automatizadas para prevenir y
detectar errores e inconsistencias. Las definiciones, reglas y requerimientos relacionados
con los datos son claramente documentados y mantenidos por una función de
administración de base de datos. Los datos se vuelven consistentes en todas las plataformas
y a lo largo de la organización. La función de servicios de información asume el papel de
custodio, mientras que el control de la integridad de los datos pasa al responsable de los
datos. La dirección se basa en informes y análisis para tomar decisiones y planificar a
futuro.
Observaciones: Existen 243 bases de datos en producción (1 SIDIF Central, 104 SLU, 133
UEPEX, 1 e-SIDIF, 1 SIDIF OD, 1 Budi, 1 Proa, 1 Data-Warehouse)
Las bases de datos utilizan motores Oracle v9, v10, v11; existiendo además bases en SQL
SERVER 2000.
Los datos cargados al sistema son propiedad de cada SAF. La unidad informática se ocupa
de mantener la infraestructura de las bases de datos y no es su responsabilidad el control de
los procesos funcionales que producen los datos.
16
La Coordinación de Bases de Datos puede realizar cambios en las bases que se encuentran
en el entorno de producción a solicitud de los dueños de los datos mediante una nota
escrita.
No existe un diccionario de datos formalmente definido. Se encuentran definidos solamente
los objetos y las relaciones entre los mismos.
Para el desarrollo del proyecto e-SIDIF se tomó la decisión de que los nuevos módulos de
aplicaciones y bases convivieran con aplicaciones anteriores (SLU, SIDIF Central). Esta
convivencia se realiza mediante interfases entre los sistemas (DBLink, Advanced Queue) a
fin de adaptar los formatos de los datos para que sean interpretados por los distintos
sistemas. Estas interfaces aumentan el riesgo de falta de integridad en los datos. Para
minimizar este inconveniente la Dirección de Auditoría de Sistemas de la Contaduría
General de la Nación controla el 100% de los datos que figuran en más de una base,
generando sobrecarga en el procesamiento.
4.4. Monitoreo
4.4.1 Monitoreo de los Procesos
Objetivo de control: La máxima autoridad debe impulsar la definición de indicadores del
desempeño relevantes, el informe sistemático y oportuno y la acción inmediata en caso de
desviaciones.
Este objetivo de control afecta, primariamente:
la eficacia
y en forma secundaria:
la eficiencia
la confidencialidad
la integridad
la disponibilidad
el cumplimiento
la confiabilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
17
Nivel de madurez: Repetible. Se identificaron mediciones básicas que deben monitorearse.
Se definieron métodos y técnicas de recopilación y evaluación, pero los procesos no se
adoptaron en toda el organismo. Se crean funciones de planificación y administración para
evaluar los procesos de monitoreo, pero las decisiones se toman sobre la base de la pericia
de personas clave. Se eligen e implementan herramientas limitadas para recopilar
información. La función de servicios de información se administra como un centro de
costos, sin evaluar su contribución a las áreas sustantivas del organismo.
Observaciones: No existen procedimientos formales para la generación de informes
internos referentes a la utilización de los recursos informáticos (personal, instalaciones,
sistemas de aplicación, tecnología y datos), lo que implica falta de control de su
desempeño.
4.4.2 Evaluación de la idoneidad del control interno
Objetivo de control: Debe existir el compromiso del funcionario principal de servicios de
información de monitorear los controles internos, evaluar su eficacia y realizar informes en
forma periódica.
Este objetivo de control afecta, primariamente:
la eficacia
la eficiencia
y en forma secundaria:
la confidencialidad
la integridad
la disponibilidad
el cumplimiento
la confiabilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de madurez: Repetible. El organismo se vale de informes de control informales para
iniciar las acciones correctivas. La evaluación depende de las habilidades de personas
clave. Se comenzaron a establecer indicadores básicos. La gestión de servicios de
información realiza el monitoreo de la eficacia de los controles internos críticos. Se
18
empiezan a usar metodologías y herramientas específicas para el ambiente de TI, aunque
no uniformemente.
Observaciones: No existen procedimientos formales para monitorear los controles
internos, evaluar su eficacia y realizar informes en forma periódica.
4.4.3 Obtención de garantía independiente
Objetivo de control: Se deben realizar en forma periódica revisiones de garantía
independiente de la seguridad y los controles internos.
Este objetivo de control afecta, primariamente:
el cumplimiento
y en forma secundaria:
la confiabilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de madurez: Inicial. Se usan procesos de certificación y aseguramiento solo en
casos excepcionales. La certificación y la garantía están impulsadas, por ejemplo, por
cambios regulatorios, requerimientos o demanda de los usuarios. El proceso de garantía es
efectuado con una actitud reactiva.
Observaciones: No se han formalizado los procedimientos para manejar las actividades de
de auditoría independientemente del área de TI. Se realiza una auditoría de datos por parte
de la Contaduría General de la Nación (CGN), a través de su dirección de Auditoría de
Sistemas (DAS). No existen procedimientos de certificación de capacidad de proveedores
externos, cuando prácticamente todo el personal de TI es contratado. Las auditorías de
SIGEN y de la Auditoría Interna del Ministerio son eventuales.
4.4.4 Provisión de auditoría independiente
Objetivo de control: Deben realizar en forma periódica auditorías independientes.
Este objetivo de control afecta, primariamente:
la eficacia
la eficiencia
y en forma secundaria:
la confidencialidad
19
la integridad
la disponibilidad
el cumplimiento
la confiabilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de madurez: Repetible. Las autoridades reconocen que la obtención de auditoria
independiente sería potencialmente útil, pero no hay una política escrita que defina su
finalidad, autoridad y responsabilidades. La Subsecretaría de Presupuesto no estableció una
infraestructura y un proceso para garantizar que regularmente se lleven a cabo auditorias
independientes.
Observaciones: No hay política formal respecto de la Auditoría Independiente. No existe
un Comité de Auditoría, ni Plan de Auditoría Externa e Interna (salvo para la realizada por
la CGN en los datos).
5. – Comunicación del proyecto de informe y análisis de los descargos formulados por
la Secretaría de Hacienda.
El Proyecto de Informe de auditoría fue enviado al Organismo auditado para que formule
las observaciones y/o comentarios que estime pertinentes, con fecha 30 de marzo de 2011,
por Nota AGN N° 47/11-A02. Los mismos fueron remitidos por la Secretaría de Hacienda
el 20 de mayo de 2011, luego de la prórroga solicitada con fecha 29 de abril de 2011.
Como consecuencia del análisis del descargo presentado por el Organismo auditado (que
consta como Anexo VII), se ratifican las observaciones oportunamente formuladas.
6. – RECOMENDACIONES
6.1. – Planificación y organización
6.1.1. – Evaluación de Riesgos: Establecer un marco de evaluación sistemática de riesgos.
Dicho marco debe incorporar una evaluación periódica de los riesgos de información
relacionados con la consecución de los objetivos del organismo, que constituya una base
para determinar cómo deben administrarse los riesgos a un nivel aceptable. El
departamento de TI debe garantizar que se realice:
20
- una evaluación de riesgos de la actividad,
- la identificación de riesgos,
- la medición de riesgos,
- un plan de acción de reducción de riesgos,
- la aceptación de riesgos.
6.1.2. – Administración de la Calidad: Desarrollar y mantener periódicamente un plan
general de calidad basado en los planes del organismo y de tecnología de información a
largo plazo. Es recomendable que el jefe de proyecto de TI garantice que exista:
- un plan general de calidad,
- un enfoque de garantía de calidad,
- una planificación de garantía de calidad,
- la revisión de garantía de calidad en cuanto al cumplimiento de las normas y
procedimientos de TI,
- una metodología del ciclo de vida del desarrollo de sistemas,
- una metodología para la introducción de cambios importantes en la tecnología existente,
- la actualización de la metodología del ciclo de vida del desarrollo de sistemas,
- la coordinación y comunicación entre los usuarios y el personal de TI,
- un marco de adquisición y mantenimiento de la infraestructura tecnológica,
- un marco para las relaciones con terceros a cargo de la implementación,
- la observación de las normas de documentación de programas, verificando que:
se cumplan las normas de prueba de programas
se cumplan las normas de prueba de sistemas
se utilicen pruebas en paralelo/piloto
- la documentación de pruebas de sistemas.
6.2. – Administración e Implementación
6.2.1. – Adquisición y Mantenimiento del Software de Aplicación: Definir una
metodología de adquisición e implementación formal.
- Implementar herramientas de soporte automatizadas.
- Establecer una metodología para fijar qué requerimientos clave son prioritarios.
21
- Monitorear el cumplimiento con la arquitectura de TI del organismo, incluyendo
un proceso formal de aprobación de las desviaciones
6.2.2. – Desarrollo y Mantenimiento de Procedimientos: Definir acuerdos de nivel de
servicio.
- Diseñar la infraestructura y estructura organizativa para promover y compartir la
documentación del usuario, los procedimientos técnicos y el material de capacitación entre
los instructores, la mesa de ayuda y los grupos de usuarios.
- Definir los planes de capacitación del organismo y de TI.
- Mantener el inventario de aplicativos, los procedimientos del organismo y de TI
utilizando herramientas automatizadas.
- Definir el proceso de desarrollo asegurando el uso de procedimientos operativos
estándar y una apariencia estándar.
- Definir un marco estándar para la documentación y los procedimientos.
6.3. – Entrega y Soporte
6.3.1. – Definición y Administración de los Niveles de Servicio: Garantizar la eficacia de
las políticas y prácticas establecidas para las siguientes tareas y/o actividades de TI:
- establecer marco de acuerdos de nivel de servicio,
- procedimientos de ejecución,
- monitoreo e informes,
- revisión de los contratos y acuerdos de nivel de servicio,
- establecer un programa de mejora del servicio.
6.3.2. – Administración de Servicios Prestados por Terceros: Verificar que los servicios
prestados por terceros se identifiquen de modo adecuado y que la interrelación técnica y
funcional con los proveedores esté documentada. La conducción del organismo debe
garantizar la eficacia de las políticas y prácticas establecidas para las siguientes tareas y/o
actividades de TI:
- interrelación con proveedores de TI,
- asignar la responsabilidad por tales relaciones,
- formalización de contratos con terceros,
- evaluación del conocimiento y la experiencia de terceros,
22
- formalización de contratos de tercerización,
- asegurar la continuidad de los servicios,
- acordar las relaciones de seguridad,
- monitoreo de la prestación del servicio.
6.3.3. – Garantía de la Seguridad de los Sistemas: Es necesario que el jefe de proyecto
de TI garantice la eficacia de las políticas y prácticas establecidas para las siguientes tareas
y/o actividades de TI:
- administración de las medidas de seguridad,
- identificación, autenticación y acceso,
- la seguridad del acceso en línea a los datos,
- administración de cuentas de usuarios,
- revisión de la gerencia de cuentas de usuarios,
- el control ejercido por el usuario en sus propias cuentas,
- la supervisión de la seguridad,
- clasificación de los datos,
- administración centralizada de identificaciones y derechos de acceso,
- realizar informes de violación y actividades de seguridad,
- manejo de incidentes,
- acreditación de soluciones,
- normar la confianza en la contraparte,
- autorización de transacciones,
- establecer la imposibilidad de rechazo,
- definir ruta de acceso confiable,
- protección de las funciones de seguridad,
- administración de claves criptográficas,
- prevención, detección y corrección de software malicioso,
- establecer arquitectura de firewalls y conexiones con redes públicas,
- protección del valor electrónico.
23
6.3.4. – Administración de Datos: Es necesario que la jefatura de TI, los responsables de
programas y actividades y el jefe de operaciones garanticen la eficacia de los
procedimientos y prácticas establecidas para las siguientes tareas y/o actividades de TI:
- preparación de datos,
- autorización de documentos fuente,
- recopilación de datos de documentos fuente,
- manejo de errores de documentos fuente,
- conservación de documentos fuente,
- autorización de entrada de datos,
- verificación de exactitud, integridad y autorización,
- manejo de errores de entrada de datos,
- asegurar la integridad del procesamiento de datos,
- validación y edición del procesamiento de datos,
- manejo de errores del procesamiento de datos,
- manejo y conservación de salidas,
- distribución de salidas de datos,
- balanceo y conciliación de salidas de datos,
- revisión y manejo de errores de salidas de datos,
- seguridad de los informes de salida,
- protección de información crítica durante la transmisión y el transporte,
- protección de información crítica eliminada,
- administración del almacenamiento,
- establecer períodos de conservación y condiciones de almacenamiento,
- establecer un sistema de administración de biblioteca de medios,
- definir las responsabilidades de administración de la biblioteca de medios,
- resguardo y restauración,
- tareas de resguardo,
- almacenamiento de resguardos,
- administración de archivos,
- protección de mensajes críticos,
24
- autenticación e integridad.
6.4. – Monitoreo
6.4.1. – Monitoreo de los Procesos: La Unidad Informática y el Grupo de desarrollo y
mantenimiento de aplicativos son responsables de que se definan los indicadores de
desempeño pertinentes y que se recopilen datos para la elaboración de informes de gestión
e informes de excepción con respecto a estos indicadores. La evaluación de la función
servicios de información se debe llevar a cabo en forma continua. En este aspecto, la
Subsecretaría de Presupuesto es responsable de garantizar:
- que se recopilan los datos de monitoreo,
- que se evalúa el desempeño en forma continua,
- que se evalúa la satisfacción del usuario,
- que se elaboran informes de gestión.
6.4.2. – Evaluación de la idoneidad del control interno: La Unidad Informática y el
Grupo de desarrollo y mantenimiento de aplicativos son responsables de monitorear la
eficacia de los controles internos en el curso normal de las operaciones. Además, las
desviaciones graves deben informarse a la máxima autoridad del organismo. La
Subsecretaría de Presupuesto es responsable de garantizar:
- el monitoreo del control interno,
- la operación oportuna del control interno,
- los informes del nivel de control interno.
6.4.3. – Obtención de garantía independiente: Es necesario que la Subsecretaría de
Presupuesto obtenga la garantía independiente de la seguridad y los controles internos de
los servicios de TI, de la eficacia de los proveedores de servicios de TI, del cumplimiento
de requisitos legales y regulatorios y de los compromisos contractuales. Además, debe
garantizar que la función de Auditoría Interna posea la competencia técnica, y las
capacidades y conocimientos necesarios, para llevar a cabo dichas revisiones de un modo
eficaz, eficiente, y económico. En este aspecto, la Subsecretaría de Presupuesto es
responsable de garantizar:
- la acreditación independiente de la seguridad y el control interno de los servicios de TI,
25
- la certificación independiente de la seguridad y el control interno de los terceros
proveedores de servicios de TI,
- la evaluación independiente de la eficacia de los servicios de TI,
- la evaluación independiente de la eficacia de los terceros proveedores de servicios de TI
- la garantía independiente del cumplimiento de los requerimientos legales y regulatorios y
los compromisos contractuales,
- la garantía independiente del cumplimiento de los requerimientos legales y regulatorios y
los compromisos contractuales por partes terceros proveedores de servicios de TI,
- la competencia de la función de auditoría interna,
- la participación proactiva en la auditoría,
6.4.4. – Provisión de auditoría independiente: Es necesario que la Subsecretaría de
Presupuesto pueda establecer la responsabilidad primaria y acciones para la función de
auditoría interna, que resuma la responsabilidad, facultad y rendición de cuentas de la
función de auditoría informática. Además, debe ser revisado periódicamente (auditorías
externas) para garantizar que se mantenga la independencia, facultad y responsabilidad de
la función de auditoría informática. En este aspecto, la máxima autoridad y el funcionario
principal de auditoría interna son responsables de garantizar:
- la definición del alcance de las responsabilidades de auditoría informática para la función
de Auditoría,
- la independencia de los auditores internos,
- el cumplimiento del código de ética y normas profesionales,
- la competencia del plantel de auditoría informática,
- la planificación de los proyectos de auditoría,
- la ejecución del trabajo de auditoría,
- la elaboración de informes,
- las actividades de seguimiento de recomendaciones.
7. – CONCLUSIONES
El desarrollo de e-SIDIF, se encuentra en una etapa de transición que le confiere a la
información un riesgo superior al recomendable (Anexo III). Tal situación se presenta,
26
entre otros motivos, por la necesidad de que convivan los módulos ya desarrollados, junto
con productos anteriores como el SLU, SIDIF central, y SIDIF carácter (éste sería
desafectado en diciembre del 2010, fuera del período de la auditoría). Esta circunstancia se
traduce en la coexistencia de varias bases de datos con su duplicación y/o triplicación.
Para mitigar este inconveniente se han desarrollado una serie de procedimientos,
automáticos y manuales, que verifican que el mismo dato tenga el mismo valor en todas sus
apariciones.
La solución final a este problema, solo existirá cuando se termine el desarrollo de los
módulos faltantes y se migre la totalidad de los organismos usuarios al nuevo sistema
permitiendo abandonar definitivamente los anteriores, y con ello unificar los datos en una
única base.
A la fecha de finalización de los trabajos de campo, faltaba finalizar los siguientes
módulos:
Etapa 3 del módulo de Pagos
Etapas 2 y 3 del módulo de Gastos
Pasajes y viáticos
Fondos rotatorios.
Considerando que aún resta una parte importante del proyecto para transportar todo a una
única base, se destaca que deben realizarse todos los esfuerzos disponibles para terminar
con ésta situación que pone en riesgo la confiabilidad e integridad de los datos.
Cabe destacar por otra parte que, las pruebas realizadas junto con el personal de la AGN al
cual se le solicitara colaboración en las tareas, así como las consultas que se llevaron a cabo
con los usuarios directos del SIDIF, concluyeron que los datos verificados, no presentaron
errores que justifiquen su mención.
27
8. – LUGAR Y FECHA
BUENOS AIRES, DICIEMBRE DE 2010.
9. – FIRMA
28
ANEXO I
Gráficos de brecha para los niveles de madurez de los objetivos de control evaluados.
29
Dia
gra
ma
de
bre
ch
as
en
Pla
nif
icac
ión
y O
rgan
iza
ció
n
012345
4.1.
1 E
valu
ació
n de
Rie
sgos
4.1.
2 A
dmin
istr
ació
n de
la c
alid
ad
4.2.
1 A
dqui
sici
ón
Sof
twar
e de
Apl
icac
ión
4.2.
2 D
esar
rollo
y M
ante
nim
ient
o de
Pro
cedi
mie
ntos
4.3.
1 A
dmin
istr
ació
n de
niv
eles
de
serv
icio
s
4.3.
2 A
dmin
istr
ació
n de
Ser
vici
os d
e T
erce
ros
4.3.
3 G
aran
tía
de la
Seg
urid
ad d
e lo
s S
iste
mas
4.3.
4 A
dmin
istr
ació
n de
Dat
os
4.4.
1 M
onito
reo
de lo
s pr
oces
os
4.4.
2 Id
onei
dad
del c
ontr
ol in
tern
o
4.4.
3 O
bten
ción
de
Gar
antí
a In
depe
ndie
nte
4.4.
4 P
rovi
sión
de
Aud
itorí
a In
depe
ndie
nte
3: E
stan
dar
acep
tabl
e2:
Rep
etib
le1
: In
icia
lN
ive
l de
la o
rgan
iza
cion
30
ANEXO II: Estimación de los Niveles de Riesgo para los requerimientos de la
información según los procesos informáticos considerados
La alta velocidad con la que se producen los cambios en la tecnología informática hace
necesario optimizar la gestión de los riesgos relacionados con ella. Las misiones y
funciones críticas de los organismos dependen en forma creciente de los sistemas de TI en
un ambiente donde también aumentan las noticias sobre fraudes y desastres informáticos.
En la actualidad se entiende que la gestión de riesgos relacionados con la TI es un elemento
esencial de la administración del Estado Nacional.
En esta auditoría se trabajó sobre doce objetivos de control, cada uno de los cuales se
corresponde con un proceso de tecnología informática.
Cada proceso hace a uno o más de los requerimientos que debe satisfacer la información
dentro de un organismo para permitirle cumplir con sus misiones y funciones (ver Anexo
V).
En los doce casos se indica dentro de las observaciones que requerimientos son afectados
en forma primaria y secundaria por el objetivo de control (ver Tabla I).
El objeto de este Anexo es brindar parámetros cuantificables para establecer un Tablero de
Control que posibilite conocer los problemas con mayor riesgo y al mismo tiempo controlar
las mejoras que se produzcan en el futuro en forma explícita.
Se entiende como riesgo de un requerimiento a un valor que simboliza la probabilidad de
que la información carezca del mencionado requisito. Este valor fluctúa entre cero y uno,
siendo cero la situación más segura y uno la más insegura.
El proceso de cálculo parte de la base de que el riesgo es directamente proporcional al
impacto definiendo como impacto el peligro de incumplimiento de las misiones y
funciones del organismo, para los procesos involucrados en el objetivo de control, y a la
probabilidad de ocurrencia del evento.
Para cada uno de los procesos se definió el impacto como alto (99%), medio (66%) o bajo
(33%).
31
Tabla I
Requerimiento de la información
Dom
inio
Proceso
efec
tivi
dad
efic
ien
cia
con
fid
enci
alid
ad
inte
grid
ad
dis
pon
ibil
idad
cum
pli
mie
nto
con
fiab
ilid
ad
4.1.1 Evaluar riesgos S S P P P S S
P y
O
4.1.2 Administrar calidad P P P S
4.2.1 Adquirir y mantener software de aplicación P P S S S
A y
M
4.2.2 Desarrollar y mantener procedimientos P P S S S
4.3.1 Definir niveles de servicio P P S S S S S
4.3.2 Administrar servicios de terceros P P S S S S S
4.3.3 Garantizar la seguridad de sistemas P P S S S
Ent
rega
y S
opor
te
de S
ervi
cios
4.3.4 Administrar la información P P
4.4.1 Monitoreo de los procesos P S S S S S S
4.4.2 Evaluar la idoneidad del control interno P S S S S S S
4.4.3 Obtención de garantía independiente P S S S S S S
Mon
itor
eo
4.4.4 Provisión de auditoría independiente P S S S S S S
La probabilidad de ocurrencia está directamente vinculada a la calidad del control que se
realiza, y éste es evaluado en el informe a través del nivel alcanzado según el modelo de
madurez. A cada nivel se le asignó un coeficiente según el siguiente detalle:
Nivel de Madurez Coeficiente
No conforma 1,00
Inicial 0,80
Repetible 0,50
Proceso Definido 0,30
Administrado 0,20
Optimizado 0,10
32
ANEXO III
Gráfico de los niveles de riesgo de cada uno de los requerimientos de la información
para los 12 objetivos de control ponderados y su promedio general.
33
Nive
les
de R
iesg
o pa
ra la
Efic
acia
0,00
0,10
0,20
0,30
0,40
0,50
0,60
0,70
0,80
0,90
1,00
4.1.1
4.1.2
4.2.1
4.2.2
4.3.1
4.3.2
4.4.1
4.4.2
4.4.3
4.4.4
Obje
tivo
de c
ontro
l
Ries
gos P
rimar
ios
Ries
go S
ecun
dario
Ries
go A
cept
able
34
Nive
les
de R
iesg
o pa
ra la
Efic
ienc
ia
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,91
4.1.1
4.1.2
4.2.1
4.2.2
4.3.1
4.3.2
4.4.1
4.4.2
4.4.3
4.4.4
Obje
tivos
de
cont
rol
Ries
gos P
rimar
ios
Ries
gos S
ecun
dario
s
Ries
go A
cept
able
35
Nive
les
de R
iesg
o pa
ra la
Con
fiden
cial
idad
0,00
0,10
0,20
0,30
0,40
0,50
0,60
0,70
0,80
0,90
1,00
4.1.1
4.3.1
4.3.2
4.3.3
4.4.1
4.4.2
4.4.3
4.4.4
Obje
tivos
de
cont
rol
Ries
gos P
rimar
ios
Ries
gos S
ecun
dario
s
Ries
go A
cept
able
36
Nive
les
de R
iesg
o pa
ra la
Inte
grid
ad
0,00
0,10
0,20
0,30
0,40
0,50
0,60
0,70
0,80
0,90
1,00
4.1.1
4.1.2
4.2.1
4.2.2
4.3.1
4.3.2
4.3.3
4.3.4
4.4.1
4.4.2
4.4.3
4.4.4
Obje
tivos
de
cont
rol
Ries
gos P
rimar
ios
Ries
gos S
ecun
dario
s
Ries
go A
cept
able
37
Nive
les
de R
iesg
o pa
ra la
Dis
poni
bilid
ad
0,00
0,10
0,20
0,30
0,40
0,50
0,60
0,70
0,80
0,90
1,00
4.1.1
4.3.1
4.3.2
4.3.3
4.4.1
4.4.2
4.4.3
4.4.4
Obje
tivos
de
cont
rol
Ries
gos P
rimar
ios
Ries
gos S
ecun
dario
s
Ries
go A
cept
able
38
Nive
les
de R
iesg
o pa
ra e
l Cum
plim
ient
o
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,91
4.1.1
4.2.1
4.2.2
4.3.1
4.3.2
4.3.3
4.4.1
4.4.2
4.4.3
4.4.4
Obje
tivos
de
cont
rol
Ries
gos P
rimar
ios
Ries
gos S
ecun
dario
s
Ries
go A
cept
able
39
Nive
les
de R
iesg
o pa
ra la
Con
fiabi
lidad
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,91
4.1.1
4.1.2
4.2.1
4.2.2
4.3.1
4.3.2
4.3.3
4.3.4
4.4.1
4.4.2
4.4.3
4.4.4
Obje
tivos
de
cont
rol
Ries
gos P
rimar
ios
Ries
gos S
ecun
dario
s
Ries
go A
cept
able
40
Nive
les
prom
edio
de
riesg
o e
n lo
s ob
jetiv
os d
e co
ntro
l con
side
rado
s.
0,00
0,10
0,20
0,30
0,40
0,50
0,60
0,70
0,80
0,90
1,00
efica
ciaef
icien
ciaco
nfide
ncial
idad
integ
ridad
dispo
nibilid
adcu
mpli
mien
to
conf
iabilid
ad
Requ
erim
ient
o de
la in
form
ació
n
Ries
gos P
rom
edios
Ries
go A
cept
able
41
ANEXO IV
Niveles del Modelo Genérico de Madurez
0 – No conforma. Falta total de procesos reconocibles. La organización no reconoce que
existe un tema a ser tenido en cuenta.
1 – Inicial. La organización reconoce la existencia del tema y la necesidad de atenderlo. Sin
embargo, no existen procesos estandarizados sino aproximaciones ad hoc que suelen ser
aplicadas sobre una base individual o caso por caso. La administración aparece como
desorganizada.
2 – Repetible. Los procesos han evolucionado hasta la etapa en la cual procedimientos
similares son ejecutados por distintas personas que desarrollan las mismas tareas. No hay
entrenamiento formal ni comunicación de procedimientos estándar y la responsabilidad es
asumida por cada individuo. Hay un alto grado de confianza en el conocimiento de los
individuos y los errores son probables.
3 – Proceso Definido. Los procedimientos han sido estandarizados, documentados y
comunicados vía entrenamiento. Sin embargo, es responsabilidad de los individuos cumplir
con estos procesos y es improbable que se detecten las desviaciones. Los procedimientos
en sí mismos no son sofisticados pero son la formalización de prácticas existentes.
4 – Administrado. Es posible monitorear y medir el cumplimiento de los procedimientos y
accionar cuando los procesos parecen no estar trabajando adecuadamente. Los procesos
están bajo mejora constante y proveen una práctica correcta. El uso de herramientas y de
automatización es limitado o fragmentario.
5 – Optimizado. Los procesos han sido corregidos al nivel de la mejor práctica, en base a
los resultados de la mejora continua y de la movilización con otras organizaciones. La TI es
usada de forma integrada para automatizar el flujo de trabajo, proveer herramientas para
mejorar la calidad y la eficacia y hacer que la organización se adapte rápidamente a los
cambios.
42
ANEXO V
Requerimientos de la información
Eficacia: Que la información sea relevante y pertinente para la misión del ente, y que su
entrega sea oportuna, correcta, consistente y utilizable.
Eficiencia: Que se provea información a través de la utilización óptima (más productiva y
económica) de recursos.
Confidencialidad: Que se proteja la información sensible de la divulgación no autorizada.
Integridad: Que la información sea precisa y suficiente, y válida de acuerdo con los valores
y expectativas del organismo.
Disponibilidad: Que la información esté disponible cuando sea requerida por las misiones
del organismo, ahora y en el futuro. Que se salvaguarden los recursos necesarios y las
capacidades asociadas.
Cumplimiento: Que se cumplan las leyes, regulaciones y acuerdos contractuales a que el
organismo está sujeto.
Confiabilidad: Que la información provista sea apropiada a la administración para operar la
entidad y para elaborar informes financieros y de cumplimiento.
43
ANEXO VI
ANÁLISIS DE LA VISTA ENVIADA AL ORGANISMO
4.1. Planificación y organización
4.1.1 Evaluación de Riesgos
Respuesta del Organismo: Contamos con un documento "SI_ADM_PlanDeComunicacion
__ Diciembre_ V2- 3.doc"), el cual incluye información relacionada con la estructura de
comunicaciones del proyecto, con sus mecanismos de control y seguimiento.
Particularmente, y a modo de ejemplo, citamos lo referente a las reuniones periódicas
denominadas de Nivel 3, 4 y 5.
• Reuniones N3
Con una frecuencia de cada 6-7 días hábiles, alternando martes y jueves, tenemos
reuniones de coordinación, en la cual participan todos los coordinadores de
equipos, PMO, y la Coordinadora General del Proyecto. El objetivo de esta
reunión es tratar temas intergrupales, poniendo en común situaciones que deban
ser evaluadas en conjunto, y hallar soluciones que impacten a varios equipos.
Reuniones N4
Con una frecuencia regular, y hasta cotidiana, la Coordinadora General del
Proyecto interactúa con el Gerente del Proyecto, y usuarios clave, para evaluar los
avances estratégicos del Proyecto, y/o cuestiones relevantes del avance de los
cronogramas vigentes.
Reuniones N5
En reuniones regulares, ahora realizándose el primer lunes de cada mes, se reúnen
el Gerente de Proyecto, y la Coordinadora General, con el Comité de Estrategia de
Procesos e Informática de la Administración Financiera, para presentar y tratar
44
los avances destacados, y decisiones estratégicas, del proyecto (el mencionado
Comité se creó mediante Resolución de SH 325, el 01/11/10).
En todas las reuniones mencionadas, se presentan los riesgos que pudieran
dificultar el cumplimiento de los hitos definidos, junto con las acciones de
mitigación que pudieran ya haberse evaluado, colaborando la audiencia de cada
reunión, con su evaluación y aportes, en la mitigación necesaria,
Algunos ejemplos:
a) el caso de los Informes de Comité (Comité de Estrategia de Procesos e
Informática de la Administración Financiera), que se presentan en las reuniones de
Nivel 5, en el cual se incluyen riesgos, tipificados acorde a los ítems señalados en
la observación de esa Auditoria (personal, instalaciones, sistemas de aplicación,
tecnología, y datos).
b) Complementario a los monitoreos realizados, el Area Técnica genera, entre
otros reportes, uno automático que detalla y grafica información referida a la
temperatura generada en los Centros de Cómputos y recintos de UPS, y detalle de
desempeño del servicio de dichas UPS.
c) El equipo administrativo del proyecto, mantiene actualizado un esquema de
planillas en las cuales registra datos de cada miembro del proyecto:
a) personales: para su pronta localización, en caso de alguna emergencia
que así lo requiera,
b)rol, perfil, y equipo: para rápidas evaluaciones de movimientos entre
equipos, cuando la planificación así lo requiera
c)equipamiento asignado: para agiliza los inconvenientes técnicos que
pudiera tener dado el uso de los equipos a su cargo (ej, acelerar la
resolución del incidente generado cuando tiene problemas de acceso a la
red, o por rotura de algún componente en su PC).
Respecto a los niveles de riesgo, se han detallado en distintos documentos que les
hemos entregado, mostrando cómo desde tiempos tempranas del proyecto,
45
identificamos, seguimos, y mitigamos, riesgos tipificados como 'del personal', 'de
adquisiciones', y 'tecnológicos'.
Ante esto, no coincidimos entonces con que solamente nuestros procesos "siguen un
patrón regular" (Nivel 2 según estándares de COBIT, 'Repetible')1; sino que
"se documentan y se comunican" (Nivel 3, ,'Definido'), y hasta "se monitorean y se
miden" (Nivel 4, , 'Administrado').
Comentario AGN: El documento presentado no fue entregado oportunamente, tiene
estado “En elaboración” y no cuenta con aprobación superior. Las reuniones que, de
acuerdo con lo informado en el descargo, se ejecutan, no impactan en la observación
realizada.
En consecuencia se mantiene la observación.
4.1.2 Administración de la Calidad
Respuesta del Organismo: Desde el inicio del proyecto SIDIF Internet hemos
implementado como política, el control de calidad de la documentación que se genera
como producto de cada una de las disciplinas del ciclo de vida del desarrollo: Captura de
Requerimientos, Usabilidad, Análisis, Diseño, Testing e Implementación. El procedimiento
de control de calidad entregado oportunamente ("SUNG_Proceso_de_Revision.doc"), así
lo define.
Este proceso de revisión está soportado por un conjunto de checklist, o listas de
comprobación, como orientación al revisor. Las observaciones de calidad que se detectan
son documentadas en registros de calidad y luego en la herramienta de administración de
requerimientos ITEM, y priorizadas según lo indica el procedimiento de priorización, en
las reuniones de N1 de cada equipo de Negocio.
Por otro lado, el proyecto ha adoptado las buenas prácticas de las metodologías ágiles
como Scrum y Kanban, de manera tal de potenciar la calidad del producto a partir de la
detección temprana de defectos e intensificar
A través de estas reuniones la calidad del producto se controla durante todo el SPRINT y,
por ser equipos multidisciplinarios, desde todas las visiones o perspectivas, incluyendo la
del usuario final del producto:
46
la comunicación entre los miembros de un equipo de negocio. Estas prácticas promueven a
través de ciclos de desarrollo iterativos breves o SPRINT, de 2 ó 3 semanas, una serie de
reuniones, de frecuencia diversa, en las cuales participan, según corresponda, los
miembros del equipo de negocio, conformado por referentes de análisis, diseño, testing y
réplicas, PMO y la coordinación del proyecto, El equipo de Ingeniería participa
acompañando a cada equipo brindando soporte metodológico y asegurando el
cumplimiento del proceso de desarrollo,
• Reuniones diarias (Daily Meetings)
Con una frecuencia diaria, estas reuniones tienen como objetivo que cada miembro reporte
al resto del equipo el avance de las tareas que se ha comprometido a realizar, Para esto,
se suelen contestar tres preguntas básicas: ¿qué hice ayer?, ¿qué haré hoy?, y ¿cuáles son
los potenciales problemas o dificultades que vislumbro?
Cabe destacar que el objetivo de esta reunión no es resolver los problemas, sino alertar a
todos los miembros de los mismos, y coordinar reuniones de trabajo posteriores para su
resolución,
Como resultado de una reunión de este tipo se actualizan la pizarra y el Sprint Backlog,
para reflejar el avance y actualizar las estimaciones realizadas al inicio del mismo. En
forma adicional se registran incidentes y riesgos que luego serán informados a los niveles
superiores,
Estas reuniones permiten inspeccionar lo que está sucediendo y realizar las adaptaciones
necesarias para poder conseguir los objetivos de la iteración,
• Reuniones N1
Para más detalle consultar el Plan de Comunicaciones que se adjunta,
• Reuniones N2
Para más detalle consultar el Plan de Comunicaciones que se adjunta.
47
Teniendo en cuenta las nuevas metodologías en estas reuniones de Nivel 2, se reporta el
avance del negocio al PMO a cargo. Para esto se deben completar y actualizar una serie
de artefactos que comprenden:
Informe de Avance
Burndown Chart del Sprint en curso.
Product Burndown Chart.
CROE ágil.
Defectos
Presentación de estado de Bugs a cargo del equipo de Testing.
Cambios de alcance o redefinición de requerimientos.
Ítems pendientes de Arquitectura.
Tareas pendientes de GOD. QA's pendientes.
Alertas N 1.
Incidentes.
Riesgos.
Novedades de Recursos
• Demos
Al finalizar cada ciclo de desarrollo o SPRINT, se realiza una demo a todo el equipo de
negocio, a partir de un guión escrito que organiza la actividad con el objetivo de mostrar
al resultado del ciclo.
La demostración de los resultados completados al final de la iteración, permite ir
acercándose a las expectativas del usuario final mediante ajustes a realizar en las
siguientes iteraciones. Estos ajustes se incorporan al product backlog y se priorizan.
• Retrospectivas
Al finalizar cada ciclo de desarrollo se realizan reuniones de retrospectivas o lecciones
aprendidas, que buscan dar respuesta a preguntas del tipo: ¿Qué hicimos bien?, ¿Qué
podemos mejorar?, ¿Qué hicimos mal?
Como conclusión de estas reuniones se escribe un documento con las mejoras propuestas,
y se publica en la WIKI. Las mejoras priorizadas se aplican en los sucesivos SPRINT.
48
Por lo expuesto, podemos asegurar que nuestro proceso es realmente un proceso de
mejora continua con foco en la calidad a lo largo de todo el ciclo de desarrollo, y
consideramos que corresponde se modifique al nivel de madurez, en el cual "los procesos
se documentan y se comunican", correspondiendo al nivel "definido".
Comentario AGN: El documento mencionado no está debidamente actualizado. La
operación de SIDIF Internet no dispone de procedimientos formales para monitorear los
controles internos, evaluar su eficacia y realizar informes periódicos.
En consecuencia se mantiene la observación.
4.2. Administración e implementación
4.2.1. Adquisición y Mantenimiento del Software de Aplicación
Respuesta del Organismo: Ninguna.
Comentario AGN: El Organismo acepta la indicación.
En consecuencia se mantiene la observación.
4.2.2. Desarrollo y mantenimiento de procedimientos
Respuesta del Organismo: Ninguna.
Comentario AGN: El Organismo acepta la indicación.
En consecuencia se mantiene la observación.
4.3. Entrega y Soporte
4.3.1. Definición y administración de los Niveles de Servicio
Respuesta del Organismo: Ninguna.
Comentario AGN: El Organismo acepta la indicación.
En consecuencia se mantiene la observación.
4.3.2. Administración de servicios prestados por terceros
Respuesta del Organismo: 1.3.1. Adquisiciones y contrataciones.
En la etapa inicial del proyecto desde 2004 hasta 2006, cuando contaba con
financiamiento a través del FOSIP, las adquisiciones y los concursos para la contratación
de empresas los controlaba el Banco Mundial aplicando las normas del Banco, para
otorgar la "no objeción".
49
Posteriormente los procesos de contratación se han efectuado cumpliendo con todo el
marco regulatorio local con la intervención de las áreas con competencia en el tema:
Dirección de Compras y contrataciones, Dirección General de Asuntos Jurídicos, Oficina
Nacional de Tecnología Informática.
Cabe aclarar que al momento de realizarse los concursos para contratar proveedores en
los Términos de Referencia que se confeccionaron en cada oportunidad se ha exigido la
presentación de certificaciones SW-CMM v.1.1, CMMI-SE/SW v.1.0 o superior, o
equivalente; que forman parte de la fórmula de evaluación para asignar la puntuación
correspondiente. En la misma fórmula se evalúa asimismo las certificaciones de
satisfacción de clientes del oferente en los últimos 5 años anteriores a su presentación en
el concurso.
1.3.2. Control de ejecución.
El personal que reviste bajo el convenio con UTN cuenta con los conocimientos suficientes
para supervisar las actividades de arquitectura, y diseño y desarrollo, que realizan los
recursos que aportan al proyecto la UNLP empresa contratada.
Es una práctica habitual en el ámbito de la Administración Pública Nacional, y una buena
práctica de gerenciamiento, cuando no se dispone de personal interno suficiente frente a
proyectos de envergadura y largo alcance, contar con personal contratado que ejerza ese
control.
El control se ejecuta a través de control de calidad a lo largo de todo el ciclo de desarrollo
y el avance de acuerdo a las planificaciones detalladas en las reuniones semanales de
Nivel 2 (ver Plan de Comunicaciones adjunto), en las cuales se presentan los documentos
de avance que incluimos en el anexo y la justificación de los desvíos que se hayan
producido en la semana que se reporta con su correspondiente mitigación.
El grupo que realiza el testing de la aplicación también está incluido en el convenio UTN.
Este grupo efectúa el control de calidad del producto construido.
Ponemos a su disposición las guías metodológicas para ejercer los controles mencionados,
ya entregadas oportunamente.
Asimismo en las reuniones del Comité de Estrategia de Procesos e Informática de la
Administración Financiera, que se realizan el primer lunes de cada mes, la Coordinadora
50
general del proyecto presenta el avance, los temas destacados y riesgos, a consideración
de dicho Comité.
En la etapa de despliegue el usuario participa activamente, con el soporte del equipo de
Réplicas, llevando a cabo las pruebas de aceptación del producto. Esta etapa tiene
documentos estándar, que la formalizan: Documento de Alcance, Documentos de Riesgos y
Documento de Salida Controlada.
Respecto a los niveles de riesgo, hemos explicitado las actividades que se desarrollan, y
acompañamos los documentos de control que se utilizan en el proyecto de manera que esa
Auditoria pueda con estos nuevos elementos pueda atender nuestra apreciación de que el
nivel 2 "Repetible" es inferior al que corresponde pues nuestros procesos no solo "siguen
un patrón regular' (Nivel 2 según estándares de COBIT, 'Repetible'); sino que también "se
documentan y se comunican" (Nivel 3, ... , 'Definido'), y hasta "se monitorean y se miden"
(Nivel 4, ... , 'Administrado').
Comentario AGN: La intervención de la ONTI y otros entes en las contrataciones no es
condición suficiente para reemplazar el establecimiento formal de las políticas y los
procedimientos detallados para las contrataciones informáticas de un organismo.
En consecuencia se mantiene la observación.
4.3.3. Garantía de la seguridad de los sistemas
Respuesta del Organismo: Ninguna.
Comentario AGN: El Organismo acepta la indicación.
En consecuencia se mantiene la observación.
4.3.4. Administración de datos
Respuesta del Organismo: Ninguna.
Comentario AGN: El Organismo acepta la indicación.
En consecuencia se mantiene la observación.
4.4. Monitoreo
4.4.1. Monitoreo de los procesos
Respuesta del Organismo: El personal que reviste bajo el convenio con UTN cuenta con
los conocimientos suficientes para supervisar las actividades de arquitectura, y diseño y
51
desarrollo, que realizan los recursos que aportan al proyecto la UNLP empresa
contratada.
Es una práctica habitual en el ámbito de la Administración Pública Nacional, y una buena
práctica de gerenciamiento, cuando no se dispone de personal interno suficiente frente a
proyectos de envergadura y largo alcance, contar con personal contratado que ejerza ese
control.
El control se ejecuta a través de control de calidad a lo largo de todo el ciclo de desarrollo
y el avance de acuerdo a las planificaciones detalladas en las reuniones semanales de
Nivel 2 (ver Plan de Comunicaciones adjunto), en las cuales se presentan los documentos
de avance que incluimos en el anexo y la justificación de los desvíos que se hayan
producido en la semana que se reporta con su correspondiente mitigación.
El grupo que realiza el testing de la aplicación también está incluido en el convenio UTN.
Este grupo efectúa el control de calidad del producto construido.
Ponemos a su disposición las guías metodológicas para ejercer los controles mencionados,
ya entregadas oportunamente.
Asimismo en las reuniones del Comité de Estrategia de Procesos e Informática de la
Administración Financiera, que se realizan el primer lunes de cada mes, la Coordinadora
general del proyecto presenta el avance, los temas destacados y riesgos, a consideración
de dicho Comité.
En la etapa de despliegue el usuario participa activamente, con el soporte del equipo de
Réplicas, llevando a cabo las pruebas de aceptación del producto. Esta etapa tiene
documentos estándar, que la formalizan: Documento de Alcance, Documentos de Riesgos y
Documento de Salida Controlada.
Respecto a los niveles de riesgo, hemos explicitado las actividades que se desarrollan, y
acompañamos los documentos de control que se utilizan en el proyecto de manera que esa
Auditoria pueda con estos nuevos elementos pueda atender nuestra apreciación de que el
nivel 2 "Repetible" es inferior al que corresponde pues nuestros procesos no solo "siguen
un patrón regular' (Nivel 2 según estándares de COBIT, 'Repetible')2; sino que también "se
2 Así evaluado en el presente informe.
52
documentan y se comunican" (Nivel 3, ... , 'Definido'), y hasta "se monitorean y se miden"
(Nivel 4, ... , 'Administrado').
Comentario AGN: El documento “Plan de Comunicaciones” citado y entregado con la
respuesta a la vista indica en su cuerpo tratarse de un documento en estado de elaboración.
En tal sentido, por no estar oficialmente aprobado, corresponde el nivel de madurez
“Repetible” señalado en el informe.
Por otra parte la normativa de monitoreo debe mejorarse a través de la inclusión de un
conjunto balanceado de objetivos de desempeño debidamente aprobados. Se deberá además
definir referencias con las que comparar los objetivos e identificar datos disponibles a
recolectar para identificar e iniciar medidas correctivas basadas en el monitoreo del
desempeño.
En consecuencia se mantiene la observación.
4.4.2. Evaluación de la idoneidad del control interno
Respuesta del Organismo: Ninguna.
Comentario AGN: El Organismo acepta la indicación.
En consecuencia se mantiene la observación.
4.4.3 Obtención de garantía independiente
Respuesta del Organismo: Respecto de las observaciones sobre la ausencia de
formalización de los procedimientos para manejar las actividades de auditoria
independiente del área de TI, es oportuno señalar que la Auditoria Interna independiente
para el Poder Ejecutivo Nacional, se encuentra contemplada en las disposiciones de la Ley
24.156 Titulo VII 'Del sistema de Control Interno'.
En uso de las facultades establecidas por la citada Ley, la SIGEN emitió la Resolución
48/053 en materia de Normas de Control Interno para Tecnología de la Información para
el Sector Público Nacional, donde no se le asigna a la SSP responsabilidad primaria para
3 Resolución Nro. 48/05 Anexo I punto 13. Auditoría Interna de Sistemas: Las unidades de auditoría interna definidas en
la Ley 24.156 deben contemplar la ejecución de auditorías de sistemas, debiendo reunir los responsables de llevarlas a
cabo, los requisitos de competencias técnicas, independencia y autoridad para efectuar revisiones objetivas de los
controles informáticos y preparar informes sobre sus hallazgos y recomendación.
53
llevar a cabo las acciones observadas en los puntos 4.4.3 y 4.4.4, y recomendadas en los
puntos 6.4.3. y 6.4.4.
Por otra parte el citado plexo legal, prevé que la Auditoría Externa independiente del
Sector público Nacional estará a cargo de ese Órgano de Control, no contemplando la
necesidad de contar con la opinión de otros controles externos.
No obstante ha sido materia de interés permanente de las autoridades, y en tal sentido se
lo expresaron a las autoridades de la AGN, en reuniones preparatorias de la auditoria que
nos ocupa, contar con opiniones alternativas de expertos durante la gestación y el
desarrollo del mismo.
Mencionamos en tal sentido, las auditorias realizadas oportunamente por expertos del
Banco Mundial, tal las realizadas por Silvio Solarte Leyton, el 17/02/04 y 20/11/04.
Finalmente, es dable destacar que la SSP ha velado por las condiciones que permiten un
buen funcionamiento de la DAS de la CGN, ha contratado personal idóneo, y ha brindado
capacitaciones sobre las herramientas informáticas utilizadas. Se está gestionando
asimismo la compra de herramientas que darán un mejor soporte a la gestión de dicha
Dirección.
Entendemos que es de conocimiento de esa Auditoria que a través del Comité de Estrategia
de Procesos e Informática de la Administración Financiera, creado por resolución del SH,
la SSP ha provisto espacios de coordinación y control de los planes vigentes.
Entendemos por lo expuesto que no son aplicables a esta SSP los considerandos de los
puntos 4.4.3 y 4.4.4, Y por ende la asignación de un nivel de madurez respecto a los
mismos.
Comentario AGN: Es de buena práctica que el Ministro/Secretario y el funcionario
principal de servicios de información asuman la responsabilidad de garantizar:
la acreditación independiente de la seguridad y el control interno de los servicios de
TI
la certificación independiente de la seguridad y el control interno de los terceros
proveedores de servicios de TI
la evaluación independiente de la eficacia de los servicios de TI
54
la evaluación independiente de la eficacia de los terceros proveedores de servicios
de TI
la garantía independiente del cumplimiento de los requerimientos legales y
regulatorios y los compromisos contractuales
la garantía independiente del cumplimiento de los requerimientos legales y
regulatorios y los compromisos contractuales por partes terceros proveedores de
servicios de TI
la competencia de la función de auditoría interna
la participación proactiva en la auditoría.
En consecuencia se mantiene la observación.
4.4.4 Provisión de auditoría independiente
Respuesta del Organismo: Ídem ítem anterior.
Comentario AGN: Entre las mejores prácticas se incluye que la máxima autoridad del ente
y el funcionario principal de auditoría interna sean responsables de garantizar:
la definición del alcance de las responsabilidades de auditoría informática para la
función de Auditoría Interna.
la independencia de los auditores internos
el cumplimiento del código de ética y normas profesionales
la competencia del plantel de auditoría informática
la planificación de los proyectos de auditoría
la ejecución del trabajo de auditoría
la elaboración de informes
las actividades de seguimiento de recomendaciones.
En consecuencia se mantiene la observación.
7. Conclusiones
Respuesta del Organismo: 2. Punto "7 Conclusiones".
En este punto esa Auditoría pone el foco en 2 temas:
a) Riesgo de la información
55
b) Mantenimiento del sistema SLU
A continuación nos referiremos a cada uno de ellos:
a) Riesgo de la Información
La Secretaría de Hacienda se encuentra en una etapa de madurez importante en el
desarrollo de sus sistemas de administración financiera. La mayoría de los países
latinoamericanos poseen un sistema de administración financiera cuyo alcance se limita a
registrar los momentos del gasto: compromiso, devengado y pagado. El SLU, en cambio,
es un sistema de gestión administrativa que apoya el trabajo diario de los usuarios y sobre
la base de los comprobantes de gestión realiza el registro presupuestario, financiero y
contable. El e-SIDIF mejora las prestaciones del SLU acercándose aún más a la gestión
del usuario para hacer más eficiente su trabajo.
Un sistema cuyo alcance se limita al registro requiere de 2 o 3 años de desarrollo. En
cambio, un sistema cuyo alcance incorpora todo el soporte a la gestión requiere tiempos
mayores para su puesta en producción con la calidad esperada. En razón de lo expuesto y
considerando la necesidad de respuesta a requerimientos de los usuarios, que la evolución
de la propia gestión va generando, es que se toma la decisión de desplegar en producción
los módulos a medida que se concluye su desarrollo. Esta estrategia colabora también con
la reducción de los costos de mantenimiento, pues se desafectan tempranamente los
módulos que se reemplazan por el e-SIDIF de manera progresiva.
Como bien expresan las conclusiones expuestas en punto 7 del informe de esa Auditoria, se
han desarrollado procedimientos acompañados de sus correspondientes auditorías que
aseguran la actualización de los acumuladores presupuestarios en las distintas bases y dan
como resultado la ausencia de errores en los datos, que esa misma Auditoria pudo
verificar tal como expresa en el punto 7. Cabe aclarar que a la fecha los controles
manuales se realizan únicamente cuando los procedimientos automáticos generan algún
alerta que obliga a analizar datos específicos.
El e-SIDIF se sustenta en una Base de Datos única que no requerirá, una vez concluido su
desarrollo completo, redundancia de datos para la información de gestión y registro de
administración financiera de los organismos que utilicen el sistema.
56
Sin embargo respecto a la redundancia de datos, que esa Auditoria considera una
situación anómala, nos permitimos complementar nuestra respuesta haciendo referencia a
las nuevas tendencias de desarrollo como lo es la arquitectura SOA. Cuando se presentan
casos en que es necesario integrar sistemas con modelos de datos diferentes, o en casos en
que la tasa de datos a transferir es alta, la redundancia controlada de datos (ver Anexo 1),
es una alternativa de solución válida para mejorar la performance de las operaciones y
tener un repositorio central que contenga todos los datos de la organización. En estos
casos se adopta la redundancia como solución definitiva y no transitoria.
Las empresas que actualmente concentran sus datos corporativos a través de un
middleware adoptan esta solución.
A modo ejemplo de lo antedicho, en el caso de la vinculación del e-SIDIF con el sistema e-
COM que desarrolla la Oficina Nacional de Contrataciones se ha definido la redundancia
en los puntos de contacto principal como son la Solicitud de Compras y la Orden de
Compra, ambos comprobantes imprescindibles para el control presupuestario y la
continuidad de la gestión en el e-SIDIF. Esta será la solución definitiva dado que la Orden
de Compra es el punto de partida para el control de la factura del proveedor, y por lo
tanto mandatoria, para dar continuidad segura a la gestión de pagos que es crítica.
En virtud de lo señalado, no es posible aceptar la recomendación de esa AGN en el sentido
de que el riesgo es superior a lo aconsejable, puesto que se entiende que es razonable dada
las características del proyecto bajo análisis.
b) Mantenimiento del sistema SLU
En relación al mantenimiento del sistema SLU, acercamos en esta respuesta en el Anexo 2
un cuadro que refleja la dedicación al mantenimiento del SLU llevado a cabo en el año
correspondiente a vuestra auditoría.
De su análisis se puede inferir claramente que la afirmación de que no se realizan
modificaciones ni mantenimiento no es aplicable.
Respecto a la falta de ayuda en línea, como bien afirma esa Auditoría, se ha incorporado
al sistema e-SIDIF donde la usabilidad ha sido cuidadosamente considerada.
Comentario AGN:
El Organismo justifica la existencia de los problemas destacados en las conclusiones en:
57
La complejidad de la solución elegida, comparándose con la mayoría de los
países latinoamericanos, y
La existencia de soluciones informáticas que poseen redundancia de datos
controlados.
Al respecto cabe consignar lo siguiente:
Independientemente de la sofisticación del software e-SIDIF, la etapa actual de desarrollo
donde coexisten los productos anteriores como el SLU, SIDIF central y SIDIF carácter,
genera una situación que pone en riesgo la calidad de los datos. La redundancia a que hace
referencia el informe no es producto de ningún desarrollo controlado que la justifique sino
de la superposición de las versiones mencionadas arriba, y los procesos de mitigación de
riesgos que se utilizan no garantizan la inexistencia de errores.
Con respecto al SLU, cabe destacar que el mantenimiento que se realiza es de tipo reactivo,
de manera tal de permitir que los organismos puedan continuar utilizándolo hasta tanto sea
reemplazado por el e-SIDIF.
En el informe se destacan algunos inconvenientes en la interpretación de las pantallas y la
falta de ayudas en línea, temas sobre los cuales no existe intención de corregir.
En consecuencia se mantienen las conclusiones.
58
ANEXO VII
Respuesta del Organismo a la vista.
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79