INFORME DE AUDITORÍA Al Dr. Ricardo Daniel Echegaray Administrador Federal de Ingresos Públicos En uso de las facultades conferidas por el artículo 118 de la Ley 24.156, la AUDITORÍA GENERAL DE LA NACIÓN procedió a efectuar un examen en el ámbito del Ministerio de Economía y Finanzas, con el objeto que se detalla en el apartado 1. 1. Objeto de la auditoría Evaluación de la Tecnología Informática de la Dirección General Impositiva en la Administración Federal de Ingresos Públicos, organismo autárquico en la órbita del Ministerio de Economía, con el objeto de determinar debilidades y fortalezas de la gestión informática. Período auditado: año 2011. 2. Alcance del examen 2.1. El equipo de auditoría en la etapa de planificación identificó los temas de mayor exposición al riesgo y comprendió los siguientes ítems: Relevamiento de la documentación normativa del área de tecnología informática del Organismo. Relevamiento de la infraestructura informática del Organismo. Relevamiento de los sistemas existentes en producción y desarrollo. Verificación de la existencia de la documentación recomendada por la Secretaría de la Gestión Pública (SGP) y los estándares internacionales. Verificación de la adecuación de los sistemas, de la infraestructura existentes y de la planificación a la misión y metas del Organismo y a las leyes y decretos que regulan su actividad. Verificación del modelo de arquitectura de la información y su seguridad. Relevamiento y Análisis del organigrama del área de tecnología informática y su 1 funcionamiento. Relevamiento y Análisis del presupuesto operativo anual del área. Verificación del cumplimiento de la comunicación de los objetivos y las directivas de la Gerencia. Análisis de la administración de recursos humanos, la evaluación de riesgos, la administración de proyectos, la administración de calidad y las prácticas de instalación y acreditación de sistemas y de administración de cambios. Análisis de: la definición de los niveles de servicio, la administración de los servicios prestados por terceros, la administración de la capacidad y el desempeño, los mecanismos que garantizan el servicio continuo y la seguridad de los sistemas, la imputación de costos, la educación y capacitación de los usuarios, la asistencia a los clientes de la Tecnología de la Información, la administración de la configuración de hardware y software, la administración de problemas e incidentes, la administración de datos, de instalaciones y de operaciones. Análisis del monitoreo de los procesos, la idoneidad del control interno y la existencia de auditoría interna. 2.2. La tarea abarcó la auditoría del estado de utilización de la Tecnología Informática en la Sede Central de la Administración Federal de Ingresos Públicos, en base a la información obtenida de las siguientes fuentes: Entrevistas realizadas con las principales autoridades de la Administración. Cuestionario para la determinación de las necesidades de análisis detallado. Cuestionarios para el análisis detallado de los temas que lo requerían. Manuales de Documentación de los Sistemas. Inspecciones directas efectuadas en el área de Sistemas de AFIP. 2.3. Limitaciones: No formó parte de la presente auditoría la evaluación del uso de la Tecnología Informática en las delegaciones del interior del país, ni en otras dependencias 2 que no fuesen las instalaciones centrales. Las tareas de campo abarcaron desde mayo 2012 hasta diciembre 2012. 2.4. Metodología: La auditoría incluyó dos etapas: la primera de planificación del análisis detallado y la segunda de verificación del cumplimiento de lo informado en la primera etapa. La etapa de planificación incluyó las siguientes actividades: Análisis del marco legal e institucional del funcionamiento de la Administración. Análisis de los informes de Auditoría Interna en temas informáticos. Entrevistas con los responsables de la Auditoría Interna y de cada una de las Direcciones de la Administración Federal, en cuanto a la participación y experiencia propia y de su personal en el uso de la Tecnología de la Información. Entrevistas con el responsable del Área Informática de la Administración Federal de Ingresos Públicos. En la etapa de análisis detallado se ejecutó: Análisis de las respuestas a los cuestionarios para determinación de las necesidades de análisis detallado. Determinación de las necesidades de verificación de las respuestas obtenidas. Verificación mediante inspecciones in situ y entrevistas con personal subalterno, realizada por especialistas en diversas ramas de la informática, a través del trabajo directo en el campo. En función de la información relevada y los niveles de riesgo estimados se definieron los trabajos de campo convenientes para realizar las verificaciones necesarias. Este informe es producto de la evaluación de la información recabada en las entrevistas mantenidas y de las observaciones realizadas en el trabajo de campo. Por otra parte se realizó un análisis de los riesgos asociados a los Objetivos de Control definidos para cada uno de los procedimientos relevados. Se han encontrado observaciones que se detallan por separado. 3 3. Aclaraciones previas Por Dto. 1156/96, conforme art. 1º, se fusionó la Administración Nacional de Aduanas y la Dirección General Impositiva, constituyendo la Administración Federal de Ingresos Públicos, entendiendo que la citada Administración funcionará como ente autárquico en el ámbito del entonces Ministerio de Economía y Obras y Servicios Públicos, asumiendo las competencias, facultades, derechos y obligaciones de las entidades que se fusionan por ese acto. La DGRSS (Dirección General de los Recursos de la Seguridad Social) integra también la Administración Federal de Ingresos Públicos, encargándose de la recaudación y fiscalización de los fondos que financian las prestaciones de la Seguridad Social en la República Argentina. La Dirección General Impositiva (DGI) tiene a su cargo la aplicación, percepción, recaudación y fiscalización de tributos interiores. 4. Comentarios y observaciones Basamos nuestra tarea en la verificación de los Objetivos de Control establecidos por las normas COBIT (Control OBjectives in Information Technologies) versión 4. Los Objetivos de Control describen los resultados que debe alcanzar un organismo implantando procedimientos de control, basados en las mejores prácticas aplicables, a los procesos de TI. Para cada uno de los Objetivos se menciona el nivel de madurez que le corresponde, conforme al Modelo de Madurez de la Capacidad incluido en el Anexo I. 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 III) 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 4 realizadas) para establecer el riesgo específico para ese objetivo, en el caso particular. Puede observarse en los gráficos de los Anexos II y IV 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. Planificar y organizar 4.1.1 Definir un plan estratégico para TI Objetivo de control: Se requiere una planeación estratégica de Tecnología de la Información (TI) para administrar y dirigir todos los recursos de TI de acuerdo con los objetivos estratégicos del Organismo y las prioridades. La función de TI y los participantes del negocio son responsables de garantizar que se materialice el valor óptimo de los proyectos y servicios. El plan estratégico debe mejorar el entendimiento de los interesados clave respecto a las oportunidades y limitaciones de TI, evaluar el desempeño actual y aclarar el nivel de inversión requerido. La estrategia de negocio y las prioridades se deben reflejar en los proyectos de inversión y deben ser ejecutadas por los planes tácticos de TI, los cuales establecen objetivos, planes y tareas específicas, entendidas y aceptadas tanto por el negocio como por TI. Este objetivo de control afecta, primariamente: la efectividad y en forma secundaria: la eficiencia Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Repetible. La planeación estratégica de TI se comparte con la gerencia correspondiente según se necesite. La actualización de los planes de TI ocurre como respuesta a las solicitudes de la dirección. Las decisiones estratégicas se toman proyecto por proyecto, sin ser consistentes con una estrategia global del Organismo. Los riesgos y beneficios al usuario, resultado de decisiones estratégicas importantes, se reconocen de forma intuitiva. 5 Observaciones: La normativa vigente (Anexo VI – Nota 1) exige la existencia de un Plan de Gestión Anual que deberá cumplir el Administrador Federal de Ingresos Públicos. Indicando además cómo y cuándo se controlará su cumplimiento y las penalidades para el caso en que ello no ocurra. Para el período analizado por esta auditoría, no existía un Plan Estratégico de TI formalizado, alineado con el Plan Estratégico del Organismo aunque existen iniciativas, relacionadas con la infraestructura, incluidas en este último. Al cierre de los trabajos de campo está en etapa de revisión y aprobación final el Plan Estratégico de TI del presente año. 4.1.2 Definir la arquitectura de información Objetivo de control: La función de los sistemas de información debe crear y actualizar de forma regular un modelo de información y definir los sistemas apropiados para optimizar el uso de esta información. Esto incluye el desarrollo de un diccionario corporativo de datos que contiene las reglas de sintaxis de los datos del Organismo, el esquema de clasificación de datos y los niveles de seguridad. Este proceso mejora la calidad de la toma de decisiones gerenciales asegurándose que se proporciona información confiable y segura, y permite racionalizar los recursos de los sistemas de información para igualarse con las estrategias del Organismo. Este proceso de TI también es necesario para incrementar la responsabilidad sobre la integridad y seguridad de los datos y para mejorar la efectividad y control de la información compartida a lo largo de las aplicaciones y de las entidades. Este objetivo de control afecta, primariamente: la eficiencia la integridad y en forma secundaria: la efectividad la confidencialidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Repetible. Existe un proceso de arquitectura de información y procedimientos similares, aunque intuitivos e informales, que se siguen por distintos 6 individuos dentro de la organización. Las personas obtienen sus habilidades al construir la arquitectura de información por medio de experiencia práctica y la aplicación repetida de técnicas. Los requerimientos tácticos impulsan el desarrollo de los componentes de la arquitectura de la información por parte de los individuos. Observaciones: No existe un diccionario de datos de la organización ni un procedimiento formalizado que obligue a la progresiva constitución del mismo. Tampoco existe un modelo de datos del Organismo. Queda a criterio de cada sector del Organismo la administración de la información, por lo cual se es proclive a generar redundancia de datos. No existe un esquema de clasificación de datos basado en la criticidad y sensibilidad la información. Se está trabajando en la homogeneización de los múltiples entornos de trabajo, producto de la fusión de los distintos organismos originales en la actual AFIP. Existen algunas iniciativas como el Padrón Único de Contribuyentes (PUC), el Sistema Único de Parámetros de AFIP (SUPA), el Repositorio Único de Declaraciones Juradas (RUCD) o Repositorio de Documentos Internos (RUCDI) que tienen un uso común para todas las aplicaciones del Organismo. 4.1.3 Determinar la dirección tecnológica Objetivo de control: La función de servicios de información debe determinar la dirección tecnológica para dar soporte a los objetivos de la organización. Esto requiere de la creación de un plan de infraestructura tecnológica y de un consejo de arquitectura que establezca y administre expectativas realistas y claras de lo que la tecnología puede ofrecer en términos de productos, servicios y mecanismos de aplicación. El plan se debe actualizar de forma regular y debe abarcar aspectos tales como arquitectura de sistemas, dirección tecnológica, planes de adquisición, estándares, estrategias de migración y contingencias. Esto permite mejorar los tiempos de reacción manteniendo entornos competitivos, mejorar la economía de escala en los sistemas de información utilizados por el personal o para la toma de decisiones, como también en interoperabilidad entre las plataformas y las aplicaciones. Este objetivo de control afecta, primariamente: la efectividad 7 la eficiencia Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Definido. La gerencia está consciente de la importancia del plan de infraestructura tecnológica. El proceso para su planificación es sólido. Existe un plan de definido, documentado y bien difundido, aunque se aplica de forma inconsistente. La orientación de la infraestructura tecnológica incluye el entendimiento con la alineación de la estrategia del Organismo. Los proveedores clave se seleccionan en base a su entendimiento de la tecnología a largo plazo y de los planes de desarrollo de productos, de forma consistente con la dirección tecnológica del Organismo. Observaciones: La Dirección de Infraestructura Tecnológica actualiza anualmente el Plan de Infraestructura y ha desarrollado un sistema que permite el seguimiento de proyectos, facilita la ejecución de los procesos y la realización de controles con el propósito de optimizar la gestión del área. Sin embargo, la ausencia de planes estratégicos a nivel de la Subdirección General de Sistemas y Telecomunicaciones, para el período auditado, no permite establecer la dirección tecnológica. Se siguen procesos intuitivos y reactivos basados en un trabajo sobre tendencias del mercado y posibles necesidades futuras, tanto para establecer el mantenimiento de la infraestructura como su crecimiento. Las áreas de desarrollo de sistemas están poco involucradas en la definición de la dirección tecnológica. 4.1.4 Definir los procesos, organización y relaciones de TI Objetivo de control: Una organización de TI se debe definir tomando en cuenta los requerimientos de personal, funciones, delegación, autoridad, roles, responsabilidades y supervisión. La organización estará inserta en un marco de trabajo de procesos de TI que asegura la transparencia y el control, así como el involucramiento de los altos ejecutivos de nivel decisorio. Un comité estratégico debe garantizar la vigilancia del consejo directivo sobre TI, y uno o más comités administrativos, en los cuales participan tanto los sectores operativos como TI, deben determinar las prioridades de los recursos de TI alineados con las necesidades del Organismo. Deben existir procesos, políticas administrativas y procedimientos para todas las funciones, con atención específica en el control, el 8 aseguramiento de la calidad, la administración de riesgos, la seguridad de la información, la propiedad de datos y de sistemas y la segregación de tareas. Para garantizar el soporte oportuno de los requerimientos, TI se debe involucrar en los procesos importantes de decisión. Este objetivo de control afecta, primariamente: la efectividad la eficiencia Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Definido. Existen roles y responsabilidades definidos para la organización de TI y para terceros. La organización de TI se desarrolla, documenta, comunica y se alinea con la estrategia de TI. Se define el ambiente de control interno. Se formulan las relaciones con terceros, incluyendo los comités de dirección, auditoría interna y administración de proveedores. La organización de TI está funcionalmente completa. Existen definiciones de las funciones a ser realizadas por parte del personal de TI y las que deben realizar los usuarios. Los requerimientos esenciales de personal de TI y experiencia están definidos y satisfechos. Existe una definición formal de las relaciones con los usuarios y con terceros. La división de roles y responsabilidades está definida e implantada. Observaciones: Existe normativa que aprueba la estructura, define responsabilidades y roles para cada perfil hasta el nivel de división. (Anexo VI – Nota 2) Falta segregación de funciones a los niveles inferiores, lo que provoca que las definiciones para el personal subalterno sean difusas y poco precisas. Se depende de individuos clave para responsabilidades específicas. Existe una matriz de perfiles de puestos, agrupados por cada especialización, con las competencias técnicas requeridas para cubrirlo. Algunas áreas como las relativas a la administración de riesgos y aseguramiento de la calidad no se encuentran contempladas en el organigrama. La política utilizada para la incorporación de personal provoca que en algunas áreas exista dependencia crítica de individuos clave por falta de agentes especializados. Esto también 9 limita el intercambio de conocimientos, el planeamiento de la sucesión y la posibilidad de respaldarse o reemplazarse mutuamente. A esto se agrega que existe personal contratado realizando tareas relevantes. La ubicación del Departamento de Seguridad Informática dependiendo de la Dirección de Infraestructura no es la ideal, ya que debería encontrarse en un nivel superior. 4.1.5 Administrar la inversión en TI Objetivo de control: Establecer y mantener un marco de trabajo para administrar los programas de inversión en TI que abarquen costos, beneficios y prioridades dentro del presupuesto. Trabajar con los interesados para identificar y controlar los costos y beneficios totales dentro del contexto de los planes estratégicos y tácticos de TI, y tomar medidas correctivas según sean necesarias. El proceso fomenta la sociedad entre TI y los interesados, facilita el uso efectivo y eficiente de recursos de TI, y brinda transparencia y responsabilidad dentro del costo total de la propiedad, la materialización de los beneficios y el retorno sobre las inversiones en TI. Este objetivo de control afecta, primariamente: la efectividad la eficiencia y en forma secundaria: la confiabilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Repetible. Existe un entendimiento implícito de la necesidad de seleccionar y presupuestar las inversiones en TI. La necesidad de un proceso de selección y presupuesto se da a conocer a los interesados. El cumplimiento depende de la iniciativa de individuos dentro de la organización. Surgen técnicas comunes para desarrollar componentes del presupuesto de TI. Se toman decisiones presupuestales reactivas y tácticas. Observaciones: Existe normativa (Anexo VI – Nota 3) que establece el marco general del sistema presupuestario. Un área coordinadora elabora, con participación de las Áreas 10 Responsables, un anteproyecto de Plan de Gestión que contendrá las principales líneas de acción y actividades previstas para el año siguiente sobre la base de los lineamientos del Plan Estratégico de AFIP. Además, la SDG SIT quedó comprendida por el Régimen Económico Financiero vigente para las Direcciones Regionales Impositivas y Aduaneras, quedando en manos de la Subdirección General de Administración Financiera la determinación de qué contrataciones se efectuarán en forma centralizada. (Anexo VI – Nota 4) No se ha establecido formalmente un marco de Administración Financiera de TI para elaborar y administrar un presupuesto que refleje las prioridades establecidas en los programas de inversión, la administración de costos y los beneficios esperados que permita medir la contribución de TI a los objetivos estratégicos del Organismo. Existen iniciativas aisladas en algunas direcciones pero no se ha formalizado un procedimiento de trabajo común a toda la SDG SIT. Las áreas de Desarrollo no contemplan en la metodología de ciclo de vida de desarrollo de sistemas, un marco de administración presupuestaria que comprenda cálculos de costos y beneficios esperados de los desarrollos, imputaciones por centro de costos y análisis comparativo entre lo presupuestado y lo efectivamente gastado. 4.1.6 Comunicar las aspiraciones y la dirección de la gerencia Objetivo de control: La dirección debe elaborar un marco de trabajo de control organizacional para TI, y definir y comunicar las políticas. Un programa de comunicación continua se debe implantar para articular la misión, los objetivos de servicio, las políticas y procedimientos aprobados y apoyados por la dirección. La comunicación apoya el logro de los objetivos de TI y asegura la concientización y el entendimiento de los riesgos. El proceso debe garantizar el cumplimiento de las leyes y reglamentos relevantes. Este objetivo de control afecta, primariamente: la efectividad y en forma secundaria: el cumplimiento Nivel de riesgo: [ ] Alto [X] Medio [ ] Bajo 11 Nivel de Madurez: Repetible. La gerencia tiene un entendimiento implícito de las necesidades y de los requerimientos de un ambiente de control de información efectivo, aunque las prácticas son, en su mayoría, informales. La gerencia ha comunicado la necesidad de políticas, procedimientos y estándares de control, pero la elaboración se delega a la discreción de gerentes y áreas individuales. La calidad se reconoce como una filosofía deseable a seguir, pero las prácticas se dejan a discreción de los gerentes. El entrenamiento se realiza de forma individual, según se lo requiera. Observaciones: La Administración Federal de Ingresos Públicos, como entidad autárquica, se encuentra facultada para reglamentar su funcionamiento interno, dictar nomas reglamentarias e interpretativas de alcance general respecto de terceros y la de fijar las políticas y criterios generales de conducción. Existe normativa vigente (Anexo VI – Nota 5) por la cual se regulan los actos de carácter individual y general, normativos o de ejecución, en el ámbito del Organismo, así como también la competencia de los distintos funcionarios, ya sea originaria o delegada en que se fundamenten los actos administrativos. En el caso de la implantación y comunicación de políticas de TI, se implementan y/o regulan a través de Disposiciones y/o Instrucciones Generales (Anexo VI – Nota 6). Las mismas se encuentran disponibles para el personal del Organismo en su intranet. Sin embargo, la ausencia de un Plan Estratégico de TI, hace difícil transmitir las políticas de TI generales para la organización, salvo algunas iniciativas aisladas. 4.1.7 Administrar los recursos humanos de TI Objetivo de control: Adquirir, mantener y motivar una fuerza de trabajo para la creación y entrega de servicios de TI para el negocio. Esto se logra siguiendo prácticas definidas y aprobadas que apoyan el reclutamiento, entrenamiento, la evaluación del desempeño, la promoción y la terminación. Este proceso es crítico, ya que las personas son activos importantes, y el ambiente de gobierno y de control interno depende fuertemente de la motivación y competencia del personal. Este objetivo de control afecta, primariamente: la efectividad 12 la eficiencia Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Parcialmente definido. Existe un proceso definido y documentado para administrar los recursos humanos de TI. Existe un plan informal de administración de recursos humanos. Existe un enfoque estratégico para la contratación y la administración del personal de TI. El plan de entrenamiento formal está diseñado para satisfacer las necesidades de los recursos humanos de TI. Está establecido un programa de rotación, diseñado para expandir las habilidades gerenciales. Observaciones: Existe normativa que regula la política de ingreso de personal, así como la estructura organizativa de la Administración Federal de Ingresos Públicos hasta el nivel de Subdirección General, inclusive. (Anexo VI – Nota 7) También está definido el organigrama de la Subdirección con un detalle de los roles y responsabilidades para cada perfil hasta nivel de división. (Anexo VI – Nota 8) En relación a las competencias del personal, existe una matriz de perfiles de puestos, agrupados por cada especialización, con las competencias técnicas requeridas para cubrirlo. (Anexo VI – Nota 7) Como resultado de un proceso de integración de distintos organismos (impositivo, aduanero y seguridad social) persisten la convivencia de distintos convenios colectivos de trabajo que generan asimetrías tanto administrativas como funcionales dentro de una misma área de TI que brinda servicios a distintas Direcciones Generales. La política restrictiva de incorporación de personal, provoca que: En algunas áreas existe dependencia crítica de individuos clave por falta de personal especializado. Esto también limita el intercambio de conocimientos, el planeamiento de la sucesión y la posibilidad de respaldarse o disponer una adecuada rotación. Limita el establecimiento de un Plan de Carrera con movilidades ascendentes u horizontales, que permitan a los individuos una perspectiva de desarrollo a largo plazo. Existen concursos a niveles de jefaturas, pero no en los niveles inferiores. 13 También existe la posibilidad de ascender de categoría con la obtención de un título universitario. La política de retención del personal está basada en la estabilidad del empleo público y los niveles salariales. Existe un riesgo latente de que si cambian estas condiciones, podría originarse un éxodo de personal altamente especializado a otras organizaciones. Se realizan evaluaciones de desempeño anuales, de cuyo resultado depende un incentivo económico. El procedimiento, que está sistematizado, no contempla una evaluación de los niveles inferiores hacia los niveles superiores. No existen mecanismos de autoevaluación. En relación a la capacitación, el Organismo elabora un Plan de Capacitación en base a una “Encuesta de necesidades de capacitación” que se incluyen en la confección del Plan de Gestión Anual, no en función del Plan estratégico de la SDG SIT. La capacitación se realiza en forma interna y externa. Se cuenta con una herramienta de capacitación virtual denominada “Campus Virtual” donde se deja a disposición del personal materiales referidos a distintas temáticas. En relación a la capacitación de usuarios internos de las aplicaciones implantadas, las denominadas “Pautas para el desarrollo y mantenimiento de sistemas informáticos en la AFIP”, establecen los esquemas de documentación que son elaborados por las divisiones de control de calidad de las áreas de desarrollo, que posteriormente quedan disponibles en la página de la Dirección de Capacitación. 4.1.8 Administrar la calidad Objetivo de control: Se debe elaborar y mantener un sistema de administración de calidad, el cual incluya procesos y estándares probados de desarrollo y de adquisición. Esto se facilita por medio de la planeación, implantación y mantenimiento del sistema de administración de calidad, proporcionando requerimientos, procedimientos y políticas claras de calidad. 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 desviaciones y la comunicación de los resultados a los interesados. La administración de calidad es esencial para garantizar que TI está dando valor a los objetivos de la organización, mejora continua y transparencia para los interesados. 14 Este objetivo de control afecta, primariamente: la efectividad la eficiencia y en forma secundaria: la integridad la confiabilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Inicial. Existe conciencia por parte de la dirección de la necesidad de un Sistema de Administración de Calidad (SAC). La administración de la calidad es impulsada por individuos cuando éste ocurre. La dirección realiza juicios informales sobre la calidad. Observaciones: Si bien en el Plan Estratégico del Organismo se plantea la necesidad de establecer lineamientos para desarrollar procesos de calidad, no se evidenció al momento de esta auditoría, la existencia de políticas de calidad, un plan de calidad y/o un sistema de administración de la misma, ni a nivel de la organización ni en la SDG SIT. No está definida en el organigrama el área correspondiente en la SDG SIT para llevarlo a cabo. Hay iniciativas aisladas en las direcciones de Operaciones y de Infraestructura Tecnológica para mantener la continuidad de los servicios a niveles razonables y en las áreas de desarrollo en la fase de homologación de aplicaciones. 4.1.9 Evaluar y administrar los riesgos de TI Objetivo de control: Crear y dar mantenimiento a un marco de trabajo de administración de riesgos. El marco de trabajo documenta un nivel común y acordado de riesgos de TI, estrategias de mitigación y riesgos residuales acordados. Cualquier impacto potencial sobre las metas del Organismo, causado por algún evento no planeado se debe identificar, analizar y evaluar. Se deben adoptar estrategias de mitigación de riesgos para minimizar los riesgos residuales a un nivel aceptable. El resultado de la evaluación debe ser entendible para los participantes y se debe expresar en términos financieros, para permitir a los participantes alinear los riesgos a un nivel aceptable de tolerancia. Este objetivo de control afecta, primariamente: 15 la confidencialidad la integridad la disponibilidad y en forma secundaria: la efectividad la eficiencia el cumplimiento la confiabilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Parcialmente repetible. Existe un enfoque de evaluación de riesgos inmaduro y en evolución. La administración de riesgos se da por lo general a altos niveles y se aplica de manera típica sólo a proyectos grandes o como respuesta a problemas. Los procesos de mitigación de riesgos están en implantación donde éstos se identifican. Observaciones: No está definida la función correspondiente en el organigrama. Tampoco se dispone de un marco de trabajo general de administración de riesgos de TI, integrado al gobierno y el marco de control. Existen iniciativas aisladas en algunas direcciones o departamentos que corresponden a las misiones y funciones que se fijaron para ellos. El área de Auditoría Interna cuenta con un marco de administración de riesgos para poder priorizar los procesos a controlar, ya que éste no es provisto por un área específica a tal fin. El Organismo cuenta con una herramienta de Gobierno Corporativo, Administración de Riesgos y Cumplimiento Regulatorio (GRC), pero sólo es utilizada por el área de Auditoría Interna. 4.1.10 Administrar proyectos Objetivo de control: Establecer un programa y un marco de control administrativo de proyectos para la administración de todos los proyectos de TI. El marco de trabajo debe garantizar la correcta asignación de prioridades y la coordinación de todos los proyectos. El marco de trabajo debe incluir un plan maestro, asignación de recursos, definición de entregables, aprobación de los usuarios, un enfoque de entrega por fases, aseguramiento de la calidad, un plan formal de pruebas, revisión de pruebas y revisión post-implantación 16 para garantizar la administración de los riesgos del proyecto y la entrega de valor para el Organismo. Este enfoque reduce el riesgo de costos inesperados y de cancelación de proyectos, mejora la comunicación y el involucramiento de los interesados y de los usuarios finales, asegura el valor y la calidad de los entregables de los proyectos, y maximiza su contribución a los programas de inversión en TI. Este objetivo de control afecta, primariamente: la efectividad la eficiencia Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Repetible. La alta dirección ha obtenido y comunicado la conciencia de la necesidad de la administración de los proyectos de TI. La organización está en proceso de desarrollar y utilizar algunas técnicas y métodos proyecto por proyecto. Los proyectos de TI han definido objetivos técnicos y de negocio de manera informal. Hay participación limitada de los interesados en la administración de los proyectos de TI. Las directrices iniciales se han elaborado para muchos aspectos de la administración de proyectos. La aplicación a proyectos de las directrices administrativas se deja a discreción de cada responsable de proyecto. Observaciones: No se ha normalizado un proceso de administración de proyectos que se aplique a todas las áreas. Se utilizan distintas herramientas y distintos criterios para el seguimiento de los proyectos, según sea el sector involucrado. 4.2. Adquirir e implementar 4.2.1 Identificar soluciones automatizadas Objetivo de control: La necesidad de una nueva aplicación o función requiere de análisis antes de la compra o desarrollo para garantizar que los requisitos del proyecto se satisfacen con un enfoque efectivo y eficiente. Este proceso cubre la definición de las necesidades, considera las fuentes alternativas, realiza una revisión de la factibilidad tecnológica y económica, ejecuta un análisis de riesgo y de costo-beneficio y concluye con una decisión final de desarrollar o comprar. Todos estos pasos permiten a las organizaciones minimizar 17 el costo para adquirir e implantar soluciones, mientras que al mismo tiempo facilitan el logro de los objetivos del Organismo. Este objetivo de control afecta, primariamente: la efectividad y en forma secundaria: la eficiencia Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Parcialmente definido. Existen orientaciones claras y estructuradas para determinar las soluciones de TI. El enfoque para la determinación de las soluciones de TI requiere la consideración de alternativas evaluadas entre otros, contra los requerimientos del proyecto o del usuario, las oportunidades tecnológicas, la factibilidad económica y las evaluaciones de riesgo. El proceso para determinar las soluciones de TI se aplica para algunos proyectos con base en factores tales como las decisiones tomadas por el personal involucrado, la cantidad de tiempo administrativo dedicado, y el tamaño y prioridad del requerimiento de proyecto original. Se usan enfoques estructurados para definir requerimientos e identificar soluciones de TI. Observaciones: Está definido el proceso de Ciclo de Vida de Desarrollo de Sistemas, alineado a la política de seguridad, aprobada por normativa vigente. (Anexo VI – Nota 9) Se establecen además procedimientos de interacción entre las áreas denominadas “Definidoras” y las áreas de desarrollo de aplicaciones de la SDG SIT, cuya documentación se encuentra formalizada en una serie de documentos entregables que incluyen desde la definición del requerimiento de las necesidades funcionales, determinación de los responsables tanto del área usuaria como del área informática, la asignación de recursos y el cronograma estimado de trabajo. Sin embargo, el procedimiento adolece de fuertes exclusiones, tales como: a) La atención de requerimientos de mantenimiento de sistemas del tipo correctivo originados debido a desvíos y/o errores en la programación. b) Los desarrollos realizados para satisfacer requerimientos puntuales de información. c) Los subcontratos o acuerdos de tercerización de software. 18 d) Los desarrollos realizados en carácter de pruebas de concepto como parte de tareas de investigación. Asimismo, la Subdirección General de Sistemas y Telecomunicaciones pueda autorizar la no utilización de estas pautas para determinados casos. Dada la ausencia de procedimientos para el tratamiento de situaciones de emergencia, en estos casos se utilizan las excepciones antes mencionadas, y no contempla un procedimiento de revisión de pistas de auditoría sobre las acciones tomadas. Por otra parte, el procedimiento carece, en su etapa de evaluación preliminar, de consideraciones relativas al análisis de factibilidad, análisis de riesgos y criterios formalizados para la administración de prioridades, estimación de costos y beneficios esperados que permitan la evaluación de cursos de acción alternativos, como la tercerización del desarrollo. Además, permite que la adopción de los documentos entregables sea a criterio de cada división de desarrollo, mientras cumpla con los contenidos mínimos requeridos para cada fase (definición, diseño, construcción e implementación) lo que genera que éstas hayan adoptado un conjunto distinto de documentos. (Anexo VI – Nota 10) En relación al entregable “REQ” (Requerimiento de Sistemas) no todas las áreas definidoras formalizan su confección, por lo cual esta tarea suele ser hecha por las áreas de desarrollo. Al momento de esta auditoría se encuentra en elaboración una Instrucción General que establecerá una nueva metodología de ciclo de vida de desarrollo de sistemas, que reemplazará a la actual y que toma en consideración algunos aspectos aquí observados. 4.2.2 Adquirir o desarrollar y mantener software aplicativo Objetivo de control: Las aplicaciones deben estar disponibles de acuerdo con los requerimientos del Organismo. Este proceso cubre el diseño de las aplicaciones, 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 elegidos. Esto permite al Organismo apoyar la operatividad de forma apropiada con las aplicaciones correctamente automatizadas. Este objetivo de control afecta, primariamente: 19 la efectividad la eficiencia y en forma secundaria: la integridad la confiabilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Parcialmente 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 de la organización. 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 lo que es muy probable que se salten pasos. Las actividades de mantenimiento se planean, programan y coordinan. Observaciones: La Subdirección General de Informática y Telecomunicaciones implementó las “Pautas para el desarrollo y mantenimiento de Sistemas Informáticos en la AFIP” (Anexo VI – Nota 9) donde se define el proceso de Ciclo de Vida de Desarrollo de Sistemas (CVDS). Las Pautas, están alineadas a la política de seguridad, aprobada mediante “Pautas y consideraciones de seguridad a tener en cuenta en el Ciclo de Vida del Desarrollo y Mantenimiento de Sistemas en relación con la Seguridad de la Información”. La misma contempla documentación, aprobaciones y escalamiento en las etapas relevantes tales como el diseño de alto nivel, el diseño detallado, fase de construcción, pruebas, implementación y el pase a producción de aplicaciones. Las misiones y funciones de las divisiones de Control de Calidad de las áreas de desarrollo contemplan la etapa de aseguramiento de la calidad del software enfocada a las pruebas y a la calidad de la documentación. Falta incluir en la metodología de CVDS un análisis de la calidad del desarrollo del software (Anexo VI – Nota 11) aunque existen algunas iniciativas para los desarrollos de servicios web. 20 La metodología de CVDS tampoco contempla consideraciones de costos ni la posibilidad de tercerizar el desarrollo o el mantenimiento. Al momento de esta auditoría se encuentra en elaboración una Instrucción General que establecerá una nueva metodología de ciclo de vida para el desarrollo de sistemas, que reemplazará a la actual, y que toma en consideración algunos aspectos aquí observados. En algunos casos, la contratación de servicios externos de desarrollo de sistemas se efectúa a través de contratos con universidades, en cuyas cláusulas contractuales se estipula la entrega de todo el software y documentación necesaria que permite al Organismo la independencia del proveedor en tareas de mantenimiento futuro. 4.2.3 Adquirir y mantener infraestructura tecnológica Objetivo de control: El Organismo debe contar con procesos para adquirir, implantar y actualizar la infraestructura tecnológica. Esto requiere de un enfoque planeado para adquirir, mantener y proteger la infraestructura de acuerdo con las estrategias tecnológicas convenidas y la disposición del ambiente de desarrollo y pruebas. Esto garantiza que exista un soporte tecnológico continuo para las aplicaciones. Este objetivo de control afecta, primariamente: la eficiencia y en forma secundaria: la efectividad la integridad la disponibilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Parcialmente definido. Existe un claro, definido y generalmente entendido proceso para adquirir y dar mantenimiento a la infraestructura de TI. El proceso respalda las necesidades de las aplicaciones críticas de lo organización y concuerda con la estrategia de TI, pero no se aplica en forma consistente. Se planea, programa y coordina el mantenimiento. Existe un ambiente independiente para pruebas de factibilidad. Observaciones: Por ser la AFIP un organismo que recibió los recursos informáticos de la Dirección General Impositiva, la Dirección General de Aduanas y de Dirección de 21 Seguridad Social existe una gran diversidad de plataformas de software y de motores de base de datos. Cuentan con algunos productos obsoletos, discontinuados por sus fabricantes, lo que implica que carezcan de soporte. No se encontró un plan formalmente definido para la integración efectiva de las áreas y sistemas que permita reducir la cantidad de plataformas existentes en la actualidad. No existe un plan de adquisición de infraestructura tecnológica formalmente definido y aprobado. Las compras de equipamiento se realizan en función de las necesidades detectadas y de las proyecciones a futuro de acuerdo a distintos parámetros obtenidos de los sistemas de control instalados. Existe la posibilidad que pueda producirse atraso tecnológico al momento de recepción de equipos nuevos debido al excesivo tiempo que insume el proceso completo de compras, desde la formulación del requerimiento hasta la recepción del producto solicitado, que puede superar el año. Si bien se realizan los mantenimientos adecuados a los servidores, equipos de comunicaciones y estaciones de trabajo, no existe un procedimiento automatizado para la instalación de actualizaciones en los sistemas operativos de computadoras personales por carecer de una herramienta necesaria para la instalación de los mismos. La falta de un plan de análisis de riesgo y evaluación de vulnerabilidades no permite identificar los posibles problemas que la falta de actualización en los sistemas operativos puedan producir. 4.2.4 Facilitar la operación y el uso Objetivo de control: El conocimiento sobre los nuevos sistemas debe estar disponible. Este proceso requiere la generación de documentación y manuales para usuarios y TI, y proporciona entrenamiento para garantizar el uso y la operación correctos de las aplicaciones y la infraestructura. Este objetivo de control afecta, primariamente: la efectividad la eficiencia y en forma secundaria: 22 la integridad la disponibilidad el cumplimiento la confiabilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Repetible. Se utilizan enfoques similares para generar procedimientos y documentación, pero no se basan en un enfoque estructural o marco de trabajo. No hay un enfoque uniforme para el desarrollo de procedimientos de usuario y de operación. Individuos o equipos de proyecto generan los materiales de entrenamiento, y la calidad depende de los individuos que se involucran. Los procedimientos y la calidad del soporte al usuario son variables, con insuficiente consistencia e integración a lo largo de la organización. Se proporcionan o facilitan programas de entrenamiento para las áreas decisorias y los usuarios, pero no hay un plan general para ofrecer o dar entrenamiento. Observaciones: El Decreto 618 del 10 de julio de 1997 establece que, entre otras facultades, que el Administrador Federal de Ingresos Públicos reglamenta el funcionamiento interno. El artículo 4 del mismo decreto prevé la posibilidad de delegar dichas potestades a favor de los Directores Generales y Subdirectores Generales. Estos actos internos de carácter resolutivo son formalizados a través de la aprobación de Resoluciones, Disposiciones o Instrucciones Generales. La Subdirección General de Sistemas y Telecomunicaciones genera este acto administrativo en cada política o procedimiento a aplicar. Dependiendo del alcance que se le quiera dar, es aprobada por una jerarquía acorde. En el caso de las áreas de desarrollo y mantenimiento de aplicaciones, las respectivas áreas de Control de Calidad deben verificar que la documentación esté confeccionada de acuerdo a los estándares establecidos. Sin embargo, su cumplimiento depende del criterio adoptado por cada área. Toda la documentación referida a disposiciones, resoluciones e instrucciones generales se encuentra disponible para los agentes del Organismo en la intranet. 23 No existe un mecanismo formalmente definido para la delegación de la capacitación en las aplicaciones a los usuarios finales, desde las áreas de desarrollo de software a la Dirección de Capacitación. 4.2.5 Adquirir recursos de TI Objetivo de control: Se deben suministrar recursos de TI, incluyendo personas, hardware, software y servicios. Esto requiere de la definición y ejecución de los procedimientos de adquisición, la selección de proveedores, el ajuste de arreglos contractuales y la adquisición en sí. El hacerlo así garantiza que se tengan todos los recursos de TI que se requieren de una manera oportuna y rentable. Este objetivo de control afecta, primariamente: la eficiencia y en forma secundaria: la efectividad el cumplimiento Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Definido. Existen políticas y procedimientos para la adquisición de TI, éstas toman como guía el proceso general de adquisición de la organización. Las compras de TI se integran en gran parte con los sistemas generales de adquisición del Organismo. Existen estándares de TI para la adquisición de recursos de TI. La administración de TI comunica la necesidad de contar con una administración adecuada de adquisiciones y contratos en toda la función de TI. Observaciones: Las adquisiciones se llevan a cabo en el marco de administración de proyectos y siguiendo la normativa de compras del Estado. Los procedimientos de adquisición son auditables. La ausencia de un Plan Estratégico lleva a que las decisiones de adquisición sean reactivas a las necesidades coyunturales. Existen además normativas internas que rigen para todas las áreas de AFIP. (Anexo VI – Nota 12) 24 De las órdenes de compras analizadas surge que se tuvieron en cuenta los aspectos legales y técnicos para cada contratación tales como responsabilidades y obligaciones legales, financieras, organizacionales, de seguridad y de protección de propiedad intelectual. La contratación de servicios externos de desarrollo de sistemas se efectúa a través de: Contratos con universidades, en cuyas cláusulas se estipula la entrega de todo el software y documentación necesaria que permite al Organismo la independencia del proveedor en tareas de mantenimiento. En algunos casos, el mantenimiento de estos sistemas, producen una sobrecarga de trabajo a la dotación existente que no está en condiciones de absorberlo adecuadamente. Personal contratado a plazo fijo. Estos contratos tienen una vigencia de tres meses y generalmente son renovables. El agente que trabaja más de cinco años en esta modalidad, cambia la figura a contrato por tiempo indeterminado. Esta indefinición provoca incertidumbre en la disponibilidad de recursos para proyectos a mediano y largo plazo. 4.2.6 Administrar cambios Objetivo de control: Todos los cambios, incluyendo el mantenimiento de emergencia y actualizaciones, relacionados con la infraestructura y las aplicaciones dentro del ambiente de producción, deben administrarse formal y controladamente. Los cambios (incluyendo procedimientos, procesos, sistemas y parámetros del servicio) se deben registrar, evaluar y autorizar previo a la implantación y contrastar contra los resultados planeados después de la misma. Esto garantiza la reducción de riesgos que impactan negativamente en la estabilidad o integridad del ambiente de producción. Este objetivo de control afecta, primariamente: la efectividad la eficiencia la integridad la disponibilidad y en forma secundaria: la confiabilidad 25 Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Parcialmente definido. Existe un proceso formal definido para la administración de cambios, que incluye la autorización del cambio y la administración de la liberación. Se dan soluciones temporales a los problemas y los procesos pero en ocasiones no se cumplen. El análisis de impacto de los cambios de TI se está formalizando para apoyar la implantación planeada de nuevas aplicaciones y tecnologías. Observaciones: Existe una instrucción general que define el proceso de Ciclo de Vida de Desarrollo de Sistemas para las aplicaciones desarrolladas por el Organismo (Anexo VI – Nota 9). Esta, está alineada a la política de seguridad, y aprobada formalmente. (Anexo VI – Nota 13) Se contempla documentación, aprobaciones y escalamiento en las etapas relevantes tales como el diseño de alto nivel, el diseño detallado, fase de construcción, aseguramiento de la calidad, pruebas, implementación y liberación de aplicaciones de software. La etapa de aseguramiento de la calidad de software está enfocada a las pruebas y a la calidad de la documentación, no así a un análisis de la calidad del desarrollo del software. Existen algunas iniciativas en este sentido para los desarrollos de servicios web (web services). Faltan procedimientos para el tratamiento de situaciones de cambios de emergencia, que contemplen una etapa de revisión obligatoria de pistas de auditoría sobre las acciones tomadas. Se observa en la aplicación práctica de esta metodología, las mismas falencias que en los desarrollos nuevos: falta de consideraciones de análisis de prioridades, factibilidad, riesgo, costos y beneficios esperados. La gestión de aseguramiento de la calidad está enfocada solamente a las pruebas. Al momento de esta auditoría se encuentra en elaboración una Instrucción General que establecerá una nueva metodología de ciclo de vida de desarrollo de sistemas, que toma en consideración algunos aspectos aquí observados. En relación a las actualizaciones de sistema operativo, existe un procedimiento formal para su instalación. 26 Con respecto a las estaciones de trabajo nuevas, existe un procedimiento inicial por el cual se entrega al proveedor el software de base (Windows XP service pack III, Zip central, Adobe reader, Adobe Flash Player, Open Office, Antivirus Panda) para que instale una imagen del mismo en las máquinas a entregar. Cualquier incidente posterior es canalizado por la Mesa de Ayuda que escala el problema de acuerdo al procedimiento del Sistema de Registración de Incidentes (SRI). 4.2.7 Instalar y acreditar soluciones y cambios Objetivo de control: Los nuevos sistemas necesitan estar funcionales una vez que su desarrollo se completa. Esto requiere pruebas adecuadas en un ambiente dedicado con datos de prueba relevantes, definir la transición e instrucciones de migración, planear la liberación y la transición en sí al ambiente de producción, y revisar la post-implantación. Esto garantiza que los sistemas operacionales estén en línea con las expectativas convenidas y con los resultados. Este objetivo de control afecta, primariamente: la efectividad y en forma secundaria: la eficiencia la integridad la disponibilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Parcialmente definido. Se cuenta con una metodología formal en relación con la instalación, migración, conversión y aceptación. Los procesos de TI para instalación y acreditación están integrados dentro del ciclo de vida del sistema y están automatizados hasta cierto punto. El entrenamiento, pruebas y transición y pase a producción tienen, probablemente, variaciones respecto al proceso definido, con base en decisiones individuales. Observaciones: Existe una instrucción general que define las actividades a seguir para la puesta efectiva en producción de las aplicaciones (Anexo VI – Nota 14), se incluye allí las responsabilidades de las áreas involucradas (Control de Calidad, Soporte Técnico y Área 27 Definidora) y la documentación que debe generarse, con sus correspondientes aprobaciones. En relación a los desarrollos de servicios web, al momento de esta auditoría se encontraba a la firma del Administrador Federal de Ingresos Públicos una resolución general que establece los procedimientos que deben utilizar los desarrolladores de aplicaciones de uso propio o de terceros y que además contempla la posibilidad de que los usuarios finales, puedan acceder al entorno de prueba (testing) y pase a producción. Resta incluir en la metodología general un procedimiento de emergencia que abarque las actuales exclusiones que permite esta resolución, tales como: La atención de requerimientos de mantenimiento de sistemas del tipo correctivo debidos a desvíos y/o errores en la programación. Los desarrollos realizados para satisfacer requerimientos puntuales de información. Los subcontratos o acuerdos de tercerización de software. Los desarrollos realizados en carácter de pruebas de concepto como parte de tareas de investigación. Casos expresamente autorizados por la SDG SIT. El pase de los aplicativos a producción los solicitan las áreas de Control de Calidad a las áreas de Operaciones a través de aplicativos. Este paso contempla la aprobación de las Áreas Definidoras, aunque no en todos los casos se cumple. La documentación de la aprobación de las etapas de pruebas no es homogénea en todos los departamentos de desarrollo. 4.3. Entregar y dar soporte 4.3.1 Definir y administrar los niveles de servicio Objetivo de control: La máxima autoridad debe definir un marco que promueva el establecimiento de acuerdos de nivel de servicio que formalicen los criterios de desempeño en virtud de los cuales se medirá su cantidad y calidad. Este objetivo de control afecta, primariamente: la efectividad la eficiencia 28 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. Los niveles de servicio están acordados pero no están controlados. Los reportes de los niveles de servicio están incompletos y dependen, en forma individual, de las habilidades y la iniciativa de los administradores. Están designados responsables de niveles de servicio por cada acuerdo con atribuciones definidas, pero con autoridad limitada. Si existe un proceso para el cumplimiento de los acuerdos de niveles de servicio es voluntario y no está debidamente implementado. Observaciones: De la documentación recibida surge que no existe un marco de trabajo para la administración de niveles de servicio entre las áreas usuarias y el prestador del servicio, en este caso la Dirección de Sistemas y Telecomunicaciones. Los acuerdos entre AFIP y distintos organismos, que proveen y reciben datos del mismo, carecen de definiciones técnicas precisas y de penalizaciones por incumplimiento. No existen acuerdos formalizados sobre niveles de servicio entre la Dirección de Sistemas y Telecomunicaciones y otras áreas de la AFIP, aunque en determinados casos existen plazos de tiempo no formales para la realización de tareas. 4.3.2 Administrar servicios de terceros Objetivo de control: La máxima autoridad debe implementar medidas de control orientadas a la revisión y al monitoreo de los contratos y procedimientos existentes para garantizar la eficacia y el cumplimiento de la política del Organismo. Este objetivo de control afecta, primariamente: la efectividad la eficiencia y en forma secundaria: 29 la confidencialidad la integridad la disponibilidad el cumplimiento la confiabilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de madurez: Definido. Existen procedimientos bien documentados para controlar los servicios de terceros con procesos claros para tratar y negociar con los proveedores. Cuando se hace un acuerdo de prestación de servicios, la relación con el tercero es meramente contractual. La naturaleza de los servicios a prestar se detalla en el contrato e incluye requerimientos legales, operacionales y de control. Se asigna la responsabilidad de supervisar los servicios de terceros. Los términos contractuales se basan en formatos estandarizados. Observaciones: Los procesos de compras de bienes y servicios se realizan de acuerdo con normativa vigente (Anexo V), y por las reglamentaciones emitidas por la ONTI y por SIGEN. Los servicios de los proveedores se encuentran identificados y formalizados por medio de órdenes de compra. No existe una calificación de los servicios que tome en cuenta su importancia y su criticidad para la organización. La documentación sobre las relaciones técnicas, que incluyen los roles, responsabilidades, metas y entregables se encuentran definidas en los pliegos de compras. Como no existe un plan de riesgos para la AFIP, no se encuentran identificados ni existen planes de mitigación sobre los riesgos relacionados con los proveedores que garantice una entrega segura que permita la continuidad de los servicios. 4.3.3 Administrar el desempeño y la capacidad Objetivo de control: Se debe implementar un proceso de administración orientado a la recopilación de datos, al análisis y a la generación de informes sobre el desempeño de los recursos de Tecnología de la Información, la dimensión de los sistemas de aplicación y la 30 demanda de cargas de trabajo. Este proceso debe incluir el pronóstico de las necesidades futuras, almacenamiento y contingencias, y garantizar que los recursos de información que soportan los requerimientos del Organismo estén disponibles de manera continua. Este objetivo de control afecta, primariamente: la efectividad la eficiencia y en forma secundaria: la disponibilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de madurez: Administrado. Hay procesos y herramientas disponibles para medir el uso del sistema, el desempeño y la capacidad, y los resultados se comparan con metas definidas. Hay información actualizada disponible, que brinda estadísticas estandarizadas y alerta sobre incidentes causados por falta de desempeño o de capacidad. Los problemas que aparezcan se enfrentan de acuerdo con procedimientos definidos y estandarizados. Se utilizan herramientas automatizadas para monitorear recursos específicos tales como espacio en disco, servidores y la electrónica de las redes. Las estadísticas de desempeño y capacidad son reportadas en términos de los procesos del Organismo. Observaciones: Se realiza el monitoreo de parámetros tales como capacidad, desempeño, ambientales del centro de cómputos y el funcionamiento del sistema de energía eléctrica, estado de las UPS y del sistema de alarma contra incendios. Los datos obtenidos de los sistemas de control alimentan dos herramientas (PATROL y TMART) que permiten obtener estadísticas que se utilizan para prever las necesidades futuras del Organismo la organización. Los dispositivos de control informan automáticamente cualquier desviación no esperada emitiendo alarmas a los operadores y enviando mensajes a los teléfonos celulares de los responsables de las áreas involucradas. Se almacenan los logs de todos los incidentes, y se confeccionan estadísticas de desempeño semanal y mensual. 31 La seguridad de los sistemas del Organismo es controlada por la División Monitoreo y Detección que depende Departamento de Seguridad Informática de la Dirección de Infraestructura Tecnológica. Para ello se analizan los datos de las siguientes herramientas: Firewall Central de Red IPS (Intrusion Prevention Systems – Sistemas de prevención de intrusión) IDS (Intrusion Detection Systems – Sistemas de detección de intrusión) Proxy Firewalls Departamentales WAF (Detección en línea de intrusiones) Análisis de Aplicaciones WEB Se emiten alertas según parámetros establecidos y se realizan reportes sobre la cantidad de eventos que se producen. El monitoreo de los sistemas de comunicaciones lo realiza la División Gestión de Redes que se ocupa de controlar el tráfico de las redes LAN, MAN, WAN, satelital y WiFi. Este control se realiza con herramientas propias y con aplicaciones suministradas por los proveedores. 4.3.4 Garantizar la continuidad del servicio Objetivo de control: Se requiere desarrollar, mantener y probar planes para asegurar la continuidad de servicio. Al respecto, se debe almacenar respaldos fuera de las instalaciones y brindar entrenamiento periódico. Este objetivo de control afecta, primariamente: la efectividad la disponibilidad y en forma secundaria: la eficiencia Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de madurez: Repetible. Se asigna la responsabilidad para mantener la continuidad del servicio. Los enfoques para asegurar la continuidad están fragmentados. No hay un plan de continuidad de TI documentado, aunque hay compromiso para mantener disponible 32 la continuidad del servicio y sus principios más importantes se conocen. Existe un inventario de sistemas y componentes críticos, pero puede no ser confiable. Las prácticas de continuidad en los servicios emergen, pero el éxito depende de los individuos. Observaciones: No existe un Plan de Continuidad de Servicios que contemple todos los posibles escenarios que puedan presentarse. Actualmente se encuentra en proceso de definición la realización de un estudio de análisis de riesgo que servirá como base para redacción del Plan de Continuidad. No existe un sitio alternativo de procesamiento. 4.3.5 Garantizar 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 proceso incluye el establecimiento y mantenimiento de roles y responsabilidades, políticas, estándares y procedimientos de TI. La administración de la seguridad también incluye la implementación de los controles de acceso lógico que garantizan que el ingreso a los sistemas, datos y programas está limitado a los usuarios autorizados, los monitoreos y pruebas periódicas así como 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: Administrado. Las responsabilidades sobre la seguridad de TI son asignadas, administradas e implementadas de forma clara. Regularmente se lleva a cabo un análisis de impacto y de riesgos de seguridad. Las políticas y prácticas de seguridad se complementan con referencias específicas de seguridad. El contacto con métodos para 33 promover la conciencia de la seguridad es obligatorio. La identificación, autenticación y autorización de los usuarios está estandarizada. La certificación en seguridad es buscada por parte del personal que es responsable de la auditoría y la administración de la seguridad. Las pruebas de seguridad se hacen utilizando procesos estándares y formales que llevan a mejorar los niveles de seguridad. Los procesos de seguridad de TI están coordinados con la función de seguridad de toda la organización. Los reportes de seguridad están ligados con los objetivos del Organismo. La capacitación sobre seguridad de TI se planea, administra e imparte para todo el Organismo de manera que responda a las necesidades del mismo y a los perfiles de riesgo de seguridad. Observaciones: La administración de la seguridad de los sistemas está a cargo del Departamento de Seguridad Informática que depende de la Dirección de Infraestructura Tecnológica. Este departamento está dividido en dos Divisiones: Monitoreo y Detección Administración de Accesos No tiene bajo su responsabilidad la seguridad física de la sala cofre donde se encuentran los servidores del Organismo. Existe un Comité de Seguridad compuesto por los titulares de las direcciones interesadas y presidido por la Subdirección General de Sistemas y Telecomunicaciones. La posición actual del Departamento de Seguridad Informática no se considera la más apropiada dentro de la organización porque depende de la Dirección de Infraestructura Tecnológica y esta situación podría influir en un correcto impacto horizontal hacia todo el Organismo de las decisiones tomadas por el citado departamento. Existe un Manual aprobado de Políticas de Seguridad de la Información. Desde su publicación no existieron revisiones ni modificaciones. Las actualizaciones o ampliaciones de su contenido se realizan mediante Instrucciones Generales que son impulsadas y aprobadas por el Comité de Seguridad de la Información. Los usuarios acceden a las distintas aplicaciones a través del Sistema Único de Autenticación, este es un sistema que permite que el usuario sólo necesite autenticarse una 34 vez para acceder a los sistemas que tiene autorizados. Este está vinculado con el sistema SARHA de administración de RR.HH. Se contemplan también las situaciones de baja de personal, licencias ordinarias y traslado de dependencias. 4.3.6 Identificar y asignar costos Objetivo de control: Se debe implementar un sistema de imputación de costos que garantice que se registren, calculen y asignen los costos de acuerdo con el nivel de detalle requerido y el ofrecimiento de servicio adecuado. Este proceso incluye la construcción y operación de un sistema para capturar, distribuir y reportar costos de TI a los usuarios de los servicios. Este objetivo de control afecta, primariamente: la eficiencia la confiabilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de madurez: Repetible. Hay conciencia general de la necesidad de identificar y asignar costos. La asignación de costos está basada en los del hardware. No hay capacitación o comunicación formal sobre la identificación de costos estándar y sobre los procedimientos de asignación. No está determinada la responsabilidad sobre la recopilación o la asignación de los costos, particularmente del software desarrollado. Observaciones: Los costos de TI asociados al desarrollo de sistemas no son identificados para ser imputados a las áreas correspondientes. Los costos de los servicios de TI no están vinculados a los procesos del Organismo, no existe un modelo definido para la asignación de los mismos. Solamente se imputan a las áreas respectivas aquellos vinculados a las compras de hardware que patrimonialmente queden a su cargo. 4.3.7 Educación y capacitación de los usuarios Objetivo de control: Se debe establecer y mantener un plan integral de capacitación y desarrollo. Para ello, se requieren identificar las necesidades de entrenamiento de cada 35 grupo. Además, este proceso debe incluir la definición y ejecución de una estrategia para llevar a cabo un entrenamiento efectivo y para medir los resultados. Este objetivo de control afecta, primariamente: la eficacia y en forma secundaria: la eficiencia Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de madurez: Definido. El programa de entrenamiento y educación se institucionaliza y comunica, y los empleados y gerentes identifican y documentan las necesidades de entrenamiento. Los procesos de entrenamiento y educación se estandarizan y documentan. Para soportar el programa de entrenamiento y educación, se establecen presupuestos, recursos, instructores e instalaciones. Se imparten clases formales sobre conducta ética y sobre conciencia y prácticas de seguridad en los sistemas. La mayoría de los procesos de entrenamiento y educación son monitoreados, pero no todas las desviaciones son susceptibles de detección por parte de la gerencia. El análisis sobre problemas de entrenamiento y educación sólo se aplica de forma ocasional. Observaciones: El relevamiento de las necesidades de capacitación y de la organización de los distintos cursos es responsabilidad de la Dirección de Capacitación. La recolección de las necesidades de capacitación de las distintas áreas del Organismo se realiza mediante encuestas automatizadas Se otorgan becas para capacitar externamente a los agentes (el capacitado de dictar cursos de lo aprendido a solicitud del Organismo), y se contratan cursos de capacitación con los proveedores cuando se adquiere nueva infraestructura. La capacitación interna se realiza con personal propio, y se dictan cursos por medio de procedimientos WEB utilizando una herramienta llamada CAMPUS. En las áreas de desarrollo se notó falta de cursos de alto nivel para los agentes con mayor capacidad técnica. En estas mismas áreas la cantidad acotada de personal no permite que el mismo pueda dedicar las horas necesarias para capacitación. 36 4.3.8 Administrar la mesa de servicio y los incidentes Objetivo de control: Responder de manera oportuna y efectiva a las consultas de los usuarios de TI, requiere de una mesa de servicio bien diseñada y ejecutada, y de un proceso de administración de incidentes. Este proceso incluye la creación de una función de mesa de servicio con registro, escalamiento de incidentes, análisis de tendencia, análisis causaraíz y resolución. Los beneficios incluyen el incremento en la productividad gracias a la resolución rápida de consultas. Además, permite identificar la causa raíz (tales como un pobre entrenamiento a los usuarios) a través de un proceso de reporte efectivo. Este objetivo de control afecta, primariamente: la efectividad la eficacia Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de madurez: Definido. Se reconoce y se acepta la necesidad de contar con una función de mesa de servicio y un proceso para la administración de incidentes. Los procedimientos se estandarizan y documentan, pero se lleva acabo entrenamiento informal. Se deja la responsabilidad al individuo de conseguir entrenamiento y de seguir los estándares. Se desarrollan guías de usuario y preguntas frecuentes (FAQs), pero los individuos deben encontrarlas y puede ser que no las sigan. Las consultas y los incidentes se rastrean de forma manual y se monitorean de forma individual, pero no existe un sistema formal de reporte. No se mide la respuesta oportuna a las consultas e incidentes. Los usuarios han recibido indicaciones claras de dónde y cómo reportar problemas e incidentes. Observaciones: La función la realiza en su mayor parte la División Mesa de Ayuda que depende del Departamento de Soporte Técnico. Para el registro de los incidentes se utiliza una herramienta llamada Sistema de Registración de Incidentes (SRI). Estos pueden llegar vía telefónica, o por correo electrónico. En ambos casos el sistema genera un ticket con un número único para su identificación. 37 Si es resuelto en el momento, el incidente es cerrado por el operador, si este no lo puede resolver puede consultarlo al personal con mayor experiencia sobre el tema, y si aún así no puede ser resuelto se deriva el mismo al área que corresponda. Al recibir la conformidad, el operador cierra el ticket. Si bien el sistema SRI puede discriminar cada ticket por importancia, esta clasificación no es utilizada para asignar un orden en la resolución de incidentes, sino que son resueltos a medida que ingresan al sistema. En el sistema no queda almacenada la conformidad del usuario sobre la solución del incidente. El sistema almacena información sobre distintos parámetros que permiten realizar informes sobre el desempeño de la Mesa de Ayuda, pero los mismos sólo se realizan si son solicitados con algún fin específico. No se realizan encuestas de satisfacción del usuario. 4.3.9 Administrar la configuración Objetivo de control: Se deben implementar controles que identifiquen y registren todos los bienes de Tecnología de la Información y su ubicación física, y un programa de verificación regular que confirme su existencia. Este programa debe incluir la recolección de información de la configuración inicial, el establecimiento de normas, la verificación y auditoría de la información de la configuración y la actualización del repositorio de configuración conforme se necesite. Este objetivo de control afecta, primariamente: la efectividad y en forma secundaria: la eficiencia la disponibilidad la confiabilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de madurez: Definido. Los procedimientos y las prácticas de trabajo se han documentado, estandarizado y comunicado, pero la capacitación y la aplicación de 38 estándares dependen del individuo. Además se han implementado herramientas de administración de configuración entre plataformas. Es poco probable detectar las desviaciones de los procedimientos y las verificaciones físicas se realizan de manera inconsistente. Se lleva a cabo algún tipo de automatización para ayudar a rastrear cambios en el software o en el hardware. La información de la configuración es utilizada por los procesos interrelacionados. Observaciones: Con respecto al parque informático de PC de usuarios, existen dos ámbitos bien diferenciados, por un lado todos los equipos ingresados al dominio de la AFIP (aproximadamente un 80%) y por otro los que están fuera de él ubicados principalmente el edificio de Hipólito Yrigoyen (aproximadamente 370 equipos). No existe una herramienta que permita monitorear cambios en el software instalado de las estaciones de trabajo. Tampoco existe una herramienta que permita actualizar los sistemas operativos de forma automática. Los equipos nuevos son entregados con una configuración que le es entregada al proveedor para que él mismo las instale. Si bien en la actualidad los usuarios de dominio no tienen privilegios de administración de sus equipos, los que están fuera de él podrían tener estos privilegios, lo que tendría como consecuencia la falta de control del software instalado en los mismos. No existen mecanismos físicos que impidan el reemplazo de componentes internos de las estaciones de trabajo por personal no autorizado. 4.3.10 Administración de problemas Objetivo de control: Se debe implementar un sistema de administración de problemas que registre y de respuesta a todos los incidentes. El proceso también incluye la identificación de recomendaciones para la mejora, el mantenimiento de registros y la revisión de estatus de las acciones correctivas. Este objetivo de control afecta, primariamente: la eficacia la eficiencia y en forma secundaria: 39 la disponibilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de madurez: Definido. Se acepta la necesidad de un sistema integrado de administración de problemas y se evidencia con el apoyo de la gerencia y la asignación de presupuesto para personal y capacitación. Se estandarizan los procesos de escalamiento y resolución de problemas. El registro y rastreo de problemas y de sus soluciones se dividen dentro del equipo de respuesta, utilizando las herramientas disponibles sin centralizar. Es poco probable detectar las desviaciones de los estándares y de las normas establecidas. La información se comparte entre el personal de manera formal y proactiva. La revisión de incidentes y los análisis de identificación y resolución de problemas son limitados e informales. Observaciones: Los problemas son reportados por los usuarios por medio de llamadas telefónicas o a través de correos electrónicos a Mesa de Ayuda donde el operador genera un ticket. La División de Mesa de Ayuda no tiene un segundo nivel de escalamiento de problemas, sino que cuenta con referentes. Los incidentes que pueden presentarse son derivados a las áreas correspondientes cuando los operadores no pueden resolverlos. De esta forma se recargan las tareas de sectores como los de desarrollos que deben dedicar personal y recursos para actividades que no figuran en sus misiones y funciones. La aceptación de la solución del problema la realiza el usuario por medio de un correo electrónico no quedando dicha constancia en el SRI. El cierre del ticket en el sistema lo realiza el operador en forma manual cuando recibe el correo electrónico de parte del usuario con la aprobación de la solución brindada. 4.3.11 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. El proceso de administración de información también incluye el establecimiento de procedimientos efectivos para 40 administrar la librería de medios de soporte para el respaldo y la recuperación de datos, así como su eliminación apropiada. Este objetivo de control afecta, primariamente: la integridad la confiabilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de madurez: Definido. Se entiende y acepta la necesidad de la administración de datos, tanto dentro de TI como a lo largo de toda la organización. Se establece la responsabilidad sobre la administración de los datos. Se asigna la propiedad sobre los datos a la parte responsable que controla la integridad y la seguridad. Los procedimientos de administración de datos se formalizan dentro de TI y se utilizan algunas herramientas para respaldos/recuperación y desecho de equipo. Se lleva a cabo algún tipo de monitoreo sobre la administración de datos. Se definen métricas básicas de desempeño. Comienza a aparecer el entrenamiento sobre administración de información. Observaciones: La propiedad de los datos internos esta formalmente asignada a las áreas definidoras. No existe un diccionario de datos del Organismo, ni están definidos sus niveles de criticidad. En los casos en que se verifica que los archivos de datos recibidos de otros organismos contengan errores, se solicita que sean reenviados. En aquellos casos en que el archivo reenviado tenga el mismo nombre que el recibido con errores, se guarda en el repositorio agregándole un sufijo secuencial para diferenciarlo del primero. No está definido formalmente el tiempo que dichos archivos con datos erróneos deben permanecer en el repositorio. 4.3.12 Administración de instalaciones Objetivo de control: La protección del equipo de cómputo y del personal, requiere de instalaciones bien diseñadas y administradas. Se deben instalar controles ambientales y físicos adecuados cuya revisión se efectúe periódicamente a fin de determinar su correcto funcionamiento. 41 Este objetivo de control afecta, primariamente: la integridad la disponibilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de madurez: Definido. Se entiende y acepta a lo largo de todo el Organismo la necesidad de mantener un ambiente de cómputo controlado. Los controles ambientales, el mantenimiento preventivo y la seguridad física cuentan con presupuesto autorizado y verificado por la gerencia. Se aplican restricciones de acceso, permitiendo el ingreso a las instalaciones de cómputo sólo al personal autorizado. Los visitantes son acompañados. Las instalaciones físicas mantienen un perfil bajo y no son reconocibles de manera sencilla. Las autoridades monitorean el cumplimiento con los reglamentos de salud y seguridad. Observaciones: La AFIP dispone de una sala cofre donde se almacenan los servidores y equipos de comunicaciones principales. La misma se encuentra sellada y protege a todos los equipos contra incendios, humo, gases corrosivos, interferencias electromagnéticas, filtraciones, accesos indebidos, etc. Si bien el acceso a la sala cofre se controla mediante el uso de una tarjeta magnética y un dispositivo de lectura de huellas dactilares, no se observó la existencia de un registro de visitantes al centro de cómputos. El Organismo cuenta con 3 generadores autónomos y 2 sistemas de UPS independientes que permiten el funcionamiento de todo el centro de cómputos en el caso de falta de suministro de energía eléctrica. Todos los parámetros físicos del centro de cómputos (energía, humedad, temperatura, etc.) se encuentran monitoreados en forma permanente. El Organismo no dispone de un sitio alternativo de procesamiento para el caso en que el centro de cómputos deje de operar. No existe un plan de contingencia que indique los procedimientos necesarios para los distintos escenarios que puedan presentarse. 42 4.3.13 Administración de operaciones Objetivo de control: Un procesamiento completo y apropiado de la información requiere su efectiva administración y el mantenimiento del hardware involucrado. Este proceso incluye la definición de políticas y procedimientos de operación para una administración efectiva del procesamiento programado, protección de datos de salida sensitivos, monitoreo de infraestructura y mantenimiento preventivo de hardware. Este objetivo de control afecta primariamente: la efectividad la eficiencia y en forma secundaria: la integridad la disponibilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de madurez: Administrado. Las operaciones de cómputo y las responsabilidades de soporte están definidas de forma clara y la propiedad está asignada. Las operaciones se soportan a través de presupuestos de recursos para gastos de capital y de recursos humanos. La capacitación se formaliza y está en proceso. Las programaciones y las tareas se documentan y comunican, tanto a la función interna de TI como a los usuarios. Es posible medir y monitorear las actividades diarias con acuerdos estandarizados de desempeño y de niveles de servicio establecidos. Cualquier desviación de las normas establecidas es atendida y corregida de forma rápida. La gerencia monitorea el uso de los recursos de cómputo y la terminación del trabajo o de las tareas asignadas. Existe un esfuerzo permanente para incrementar el nivel de automatización de procesos como un medio de mejora continua. Se establecen convenios formales de mantenimiento y servicio con los proveedores. Hay una completa alineación con los procesos de administración de problemas, capacidad y disponibilidad, soportados por un análisis de causas de errores y fallas. Observaciones: Las tareas que comprenden al procesamiento son realizadas por la División de Operación de Sistemas que depende del Departamento de Operaciones. 43 Los procedimientos se encuentran definidos formalmente por una Instrucción General que aprueba el Calendario Operativo de Gestión en el cual se establecen las frecuencias y parámetros de las tareas a realizar. Existen procedimientos formalmente definidos para el monitoreo de la infraestructura de TI, y para el control de los eventos que se produzcan. Mediante herramientas de monitoreo (PATROL y TMART) se controlan todos los parámetros necesarios (uso de memoria, espacio en disco, servicios en línea, parámetros ambientales, sistema de energía, etc.) para un correcto funcionamiento del centro de cómputos. La División Control de Datos y Procesos se encarga del pase a producción de la información recibida de organismos externos (ANSES, Banco Nación, etc.) controlando la integridad de la información recibida y poniéndola disponible para su procesamiento. 4.4 Monitorear y evaluar 4.4.1 Monitorear y evaluar el desempeño de TI Objetivo de control: Una efectiva administración del desempeño de TI requiere un proceso de monitoreo definido formalmente. Éste debe incluir la definición de indicadores de desempeño relevantes, reportes sistemáticos y oportunos y tomar medidas expeditivas cuando existan desviaciones. El monitoreo se requiere para garantizar que las cosas correctas se hagan y que estén de acuerdo con el conjunto de direcciones y políticas. Este objetivo de control afecta, primariamente: la efectividad la eficiencia y en forma secundaria: la confidencialidad la integridad la disponibilidad el cumplimiento la confiabilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo 44 Nivel de Madurez: Repetible. Se han identificado algunas mediciones básicas a ser monitoreadas. Los métodos y las técnicas de recolección y evaluación existen, pero los procesos no se han adoptado en todo el Organismo. La interpretación de los resultados del monitoreo se basa en la experiencia de individuos clave. Herramientas limitadas son seleccionadas y aplicadas en algunas áreas para recolectar información, pero esta recolección no se basa en un enfoque planeado. Observaciones: Existen diferencias en el monitoreo de TI según el sector de que se trate. En las áreas de desarrollo y mantenimiento de software no se ha normalizado un proceso de administración de proyectos que sea común a todas. Se utilizan distintas herramientas y criterios para el seguimiento de los proyectos. La metodología de Ciclo de Vida de Desarrollo de Sistemas vigente permite la adopción de documentación entregable a criterio de cada área de desarrollo. Esto impide la uniformidad de información, y la documentación realizada difiere en estructura y calidad, según el sector de que se trate. La ausencia de un marco de trabajo de aseguramiento de la calidad, basado en estándares predefinidos, no permite mediciones de desempeño, que sean obtenidas mediante la generación de indicadores, provenientes de diversos puntos de control interno, en los procesos de desarrollo. En las áreas dependientes de la Dirección de Infraestructura, se ha establecido un monitoreo en tiempo real, con estándares de desempeño preestablecidos empleando herramientas automáticas. Los resultados obtenidos se utilizan para tomar acciones preventivas o correctivas según el caso. Los niveles de servicios los ha definido la Subdirección General de Sistemas y Telecomunicaciones. No se han formalizado acuerdos de niveles de servicio con los usuarios internos. Por otra parte, el monitoreo de la infraestructura para gestión de datos está a cargo de la División de Monitoreo y Gestión del Servicio. Mediante el cumplimiento de un procedimiento formalizado, procura la operación continua y la disponibilidad de todos los servicios por ellos suministrados. Se emiten alertas cuando se producen variaciones con respecto a los estándares fijados como óptimos. Cada incidente se identifica unívocamente. 45 Si bien el seguimiento del incidente está normado por un procedimiento formalizado, el mismo es manual y el intercambio de información con las áreas responsables de solucionar el problema se lleva a cabo mediante correos electrónicos o comunicaciones telefónicas. Al no contar con una herramienta integrada que lo integre y que incluya el escalamiento y las comunicaciones inter áreas, se dificulta el rastreo de información histórica para un análisis posterior. 4.4.2 Monitorear y evaluar el control interno Objetivo de control: Establecer un programa de control interno efectivo para TI requiere un proceso bien definido de monitoreo. Este proceso incluye el monitoreo y el reporte de las excepciones de control, resultados de las auto-evaluaciones y revisiones por parte de terceros. Un beneficio clave del monitoreo del control interno es proporcionar seguridad respecto a las operaciones eficientes y efectivas y el cumplimiento de las leyes y regulaciones aplicables. Este objetivo de control afecta, primariamente: la efectividad 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: Administrado y medible. La gerencia tiene implantado un marco de trabajo para el monitoreo del control interno de TI. La organización ha establecido niveles de tolerancia para el proceso de monitoreo del control interno. Se han implantado herramientas para estandarizar evaluaciones y para detectar de forma automática las excepciones de control. Se ha establecido una función formal para el control interno de TI, con profesionales especializados y certificados que utilizan un marco de trabajo de control 46 formal avalado por la alta dirección. Un equipo calificado de TI participa de forma rutinaria en las evaluaciones de control interno. Se ha establecido una base de datos de métricas para información histórica sobre el monitoreo del control interno. Se realizan revisiones entre pares para verificar el monitoreo del control interno. Observaciones: Hay normativa debidamente aprobada que determina las “Misiones y funciones de la Unidad de Auditoría Interna”, del cual depende el Departamento de Auditoría de Sistemas Informáticos. Existe un marco de trabajo para el monitoreo del control interno de TI, siguiendo el cumplimiento de la resolución de SIGEN 48/05 respecto a las Normas de Control Interno para Tecnología de la Información y los lineamientos estratégicos dispuestos en el Anexo I del decreto 378/2005 del Plan Nacional de Gobierno Electrónico. La metodología está establecida por el Manual de Auditoría Interna de la Unidad de Auditoría Interna de la Administración Federal de Ingresos Públicos de acuerdo con la resolución de SIGEN 152/02 “Normas de Auditoría Interna Gubernamental” según en el marco de la ley 24.156 de Administración Financiera y de los Sistemas de Control del Sector Público Nacional. El Organismo cuenta con un Departamento de Auditoria de Sistemas Informáticos, dependiente de la Subdirección General de Auditoría Interna, que cuenta con profesionales internacionalmente certificados en Auditoría de Sistemas (CISA) y Certificación de Riesgos (CRISC). Se ha adquirido una herramienta de Gobierno Corporativo, Administración de Riesgos y Cumplimiento Regulatorio denominada GRC. A través de ésta, se lleva a cabo un análisis de riesgo donde se identifican la mayoría de los procesos involucrados en la operatoria de TI, la evaluación de los riesgos asociados a cada proceso (la magnitud de la pérdida o daño posible y la probabilidad que dicha pérdida o daño llegue a ocurrir). En función de la criticidad que refleje cada caso individual, se asigna prioridades en el Plan Ciclo de Auditoría, donde se fija la frecuencia de la revisión y la carga de recursos a asignar (principalmente, horas hombre). El Plan Ciclo de Auditoría contempla información histórica de 5 (cinco) años hacia atrás del período presente y una proyección de 5 (cinco) 47 años hacia adelante. Están contempladas un promedio de 8.386 horas de auditoría para cada año. 4.4.3 Garantizar el cumplimiento con requerimientos externos Objetivo de control: Una supervisión efectiva del cumplimiento regulatorio requiere del establecimiento de un proceso independiente de revisión para garantizar el cumplimiento de las leyes y regulaciones. Este proceso incluye la definición de una declaración de auditoría, independencia de los auditores, ética y estándares profesionales, planeación, desempeño del trabajo de auditoría y reportes y seguimiento a las actividades de auditoría. El propósito de este proceso es proporcionar un aseguramiento positivo relativo al cumplimiento de TI de las leyes y regulaciones. Este objetivo de control afecta, primariamente: el cumplimiento y en forma secundaria: la confiabilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Repetible. Existe el entendimiento de la necesidad de cumplir con los requerimientos externos y la necesidad se comunica. En los casos en que el cumplimiento es recurrente se han desarrollado procedimientos individuales al respecto. No existe un enfoque estándar. Hay dependencia del conocimiento y responsabilidad de los individuos y los errores son posibles. Se brinda entrenamiento informal respecto a los requerimientos externos y a los temas de cumplimiento. Observaciones: No se encontró un catálogo de requerimientos legales y regulatorios relacionados con la prestación del servicio de TI ni un procedimiento formal para su desarrollo. No existen informes sobre el cumplimiento de las actividades de TI con los requerimientos externos legales y regulatorios. 4.4.4 Proporcionar gobierno de TI Objetivo de control: El establecimiento de un marco de trabajo de gobierno efectivo, incluye la definición de estructuras, procesos, liderazgo, roles y responsabilidades 48 organizacionales para garantizar que las inversiones en TI estén alineadas y de acuerdo con las estrategias y objetivos del Organismo. Este objetivo de control afecta, primariamente: la efectividad 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. Existe conciencia sobre los temas de gobierno de TI. Las actividades y los indicadores de desempeño del gobierno de TI, los cuales incluyen procesos planeación, entrega y supervisión de TI, están en desarrollo. Los procesos de TI seleccionados se identifican para ser mejorados con base en decisiones individuales. Se han identificado mediciones básicas para el gobierno de TI, así como métodos de evaluación y técnicas; sin embargo, el proceso no ha sido adoptado a lo largo del Organismo. La comunicación respecto a los estándares y responsabilidades de gobierno se deja a los individuos. Los individuos impulsan los procesos de gobierno en varios proyectos y procesos de TI. Los procesos, herramientas y métricas para medir el gobierno de TI no abarcan la totalidad de la gestión de TI. Observaciones: El marco de gobierno de TI es incompleto: Falta un Plan Estratégico de TI alineado con el plan Estratégico del Organismo, que garantice un entendimiento compartido entre los objetivos y la función de TI. No se ha normalizado un proceso de administración de proyectos que se aplique a todas las áreas. Se utilizan distintas herramientas y distintos criterios para los aspectos considerados para el seguimiento. 49 No se ha definido un programa de administración de la calidad, inserto en un sistema donde se pueda evaluar el desempeño de la función de TI, su contribución a los objetivos estratégicos del Organismo y que sirva como herramienta de toma de decisiones ante posibles desvíos entre los resultados esperados y los reales. No existe un marco de administración presupuestaria que abarque todas las áreas de TI, que contemple la contabilidad por centro de costos imputándolos a los proyectos y calculándose los beneficios esperados y su contribución a las misiones y funciones de la organización. Falta la definición y ejecución de un marco integral de administración de riesgos que defina cuál es el nivel de riesgo aceptado por el Organismo y que, con prácticas de administración de riesgo, se asegure que el mismo no exceda las pautas establecidas. 5. Comunicación del proyecto de informe y análisis de los descargos formulados por la Administración Federal de Ingresos Públicos 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 7 de mayo de 2013, por Nota AGN N° 38/13-AG4. Las mismas fueron remitidas por el Ente el 27 de junio de 2013. Como consecuencia del análisis del descargo presentado por el Organismo auditado (Anexo V), se ratifican las observaciones oportunamente formuladas. 6. Recomendaciones Se detallan a continuación las buenas prácticas aconsejadas para cada uno de los procesos, independientemente del hecho de que ya hayan sido parcialmente puestas en práctica. 6.1. Planificar y organizar 6.1.1. Definir un plan estratégico para TI Recomendaciones: Crear un plan estratégico que defina, en cooperación con los interesados relevantes, cómo la TI contribuirá a los objetivos estratégicos del Organismo. Definir cómo se 50 cumplirán y medirán esos objetivos y recibir una autorización formal de los interesados. El plan estratégico de TI debe incluir: el presupuesto de la inversión/operativo, las fuentes de financiamiento, la estrategia de procuración, la estrategia de adquisición, y los requerimientos legales y regulatorios. Debe ser lo suficientemente detallado para permitir la definición de planes tácticos de TI. Crear un conjunto de planes tácticos de TI que se deriven del plan estratégico de TI. Estos deben establecer las iniciativas y los requerimientos de recursos requeridos por TI, y cómo el uso de los recursos y el logro de los beneficios serán monitoreados y administrados. Los planes tácticos deben tener el detalle suficiente para permitir la definición de planes operativos. Administrar de forma activa los planes tácticos y las iniciativas de TI establecidas por medio del análisis de la cartera de proyectos y servicios. Esto requiere encontrar el equilibrio entre requerimientos y recursos, comparándolos con el logro de metas estratégicas, tácticas y los beneficios esperados, tomando las medidas necesarias en caso de desviaciones. Administrar el grupo de proyectos de TI de forma proactiva y el conjunto de programas de inversión de TI requerido para lograr objetivos estratégicos y específicos del Organismo por medio de la identificación, definición, evaluación, asignación de prioridades, selección, inicio, administración y control de los programas. Esto incluye: clarificar los resultados deseados, garantizar que los objetivos de los programas den soporte para alcanzar las metas establecidas, entender el alcance completo del esfuerzo requerido, definir una rendición de cuentas clara, asignar recursos y financiamiento y delegar autoridad. Administrar el valor de TI para garantizar que las inversiones en TI del Organismo contenga programas con casos de negocio sólidos. Reconocer que existen inversiones obligatorias, de sustento y discrecionales que difieren en complejidad y grado de libertad en cuanto a la asignación de fondos. Los servicios de TI se deben ejecutar contra acuerdos de niveles de servicios equitativos y exigibles. La 51 rendición de cuentas del logro de los beneficios y del control de los costos debe ser claramente asignada y monitoreada. Identificar en el Organismo las áreas que dependen de forma crítica de la TI. Mediar entre los imperativos de éstas y la tecnología, de tal modo que se puedan establecer prioridades concertadas. Evaluar el desempeño actual, el de los planes existentes y de los sistemas de información en términos de su contribución a los objetivos estratégicos del Organismo, su funcionalidad, su estabilidad, su complejidad, sus costos, sus fortalezas y debilidades. 6.1.2. Definir la arquitectura de información Establecer y mantener un modelo de información que facilite el desarrollo de aplicaciones y las actividades de soporte a la toma de decisiones, consistente con los planes de TI como se describen en el Plan Estratégico. El modelo facilita la creación, uso y compartición óptimas de la información por parte del Organismo de una manera que conserva la integridad y es flexible, funcional, rentable, oportuna, segura y tolerante a fallas. Mantener un diccionario de datos de la organización que incluya las reglas de sintaxis de datos. El diccionario facilita la compartición de elementos de datos entre las aplicaciones y los sistemas, fomenta un entendimiento común de datos entre los usuarios de TI y del Organismo, y previene la creación de elementos de datos incompatibles. Establecer un esquema de clasificación de datos que aplique a todo el Organismo, basado en la criticidad y sensibilidad de la información. Este esquema incluye detalles acerca de la propiedad de datos, la definición de niveles apropiados de seguridad y de controles de protección, como también una breve descripción de los requerimientos de retención y destrucción de datos, además de qué tan críticos y sensibles son. Se usa como base para aplicar controles como el control de acceso, archivo o encripción. 52 Definir e implantar procedimientos para garantizar la integridad y consistencia de todos los datos almacenados en formato electrónico, tales como bases de datos y archivos. 6.1.3. Determinar la dirección tecnológica Planear la dirección tecnológica. Analizar las tecnologías existentes y emergentes y planear cuál dirección tecnológica es la apropiada para materializar la estrategia de TI y la arquitectura de sistemas del Organismo. También identificar en el plan, qué tecnologías tienen el potencial de crear oportunidades de negocio. El plan debe abarcar la arquitectura de sistemas, la dirección tecnológica, las estrategias de migración y los aspectos de contingencia de los componentes de la infraestructura. Elaborar un Plan de infraestructura tecnológica. Crear y mantener un plan de infraestructura tecnológica que esté de acuerdo con los planes estratégicos y tácticos de TI. El plan se basa en la dirección tecnológica e incluye acuerdos para contingencias y orientación para la adquisición de recursos tecnológicos. También debe tomar en cuenta los cambios en el ambiente competitivo, las economías de escala en la obtención de equipo de sistemas de información, y la mejora en la interoperabilidad de las plataformas y las aplicaciones. Monitorear tendencias y regulaciones futuras. Establecer un proceso para monitorear las tendencias del sector/industria, tecnológicas, de infraestructura, legales y regulatorias. Incluir las consecuencias de estas tendencias en el desarrollo del plan de infraestructura tecnológica de TI. Establecer estándares tecnológicos. Proporcionar soluciones tecnológicas consistentes, efectivas y seguras para toda la organización, establecer un foro tecnológico para brindar directrices tecnológicas, asesoría sobre los productos de la infraestructura y guías sobre la selección de la tecnología, y medir el cumplimiento de estos estándares y directrices. Este foro impulsa los estándares y las prácticas tecnológicas con base a su importancia, riesgo y en el cumplimiento de requerimientos externos. 53 Establecer un consejo de arquitectura de TI que proporcione directrices sobre la arquitectura y asesoría sobre su aplicación y que verifique el cumplimiento. Esta entidad orienta el diseño de la arquitectura de TI garantizando que facilite la estrategia y tome en cuenta el cumplimiento regulatorio y los requerimientos de continuidad. Estos aspectos se relacionan con la arquitectura de la información 6.1.4. Definir los procesos, organización y relaciones de TI Ubicación organizacional de la función de TI. Ubicar a la función de TI dentro de la estructura organizacional general con un modelo supeditado a su importancia dentro del Organismo, en especial en función de la criticidad que representa para la estrategia del Organismo y el nivel de dependencia operativa. Estructura organizacional. Establecer una estructura organizacional de TI interna y externa que refleje las necesidades de la Organización. Además implementar un proceso para revisar la estructura organizacional de TI de forma periódica para ajustar los requerimientos de personal y las estrategias internas para satisfacer los objetivos esperados y las circunstancias cambiantes. Establecimiento de roles y responsabilidades. Definir y comunicar tanto los roles como las responsabilidades para el personal de TI y los usuarios que delimiten la autoridad entre el personal de TI y los usuarios finales. Definir las responsabilidades y la rendición de cuentas para alcanzar los objetivos estratégicos del Organismo. Responsabilidad del aseguramiento de calidad (QA) de TI. Asignar la responsabilidad para el desempeño de la función de QA. Asegurar que la ubicación organizacional, las responsabilidades y el tamaño del grupo de QA satisfacen los requerimientos del Organismo. Responsabilidad sobre el Riesgo, la Seguridad y el Cumplimiento. Establecer la propiedad y la responsabilidad de los riesgos relacionados con TI a un nivel apropiado. Definir y asignar roles críticos para administrar los riesgos de TI, incluyendo la responsabilidad específica de la seguridad de la información, la seguridad física y el cumplimiento. Establecer responsabilidades sobre la 54 administración del riesgo y la seguridad de toda la organización para manejar los problemas a nivel de todo el Organismo. Puede ser necesario asignar responsabilidades adicionales de administración de la seguridad a nivel de sistemas específicos para manejar problemas relacionados con seguridad. Obtener la posición de la alta dirección en relación a los niveles aceptables de riesgo de TI que se quieren asumir y la aprobación de cualquier riesgo residual. Propiedad de Datos y de Sistemas. Proporcionar al Organismo los procedimientos y herramientas que le permitan asumir sus responsabilidades de propiedad sobre los datos y los sistemas de información. Las áreas responsables, dueña de los datos y sistemas, deberán tomar decisiones sobre la clasificación de la información y cómo protegerlos. Implantar prácticas adecuadas de supervisión dentro de la función de TI para garantizar que los roles y las responsabilidades se ejerzan de forma apropiada. Evaluar si todo el personal cuenta con la suficiente autoridad para ejecutarlos y para revisar en general los indicadores clave de desempeño. Implantar una división de roles y responsabilidades que reduzca la posibilidad de que un solo individuo afecte un proceso crítico. La gerencia debe asegurar de que el personal realice sólo las tareas autorizadas, relevantes a sus puestos y posiciones respectivas. Evaluar los requerimientos de personal de forma regular o cuando existan cambios importantes en las necesidades estratégicas del Organismo, operativo o de TI para garantizar que la función de TI cuente con un número suficiente de personal competente, el entrenamiento cruzado-funcional, la rotación de puestos y las oportunidades de personal externo. Definir e identificar al personal clave de TI y minimizar la dependencia excesiva en ellos. Debe existir un plan para contactar al personal clave en caso de emergencia. Políticas y procedimientos para personal contratado. Definir e implantar políticas y procedimientos para controlar las actividades de los consultores u otro personal contratado por la función de TI. 55 Establecer y mantener una estructura óptima de enlace, comunicación y coordinación entre la función de TI y otras funciones dentro y fuera de ella, tales como el consejo directivo, ejecutivos, usuarios individuales, proveedores, oficiales de seguridad, gerentes de riesgo y los contratistas externos. Definir un marco de trabajo para el proceso de TI para ejecutar el plan estratégico de TI. Este marco incluye estructura y relaciones de procesos de TI, propiedad, medición del desempeño, mejoras, cumplimiento, metas de calidad y planes para alcanzarlas. Proporciona integración entre los procesos que son específicos para TI, administración de la cartera de proyectos del Organismo, y procesos de cambios de estrategia. El marco de trabajo de procesos de TI debe estar integrado en un sistema de administración de calidad y en un marco de trabajo de control interno. Establecer un comité estratégico de TI que deberá asegurar que el gobierno de TI, como parte del gobierno del Organismo, se maneja de forma adecuada, asesora sobre la dirección estratégica y revisa las inversiones principales. Establecer un comité directivo de TI compuesto por la gerencia ejecutiva, del sector interesado y de TI para: Determinar las prioridades de los programas de inversión de TI alineadas con la estrategia y prioridades de los objetivos estratégicos del Organismo. Dar seguimiento de los proyectos y resolver los conflictos de recursos. Monitorear los niveles y las mejoras del servicio. 6.1.5. Administrar la inversión en TI Establecer un marco de Administración Financiera para TI que impulse la presupuestación, con base en el grupo de proyectos de inversión en bienes y servicios. Comunicar los aspectos de costo y beneficio en los procesos de priorización de presupuestos y administración de costos. Implantar un proceso de toma de decisiones para dar prioridades a la asignación de recursos a TI contemplando operaciones, proyectos y mantenimiento, de manera tal de maximizar la contribución de TI y optimizar el retorno de inversión de los proyectos de inversión y otros servicios y activos de TI. 56 Establecer un proceso para elaborar y administrar un presupuesto que refleje las prioridades establecidas en los programas de inversión en TI, incluyendo los costos recurrentes de operar y mantener la infraestructura actual. Este debe dar soporte al desarrollo de un presupuesto general de TI y de presupuestos para programas individuales, con énfasis especial en los componentes de TI de esos programas. El proceso debe permitir la revisión, el refinamiento y la aprobación constantes del presupuesto general y de los presupuestos de programas individuales. Implantar un proceso de administración de costos que compare los costos reales con los presupuestados. Los costos se deben monitorear y reportar. Cuando existan desviaciones, éstas se deben identificar de forma oportuna y evaluar el impacto. Junto con el patrocinador del proyecto, se deberán tomar las medidas correctivas apropiadas y, en caso de ser necesario, el programa de inversión se deberá actualizar. Implantar un proceso de monitoreo de beneficios que permita medir la contribución esperada de TI a los resultados esperados, ya sea como un componente de programas de inversión en TI o como parte de un soporte operativo regular, que debe identificar, acordar, monitorear y reportar. Los reportes se deben revisar y, en donde existan oportunidades para mejorar la contribución de TI, se deben definir y tomar las medidas apropiadas. Siempre que los cambios en la contribución de TI tengan impacto directo en el programa o a otros proyectos relacionados, el programa de inversión deberá ser actualizado. Desarrollar un presupuesto por centro de costos. 6.1.6. Comunicar las aspiraciones y la dirección de la gerencia de TI Comunicación de los objetivos y la dirección de TI. Asegurar que el conocimiento y el entendimiento de los objetivos estratégicos del organismo y de TI se comunican a toda la organización. La información comunicada debe poseer una visión claramente articulada entre los objetivos de servicio, la seguridad, los controles internos, la calidad, el código de ética y conducta, políticas y procedimientos. Estos deben incluirse dentro de un programa de comunicación 57 continua, apoyado por la alta dirección con acciones. La dirección debe dar especial atención a comunicar la conciencia sobre que la seguridad de TI es responsabilidad de todos. Implantación de políticas de TI. Asegurarse de que las políticas de TI se implantan y comunican a todo el personal relevante de tal forma que estén incluidas y sean parte integral de las operaciones organizacionales. Ambiente de políticas y de control. Definir los elementos de un ambiente de control para TI incluyendo las expectativas/requerimientos respecto a la entrega de valor proveniente de las inversiones en TI, el nivel de tolerancia aceptado al riesgo, la integridad, los valores éticos, la competencia del personal, la rendición de cuentas y la responsabilidad. El ambiente de control se basa en una cultura que apoya la entrega de valor, mientras que al mismo tiempo administra riesgos significativos, fomenta la colaboración entre distintas áreas y el trabajo en equipo, promueve el cumplimiento y la mejora continua de procesos, y maneja las desviaciones (incluyendo las fallas) de forma adecuada. Riesgo Corporativo y Marco de Referencia de Control Interno de TI. Elaborar y dar mantenimiento a un marco de trabajo que establezca el enfoque de la organización hacia los riesgos y hacia el control interno. Este debe estar integrado por el marco de procesos de TI, el sistema de administración de calidad y debe cumplir los objetivos generales del Organismo. Debe tener como meta maximizar el éxito de la entrega de valor mientras minimiza los riesgos para los activos de información por medio de medidas preventivas, la identificación oportuna de irregularidades, la limitación de pérdidas y la recuperación oportuna de activos. Administración de políticas para TI. Elaborar y dar mantenimiento a un conjunto de políticas que apoyen la estrategia de TI. Estas políticas deben incluir el propósito, los roles y responsabilidades, los procesos de excepción y referencias a procedimientos, estándares y directrices. Las políticas deben incluir temas clave como calidad, seguridad, confidencialidad, controles internos y propiedad intelectual. Se deben revisar regularmente. 58 6.1.7. Administrar los recursos humanos de TI Reclutamiento y Retención del Personal. Asegurarse que los procesos de reclutamiento del personal de TI estén de acuerdo a las políticas y procedimientos generales del personal. La gerencia debe implementar procesos para garantizar que el Organismo cuente con una fuerza de trabajo posicionada de forma apropiada y que tenga las habilidades necesarias para alcanzar las metas del Organismo. Competencias del personal. Verificar de forma periódica que el personal tenga las habilidades para cumplir sus roles con base en su educación, entrenamiento y/o experiencia. Definir los requerimientos esenciales de habilidades para TI y verificar que se les proporcione actualizaciones, usando programas de calificación y certificación según sea el caso. Asignación de roles. Definir, monitorear y supervisar los marcos de trabajo para los roles, responsabilidades y retribuciones del personal, incluyendo el requisito de adherirse a las políticas y procedimientos administrativos, así como al código de ética y prácticas profesionales. Los términos y condiciones de empleo deben enfatizar la responsabilidad del empleado respecto a la seguridad de la información, al control interno y al cumplimiento regulatorio. El nivel de supervisión debe estar de acuerdo con la sensibilidad del puesto y el grado de responsabilidades asignadas. Entrenamiento del personal de TI. Proporcionar a los empleados de TI la orientación necesaria al momento de la contratación y entrenamiento continuo para conservar su conocimiento, aptitudes, habilidades, controles internos y conciencia sobre la seguridad, al nivel requerido para alcanzar las metas de la organización. Dependencia sobre los individuos. Minimizar la exposición de dependencias críticas sobre individuos clave por medio de la documentación y divulgación del conocimiento, como también la planeación de la sucesión y rotación de personal. Incluir verificaciones de antecedentes en el proceso de reclutamiento de TI para el personal que cubra funciones críticas. Este criterio también debe aplicarse a los contratistas y proveedores. 59 Evaluación del desempeño del empleado. Es necesario que las evaluaciones de desempeño se realicen periódicamente, comparando contra los objetivos individuales derivados de las metas del Organismo, estándares establecidos y responsabilidades específicas del puesto. Los empleados deben recibir adiestramiento sobre cómo desempeñarse y conducirse, según sea necesario. Cambios y culminación de trabajo. Tomar medidas respecto a los cambios en los puestos, en especial las culminaciones sea por renuncia o despido. Se debe realizar la transferencia del conocimiento, reasignar responsabilidades y eliminar los privilegios de acceso, de tal modo que los riesgos se minimicen y se garantice la continuidad de la función. 6.1.8. Administrar la calidad Se debe establecer un Sistema de Administración de la Calidad (SAC) que proporcione un enfoque estándar, formal y continuo, con respecto a la administración de la calidad, que esté alineado con los objetivos estratégicos del Organismo. El SAC identifica los requerimientos y los criterios de calidad, los procesos claves de TI, y su secuencia e interacción, así como las políticas, criterios y métodos para definir, detectar, corregir y prever las no conformidades. El SAC debe definir la estructura del Organismo para la administración de la calidad, cubriendo los roles, las tareas y las responsabilidades. Todas las áreas clave deben desarrollar sus planes de calidad de acuerdo a los criterios y políticas, y registran los datos. Los datos del SAC deben ser monitoreados y medidos para medir la efectividad y mejorarla cuando sea necesario. Se deben identificar y mantener estándares, procedimientos y prácticas para los procesos clave de TI de manera tal de orientar a la organización hacia el cumplimiento del SAC. Se deben usar las mejores prácticas como referencia al optimizar y adaptar las prácticas de calidad. del Organismo. Se deben adoptar y mantener estándares para todo desarrollo y adquisición que sigue el ciclo de vida de las aplicaciones, hasta el último entregable. Esto debe incluir la documentación de hitos clave con base en criterios de aprobación 60 acordados. Los temas a considerar incluyen estándares de codificación de software, normas de nomenclatura; formatos de archivos, estándares de diseño para esquemas y diccionario de datos; estándares para la interfaz de usuario; interoperabilidad (posibilidad de que los módulos de un sistema puedan ser reutilizados por otros); eficiencia de desempeño de sistemas; escalabilidad; estándares para desarrollo y pruebas; validación contra requerimientos; planes de pruebas; y pruebas unitarias, de regresión y de integración. La administración de la calidad debe enfocarse en los usuarios, al determinar sus requerimientos y alinearlos con los estándares y prácticas de TI. Se deben definir los roles y responsabilidades respecto a la resolución de conflictos entre el usuario/cliente y área de TI. Se debe elaborar y comunicar un plan global de calidad que promueva la mejora continua, de forma periódica a través de mediciones para monitorear el cumplimiento continuo del SAC, así como el valor que el SAC proporciona. La medición, el monitoreo y el registro de la información deben ser usados por el dueño del proceso para tomar las medidas correctivas y preventivas apropiadas. 6.1.9. Evaluar y administrar los riesgos de TI Se debe integrar el gobierno, la administración de riesgos y el marco de control de TI, al marco de trabajo de administración de riesgos del Organismo. Esto incluye la alineación con el nivel de tolerancia al riesgo del Organismo. Se debe establecer el contexto en el cual el marco de trabajo de evaluación de riesgos se aplique para garantizar resultados apropiados. Esto incluye la determinación del contexto interno y externo de cada evaluación de riesgos, la meta de la evaluación y los criterios contra los cuales éstos se evalúan. Se deben identificar todos aquellas amenazas y vulnerabilidades que tengan un impacto potencial sobre las metas o las operaciones del Organismo, aspectos de estratégicos, regulatorios, legales, tecnológicos, de recursos humanos y operativos. Determinar la naturaleza del impacto y dar mantenimiento a esta información. 61 Evaluar de forma recurrente la posibilidad e impacto de todos los riesgos identificados, usando métodos cualitativos y cuantitativos. La posibilidad e impacto asociados a los riesgos inherentes y residuales se debe determinar de forma individual. Identificar los propietarios de los riesgos y a los dueños de procesos afectados, y elaborar y mantener respuestas que garanticen que los controles y las medidas de seguridad mitigan la exposición de forma continua. La respuesta a los riesgos debe identificar estrategias tales como evitar, reducir, compartir o aceptar. Al elaborar la respuesta, considerar los costos y beneficios y seleccionar aquellas que limiten los riesgos residuales dentro de los niveles de tolerancia definidos. Mantenimiento y monitoreo de un plan de acción de riesgos. Asignar prioridades y planear las actividades de control a todos los niveles para implantar las respuestas a los riesgos, identificadas como necesarias, incluyendo la determinación de costos, beneficios y la responsabilidad de la ejecución. Buscar la aprobación para las acciones recomendadas y la aceptación de cualquier riesgo residual, y asegurarse de que las acciones comprometidas son propiedad del dueño o dueños de los procesos afectados. Monitorear la ejecución de los planes y reportar cualquier desviación a la alta dirección. 6.1.10. Administrar proyectos Preparar un plan de administración de la calidad que describa el sistema de calidad del proyecto y cómo será implantado. El plan debe ser revisado y acordado de manera formal por todas las partes interesadas para luego ser incorporado en el plan integrado del proyecto. Establecer un sistema de control de cambios para cada uno de ellos, de tal modo que todas las modificaciones a la línea base o indicadores al inicio del proyecto, como por ejemplo costos, cronograma, alcance y calidad, se revisen, aprueben e incorporen de manera apropiada al plan integrado, de acuerdo al marco de trabajo de gobierno del programa y del proyecto. 62 Identificar las tareas de aseguramiento requeridas para apoyar la acreditación de sistemas nuevos o modificados durante la planeación del proyecto e incluirlos en el plan integrado. Las tareas deben proporcionar la seguridad de que los controles internos y las características de seguridad satisfagan los requerimientos definidos. Medir el desempeño del proyecto contra los criterios clave tales como el alcance, los tiempos, la calidad, los costos o los riesgos; identificar las desviaciones con respecto al plan; evaluar su impacto; reportar los resultados a los interesados clave; y recomendar, implantar y monitorear las medidas correctivas, según sea requerido, de acuerdo con el marco de trabajo de gobierno del programa y del proyecto. Solicitar que al finalizar cada proyecto, los interesados se cercioren de que se hayan proporcionado los resultados y los beneficios esperados. Identificar y comunicar cualquier actividad sobresaliente requerida para alcanzar los resultados planeados del proyecto y los beneficios del programa, e identificar y documentar las lecciones aprendidas a ser usadas en futuros proyectos y programas. 6.2. Adquirir e implementar 6.2.1. Identificar soluciones automatizadas Se deben definir, identificar, dar prioridades, especificar, acordar y planificar el mantenimiento de los requerimientos técnicos y funcionales, de manera tal que se cubra el alcance completo de todas las iniciativas requeridas. Definir también los criterios de aceptación. Estas iniciativas deben incluir todos los cambios requeridos, dada la naturaleza del Organismo, de los procesos, de las aptitudes y habilidades del personal, su estructura organizacional y la tecnología de apoyo. Además debe contemplar las necesidades funcionales, la dirección tecnológica, el desempeño, el costo, la confiabilidad, la compatibilidad, la auditoría, la disponibilidad y continuidad, la ergonomía, la funcionalidad, la seguridad y la legislación vigente. Establecer procesos para garantizar y administrar la integridad, exactitud y la validez de los requerimientos, como base para el control de la adquisición y el 63 desarrollo continuo de sistemas. Estos requerimientos deben ser propiedad del patrocinador del proyecto. Reporte de análisis de riesgos. Identificar, documentar y analizar los riesgos asociados con los procesos como parte de los procesos de la Organización para el desarrollo de los requerimientos. Los riesgos incluyen las amenazas a la integridad, seguridad, disponibilidad y privacidad de los datos, así como el cumplimiento de las leyes y reglamentos. Estudio de factibilidad y formulación de cursos de acción alternativos. Desarrollar un estudio de factibilidad que examine la posibilidad de implementar los requerimientos. Debe identificar los cursos alternativos de acción para el software, hardware, servicios y habilidades que satisfagan los requerimientos establecidos, tanto funcionales como técnicos, y evaluar la factibilidad tecnológica y económica (costo potencial y análisis de beneficios) de cada uno de los cursos de acción identificados en el contexto de inversión en TI. Requerimientos, decisión de factibilidad y aprobación. Se debe asignar un patrocinador del proyecto que apruebe y autorice los requisitos tanto funcionales como técnicos, y los reportes del estudio de factibilidad en las etapas clave predeterminadas. El patrocinador del proyecto debería tener la decisión final con respecto a la elección de la solución y al enfoque de adquisición. 6.2.2. Adquirir o desarrollar y mantener software aplicativo Establecer una metodología de Ciclo de Vida de Desarrollo de Sistemas (CVDS) que contemple: Diseño de alto nivel. Traducir los requerimientos a una especificación de diseño de alto nivel para desarrollo de software, tomando en cuenta las directivas tecnológicas y la arquitectura de información dentro de la organización, y aprobar las especificaciones para garantizar que el diseño de alto nivel responde a los requerimientos. Diseño detallado. Preparar el diseño detallado y los requerimientos técnicos del software de aplicación. Definir el criterio de aceptación de los requerimientos para 64 garantizar que corresponden al diseño de alto nivel. Los conceptos a considerar incluyen, pero no se limitan a, definir y documentar los requerimientos de entrada de datos, definir interfaces, la interface de usuario, el diseño para la recopilación de datos fuente, la especificación de programa, definir y documentar los requerimientos de archivo, requerimientos de procesamiento, definir los requerimientos de salida, control y auditabilidad, seguridad y disponibilidad, y pruebas. Realizar una reevaluación para cuando se presenten discrepancias técnicas o lógicas significativas durante el desarrollo o mantenimiento. Control y auditabilidad de las aplicaciones. Asegurar que los controles se traduzcan correctamente de manera que el procesamiento sea exacto, completo, oportuno, aprobado y auditable. Los aspectos que se consideran especialmente son: mecanismos de autorización, integridad de la información, control de acceso, respaldo y diseño de pistas de auditoría. Seguridad y disponibilidad de las aplicaciones. Abordar la seguridad de las aplicaciones y los requerimientos de disponibilidad en respuesta a los riesgos identificados, de acuerdo con la clasificación de datos, la arquitectura de seguridad en la información de la organización y el perfil de riesgo. Los aspectos a considerar incluyen derechos de acceso y administración de privilegios, protección de información sensible en todas las etapas, autenticación e integridad de las transacciones y recuperación automática. Configuración e implantación de software aplicativo adquirido. Personalizar e implantar la funcionalidad automatizada adquirida con el uso de procedimientos de configuración, aceptación y prueba. Los aspectos a considerar incluyen el cumplimiento de los términos contractuales, la arquitectura de información del Organismo, las aplicaciones existentes y su interoperabilidad con estas, los sistemas de bases de datos, la eficiencia en el desempeño del sistema, la documentación y los manuales de usuario, integración y planes de prueba. Actualizaciones importantes en sistemas existentes. Seguir un proceso de desarrollo similar al de desarrollo de sistemas nuevos en el caso que se presenten 65 modificaciones importantes en los sistemas existentes, que resulten en un cambio significativo de los diseños y/o funcionalidad actuales. Los aspectos a considerar incluyen análisis de impacto, relación costo/beneficio y administración de requerimientos. Desarrollo de software aplicativo. Garantizar que la funcionalidad de automatización se desarrolla de acuerdo con las especificaciones de diseño, los estándares de desarrollo y documentación, y los requerimientos de calidad. Aprobar y autorizar cada etapa clave del proceso de desarrollo de software aplicativo, verificando la finalización de las revisiones de funcionalidad, desempeño y calidad. Los aspectos a considerar incluyen aprobar las especificaciones de diseño que satisfacen los requerimientos funcionales y técnicos, y las solicitudes de cambio; verificar la compatibilidad con los sistemas existentes. Además, garantizar que se identifican y consideran todos los aspectos legales y contractuales para el software aplicativo que desarrollan terceros. Aseguramiento de la calidad del software. Desarrollar, implantar los recursos y ejecutar un plan de aseguramiento de la calidad del software, para cumplir con los estándares especificados en la definición de los requerimientos y en las políticas y procedimientos de calidad del Organismo. Los aspectos a considerar incluyen especificar el criterio de calidad y los procesos de validación y verificación, revisión de algoritmos, código fuente y pruebas. Administración de los requerimientos de aplicaciones. Garantizar que durante el diseño, desarrollo e implantación, se da seguimiento al estado de los requerimientos particulares (incluyendo todos los requerimientos rechazados), y que las modificaciones se aprueban a través de un proceso establecido de administración de cambios. Mantenimiento de software aplicativo. Desarrollar una estrategia y un plan para el mantenimiento y pase a producción de software de aplicaciones. Los aspectos a considerar incluyen implantación planeada y controlada, planeación de recursos, reparación de defectos de programa y corrección de fallas, pequeñas mejoras, 66 mantenimiento de documentación, cambios de emergencia, interdependencia con otras aplicaciones e infraestructura, estrategias de actualización, condiciones contractuales tales como aspectos de soporte y actualizaciones, revisión periódica de acuerdo a las necesidades del Organismo, riegos y requerimientos de seguridad. 6.2.3. Adquirir y mantener infraestructura tecnológica Plan de adquisición de infraestructura tecnológica. Generar un plan para adquirir, implantar y mantener la infraestructura tecnológica que satisfaga los requerimientos funcionales y técnicos, y que esté de acuerdo con la dirección tecnológica de la organización. El plan debe considerar extensiones futuras para adiciones de capacidad, costos de transición, riesgos tecnológicos y vida útil de la inversión para actualizaciones de tecnología. Evaluar los costos, la viabilidad del proveedor y del producto al añadir nueva capacidad técnica. Protección y disponibilidad del recurso de infraestructura. Implantar medidas de control interno, seguridad y auditabilidad durante la configuración, integración y mantenimiento del hardware y del software de la infraestructura para proteger los recursos y garantizar su disponibilidad e integridad. Se deben definir y comprender claramente las responsabilidades al utilizar componentes de infraestructura sensitivos por todos aquellos que los desarrollan e integran. Se debe monitorear y evaluar su uso. Mantenimiento de la infraestructura. Desarrollar una estrategia y un plan de mantenimiento de la infraestructura y garantizar que se controlan los cambios, de acuerdo con el procedimiento de administración de cambios. Incluir una revisión periódica contra las necesidades del Organismo, administración de parches y estrategias de actualización, riesgos, evaluación de vulnerabilidades y requerimientos de seguridad. Ambiente de prueba de factibilidad. Establecer el ambiente de desarrollo y de pruebas para soportar la efectividad y eficiencia de las pruebas de factibilidad e integración de aplicaciones e infraestructura, en las primeras fases del proceso de adquisición y desarrollo. Se debe considerar la funcionalidad, la configuración de 67 hardware y software, pruebas de integración y desempeño, migración entre ambientes, control de la versiones, datos y herramientas de prueba y seguridad. 6.2.4. Facilitar la operación y el uso Marco para la documentación de sistemas. Desarrollar un plan para identificar y documentar todos los aspectos técnicos, la capacidad de operación y los niveles de servicio requeridos, de manera que todos los interesados puedan elaborar procedimientos de administración, de usuario y de operación. Este marco debe aplicarse cada vez que se produzca una actualización de aplicaciones y/o infraestructura. Transferencia de conocimiento. Transferir el conocimiento a niveles gerenciales para permitirles tomar posesión del sistema y los datos, ejercer la responsabilidad por la entrega y calidad del servicio, del control interno y de los procesos administrativos de la aplicación. La transferencia de conocimiento incluye la aprobación de acceso, administración de privilegios, segregación de tareas, controles automatizados, respaldo/recuperación, seguridad física y archivo de la documentación fuente. Transferencia de conocimiento a usuarios finales. Transferencia de conocimientos para permitir que los usuarios finales utilicen con efectividad y eficiencia la aplicación como apoyo a los procesos del Organismo. La transferencia de conocimiento incluye el desarrollo de un plan de capacitación que abarque al entrenamiento inicial y al continuo, así como el desarrollo de habilidades, manuales de usuario, manuales de procedimiento, ayuda en línea, asistencia a usuarios, identificación del usuario clave, y evaluación. Transferencia de conocimiento al personal de operaciones y soporte. Transferir el conocimiento y las habilidades para permitir al personal de soporte técnico y de operaciones que entregue, apoye y mantenga la aplicación y la infraestructura asociada de manera efectiva y eficiente de acuerdo a los niveles de servicio requeridos. La transferencia del conocimiento debe incluir al entrenamiento inicial 68 y continuo, al desarrollo de las habilidades, los manuales de operación, los manuales de procedimientos y escenarios de atención al usuario. 6.2.5. Adquirir recursos de TI Control de adquisición. Desarrollar y seguir un conjunto de procedimientos y estándares consistente con el proceso general y la estrategia de adquisiciones de la organización, para garantizar que la compra de infraestructura, instalaciones, hardware, software y servicios relacionados con TI, satisfagan los requerimientos del Organismo. Administración de contratos con proveedores. Formular un procedimiento para establecer, modificar y concluir contratos que apliquen a todos los proveedores. Debe cubrir, como mínimo, responsabilidades y obligaciones legales, financieras, organizacionales, documentales, de desempeño, de seguridad de propiedad intelectual y de conclusión, así como obligaciones y cláusulas de penalización por incumplimiento cuando no cumplan los acuerdos de niveles de servicios previamente establecidos. Todos los contratos y las modificaciones a contratos las deben revisar asesores legales. Selección de proveedores. Seleccionar proveedores mediante una práctica justa y formal para garantizar la elección del mejor basado en los requerimientos que se han desarrollado. Adquisición de software. Garantizar que se protegen los intereses del Organismo en todos los acuerdos contractuales de adquisición. Incluir y reforzar los derechos y obligaciones de todas las partes en los términos contractuales para la adquisición de software. Estos derechos y obligaciones pueden incluir la propiedad y licencia de propiedad intelectual, mantenimiento, garantías, procedimientos de arbitraje, condiciones para la actualización y aspectos de conveniencia que incluyen seguridad, custodia y derechos de acceso. Adquisición de recursos de desarrollo. Garantizar la protección de los intereses de la organización en todos los acuerdos contractuales de adquisición. Incluir y hacer cumplir los derechos y obligaciones de todas las partes en los términos 69 contractuales para la adquisición de recursos de desarrollo. Estos derechos y obligaciones pueden incluir la propiedad y licenciamiento de propiedad intelectual, aspectos de conveniencia incluyendo metodologías de desarrollo, lenguajes, pruebas, procesos de administración de calidad que comprenden los criterios de desempeño requeridos, su correspondiente revisión, términos de pago, garantías, procedimientos de arbitraje, administración de recursos humanos y cumplimiento con las políticas de la organización. Adquisición de infraestructura, instalaciones y servicios relacionados. Incluir y hacer cumplir los derechos y obligaciones de todas las partes en los términos contractuales, que comprendan los criterios de aceptación para la adquisición de infraestructura, instalaciones y servicios relacionados. Estos derechos y obligaciones pueden abarcar los niveles de servicio, procedimientos de mantenimiento, controles de acceso, seguridad, revisión de desempeño, términos de pago y procedimientos de arbitraje. 6.2.6. Administrar cambios Establecer procedimientos de administración de cambios formales para manejar de manera estándar todas las solicitudes (incluyendo mantenimiento y actualizaciones) para cambios a aplicaciones, procedimientos, procesos, parámetros de sistema y servicio, y las plataformas fundamentales. Evaluación de impacto, priorización y autorización. Garantizar que todas las solicitudes de cambio se evalúan de una manera estructurada en cuanto a impactos en los sistemas y su funcionalidad. Esta evaluación deberá incluir categorización y priorización. Previo a la migración hacia producción, los interesados correspondientes deberán establecer autorizaciones formales. Cambios de emergencia. Establecer un proceso para definir, plantear, evaluar y autorizar los cambios de emergencia que no sigan el proceso de cambio establecido. La documentación y pruebas podrán realizarse, después de la implantación del cambio. En todos los casos, se deberán dejar pistas de auditoría para su posterior revisión. 70 Seguimiento y reporte del estado del cambio. Establecer un sistema de seguimiento y reporte para mantener actualizados a los solicitantes y a los interesados relevantes del cambio, acerca del estado del mismo. Cierre y documentación del cambio. Siempre que se implantan cambios al sistema, actualizar el o los sistemas asociados, la documentación de usuario y procedimientos correspondientes. Establecer un proceso de revisión para garantizar su implantación completa. 6.2.7. Instalar y acreditar soluciones y cambios Entrenamiento. Entrenar al personal de los departamentos de usuario afectados y al grupo de operaciones de la función de TI de acuerdo con el plan definido de entrenamiento e implantación y a los materiales asociados, como parte de cada proyecto de desarrollo, implantación o modificación de sistemas de información. Plan de pruebas. Establecer un plan de pruebas y obtener la aprobación de los principales involucrados. Dicho plan se debe basar en los estándares de toda la organización y definir roles, responsabilidades y criterios de éxito. Debe considerar: requerimientos de entrenamiento, instalación o actualización de un ambiente de pruebas definido, definir tipos de prueba, los casos de prueba, manejo y corrección de errores y aprobación formal. Plan de implantación. Establecer un plan de implantación y obtener la aprobación de los principales involucrados. Debe definir el diseño de versiones, procedimientos de instalación, manejo de incidentes, controles de distribución, almacenamiento de software, revisión de la versión y documentación de cambios. Deberá también incluir medidas de respaldo y vuelta atrás. Ambiente de prueba. Establecer un ambiente de prueba independiente. Este ambiente debe asemejarse al ambiente de producción para permitir pruebas acertadas. Se deben tener presentes los procedimientos para garantizar que los datos utilizados en el ambiente de prueba sean representativos. Proporcionar medidas adecuadas para prevenir la divulgación de datos sensibles. La documentación de los resultados de las pruebas se debe archivar. 71 Conversión de sistema y datos. Garantizar que los métodos de desarrollo del Organismo contemplen para todos los proyectos de desarrollo, implantación o modificación, todos los elementos necesarios, tales como hardware, software, datos de transacciones, archivos maestros, interfases con otros sistemas, procedimientos, documentación de sistemas, etc., y sean convertidos del viejo al nuevo sistema de acuerdo con un plan preestablecido. Se debe desarrollar y mantener pistas de auditoría de los resultados previos y posteriores a la conversión. Los propietarios del sistema deben verificar detalladamente la transición exitosa. Prueba de cambios. Garantizar que se prueban los cambios de acuerdo con un plan de aceptación definido y en base en una evaluación de impacto y de recursos que incluya el dimensionamiento del desempeño en un ambiente separado de prueba, por parte de un grupo de prueba independiente de los desarrolladores antes de comenzar su uso en el ambiente de operación regular. Las pruebas paralelas o piloto se consideran parte del plan. Los controles de seguridad se prueban y evalúan antes de la liberación, de manera que se pueda certificar la efectividad de la seguridad. Los planes de respaldo/vuelta atrás se deben desarrollar y probar antes de transferir el cambio a producción. Prueba final de aceptación. Garantizar que los procedimientos proporcionan una evaluación formal y la aprobación de los resultados de prueba por parte de la gerencia de los departamentos afectados del usuario y la función de TI. Las pruebas deberán cubrir todos los componentes del sistema de información (ejemplo, software aplicativo, instalaciones, procedimientos de tecnología y usuario) y garantizar que los requerimientos de seguridad de la información se satisfacen para todos los componentes. Los datos de prueba se deben salvar para propósitos de pistas de auditoría y para pruebas futuras. Transferencia a producción. Implantar procedimientos formales para controlar la transferencia del sistema desde el ambiente de desarrollo al de pruebas, de acuerdo con el plan de implantación. La gerencia debe requerir que se obtenga la autorización del propietario del sistema antes del pasaje al entorno de producción. 72 Liberación de software. Garantizar que la liberación del software se regula con procedimientos formales que aseguren la autorización, acondicionamiento, pruebas de regresión, distribución, transferencia de control, seguimiento, procedimientos de respaldo y notificación de usuario. Distribución del sistema. Establecer procedimientos de control para asegurar la distribución oportuna y correcta, y la actualización de los componentes aprobados de la configuración. Esto implica controles de integridad; segregación de funciones entre los que construyen, prueban y operan; y adecuadas pistas de auditoría de todas las actividades. Registro y rastreo de cambios. Monitorear los cambios a sistemas aplicativos, procedimientos, procesos, sistemas y a las plataformas. Revisión posterior a la implantación. Establecer procedimientos una revisión posterior a la implantación del sistema para evaluar y reportar si el cambio satisfizo los requerimientos del usuario y entregó los beneficios esperados. 6.3. Entregar y dar soporte 6.3.1. Definir y administrar los niveles de servicio Definir un marco de trabajo que brinde un proceso formal de administración de niveles de servicio entre el usuario y el prestador de servicio. Este marco debe incluir procesos para la creación de requerimientos, definiciones, acuerdos de niveles de servicio, de niveles de operación y sus correspondientes fuentes de financiamiento. Definir la estructura organizacional para la administración del nivel de servicio, incluyendo los roles, tareas y responsabilidades de los proveedores externos e internos y de los usuarios. Organizar y almacenar de manera centralizada la definición base de los servicios de TI dependiendo de sus características y de los requerimientos del caso, por medio de la implantación de un enfoque de catálogo de servicios. Definir y acordar convenios de niveles de servicio para todos los procesos críticos de TI con base en los requerimientos del usuario y las capacidades de TI. Deben 73 incluir los compromisos del usuario, los requerimientos de soporte, métricas cualitativas y cuantitativas para la medición del servicio firmado por los interesados, en caso de aplicar, los arreglos comerciales y de financiamiento, y los roles y responsabilidades, incluyendo la revisión del acuerdo. Los puntos a considerar son disponibilidad, confiabilidad, desempeño, capacidad de crecimiento, niveles de soporte, planeación de continuidad, seguridad y restricciones de demanda. Asegurar que los acuerdos de niveles de operación expliquen cómo serán entregados técnicamente los servicios para soportar el (los) acuerdo(s) de los niveles pactados de manera óptima. Monitorear continuamente los criterios de desempeño especificados para el nivel de servicio. Emitir reportes periódicos sobre el cumplimiento de los niveles de servicio en un formato que sea entendible para los interesados. Analizar las estadísticas de monitoreo para identificar tendencias positivas y negativas tanto de servicios individuales como de los servicios en conjunto. Revisar regularmente con los proveedores internos y externos los acuerdos de niveles de servicio y los contratos de apoyo, para asegurar que son efectivos, que están actualizados y que se han tomado en cuenta los cambios en los requerimientos. 6.3.2. Administrar servicios de terceros Identificar todos los servicios de los proveedores y catalogarlos de acuerdo con el tipo de proveedor, la importancia y la criticidad. Mantener documentación formal de las relaciones técnicas y organizacionales incluyendo los roles y responsabilidades, metas, expectativas, entregables esperados y credenciales de los representantes de estos proveedores. Formalizar el proceso de administración de relaciones con proveedores por cada uno de ellos. 74 Debe existir un responsable que coordine la relación entre los proveedores y los usuarios para asegurar la calidad y la transparencia (por ejemplo, a través de acuerdos de niveles de servicio). Identificar y mitigar los riesgos relacionados con la habilidad de los proveedores para mantener una efectiva entrega de servicios de forma segura y eficiente sobre una base de continuidad. Asegurar que los contratos están de acuerdo con los estándares del tema y de conformidad con los requerimientos legales y regulatorios. Establecer un proceso para monitorear la prestación del servicio para asegurar que el proveedor está cumpliendo con los requerimientos actuales del Organismo apegándose de manera continua a los acuerdos del contrato y a los convenios de niveles de servicio. Verificando que el desempeño es competitivo respecto a los proveedores alternativos y a las condiciones del mercado. 6.3.3. Administrar el desempeño y la capacidad Establecer un proceso de planeación para la revisión del desempeño y la capacidad de los recursos de TI, que asegure su disponibilidad, con costos justificables, para procesar las cargas de trabajo acordadas tal como se determina en los acuerdos de nivel de servicio. Revisar la capacidad y desempeño actual de los recursos de TI en intervalos regulares para determinar si existe suficiente capacidad y desempeño para prestar los servicios con base en los niveles de servicio acordados. Llevar a cabo un pronóstico de desempeño y capacidad de los recursos de TI en intervalos regulares para minimizar el riesgo de interrupciones del servicio originadas por falta de capacidad o degradación del desempeño. Identificar el exceso de capacidad para una posible redistribución. Identificar las tendencias de las cargas de trabajo y determinar los pronósticos que serán parte de los planes de capacidad y de desempeño. 75 Brindar la capacidad y desempeño requeridos tomando en cuenta aspectos como cargas de trabajo normales, contingencias, requerimientos de almacenamiento y ciclos de vida de los recursos de TI. La gerencia de TI debe garantizar que los planes de contingencia consideren de forma apropiada la disponibilidad, capacidad y desempeño de los recursos individuales de TI. Monitorear continuamente el desempeño y la capacidad de los recursos de TI. Mantener y poner a punto el desempeño actual dentro de TI y atender temas como elasticidad, contingencia, cargas de trabajo actuales y proyectadas, planes de almacenamiento y adquisición de recursos. Reportar al Organismo la disponibilidad del servicio prestado como se requiere en los acuerdos de nivel de servicio. Acompañar todos los reportes de excepción con recomendaciones para llevar a cabo acciones correctivas. 6.3.4. Garantizar la continuidad del servicio Desarrollar un marco de trabajo de continuidad de TI para soportar los servicios a lo largo de toda la organización. El objetivo de este marco es identificar las debilidades en la infraestructura de TI, y guiar el desarrollo de los planes de recuperación de desastres y de contingencias. Debe tomar en cuenta la estructura del Organismo, la cobertura de roles, las tareas y las responsabilidades de los proveedores de servicios internos y externos, su administración y sus usuarios; así como las reglas y estructuras para documentar, probar y ejecutar la recuperación de desastres y los planes de contingencia de TI. El plan debe también considerar puntos tales como la identificación de recursos críticos, el monitoreo y reporte de la disponibilidad de recursos críticos, el procesamiento alternativo y los principios de respaldo y recuperación. Desarrollar planes de continuidad de TI con base en el marco de trabajo, diseñados para reducir el impacto de una interrupción mayor de las funciones y los procesos clave del Organismo. Estos deben considerar requerimientos de resistencia a los 76 incidentes, procesamiento alternativo, y capacidad de recuperación de todos los servicios críticos de TI. También deben cubrir los lineamientos de uso, los roles y responsabilidades, los procedimientos, los procesos de comunicación y el enfoque de pruebas. Centrar la atención en los puntos determinados como los más críticos en el plan de continuidad de TI, para fortalecerlos y establecer prioridades en situaciones de recuperación. Evitar las demoras para recuperar los puntos menos críticos y asegurar que la respuesta y la recuperación están alineadas con las necesidades prioritarias del Organismo, verificando también que los costos se mantienen a un nivel aceptable y se cumple con los requerimientos regulatorios y contractuales. Considerar los requerimientos de resistencia, respuesta y recuperación para diferentes niveles de prioridad, por ejemplo, de una a cuatro horas, de cuatro a 24 horas, más de 24 horas y para periodos críticos de operación del ente. La gerencia de TI debe definir y ejecutar procedimientos de control de cambios para asegurar que el plan de continuidad de TI se mantenga actualizado y que refleje de manera continua los requerimientos actuales del Organismo. Es esencial que los cambios en los procedimientos y las responsabilidades sean comunicados de forma clara y oportuna. Probar el plan de continuidad de TI de forma regular para asegurar que los sistemas pueden ser recuperados de forma efectiva, que las deficiencias son atendidas y que el plan permanece aplicable. Preparar en forma cuidadosa documentación, reporte de los resultados de las pruebas y, de acuerdo con estos, la implementación de un plan de acción. Considerar el alcance de las pruebas de recuperación en aplicaciones individuales, en escenarios de pruebas integrados, en pruebas de punta a punta y en pruebas integradas con el o los proveedores que pudieran estar implicados. Asegurar que todas las partes involucradas reciban sesiones de capacitación de forma regular respecto a los procesos, sus roles y responsabilidades en caso de 77 incidente o desastre. Verificar e incrementar el entrenamiento de acuerdo con los resultados de las pruebas de contingencia. Determinar que existe una estrategia de distribución definida y administrada para asegurar que los planes se distribuyan de manera apropiada y segura. Que estén disponibles entre las partes involucradas y autorizadas cuando y donde se requiera. Se debe prestar atención en hacerlos accesibles bajo cualquier escenario de desastre. Planear las acciones a tomar durante el período en que TI se está recuperando y reanudando los servicios. Esto puede representar la activación de sitios de respaldo, el inicio de procesamiento alternativo, la comunicación a usuarios y a los interesados, realizar procedimientos de reanudación, etc. Asegurar que los responsables entienden los tiempos de recuperación de TI y las inversiones necesarias en tecnología para soportar las necesidades de recuperación y reanudación del servicio. Almacenar fuera de las instalaciones todos los medios de respaldo, documentación y otros recursos de TI críticos, necesarios para la recuperación de TI y para los planes de continuidad. El contenido de los respaldos a almacenar debe determinarse en conjunto entre los responsables de los procesos sustantivos y el personal de TI. La administración del sitio de almacenamiento externo a las instalaciones, debe apegarse a la política de clasificación de datos y a las prácticas de almacenamiento de datos del Organismo. La gerencia de TI debe asegurar que los acuerdos con sitios externos sean evaluados periódicamente, al menos una vez por año, respecto al contenido, a la protección ambiental y a la seguridad. Asegurarse de la compatibilidad del hardware y del software para poder recuperar los datos archivados. Periódicamente probar y renovar los datos archivados. 78 Una vez lograda una exitosa reanudación de las funciones de TI después de un desastre, determinar si la gerencia de TI ha establecido procedimientos para valorar lo adecuado del plan y actualizarlo en consecuencia. La dirección del Organismo debe entender y aprobar los riesgos aceptados. 6.3.5. Garantizar la Seguridad de los Sistemas Administrar la seguridad de TI al nivel más apropiado dentro del Organismo, de manera que las acciones de administración de la seguridad estén en línea con los requerimientos de la organización. Trasladar los requerimientos de información del Organismo, la configuración de TI, los planes de acción del riesgo de la información y la cultura sobre la seguridad en la información a un plan global de seguridad de TI. Implementar el plan global de seguridad de TI mediante políticas y procedimientos de seguridad en conjunto con inversiones apropiadas en servicios, personal, software y hardware. Comunicar las políticas y procedimientos de seguridad a los interesados y a los usuarios. Todos los usuarios (internos, externos y temporales) y su actividad en sistemas de TI (aplicación, operación del sistema, desarrollo y mantenimiento) deben ser identificables de manera única. Los derechos de acceso del usuario a sistemas y datos deben estar alineados con necesidades de los procesos del Organismo, definidos, documentados y con requerimientos de trabajo. Los derechos de acceso del usuario deben ser solicitados por su gerencia, aprobados por el responsable del sistema e implementado por la persona responsable de la seguridad. Las identidades del usuario y los derechos de acceso deben mantenerse en un repositorio central. 79 Se debe implementar, mantener y actualizar medidas técnicas y procedimientos, para establecer la identificación, realizar la autenticación y habilitar los derechos de acceso de los usuarios. Garantizar que la solicitud, establecimiento, emisión, suspensión, modificación y cierre de cuentas de usuario y de los privilegios relacionados, sean tomados en cuenta por el sector responsable de las cuentas de los usuarios. Debe incluirse un procedimiento que describa al responsable de los datos o del sistema para que otorgue los privilegios de acceso. Estos procedimientos deben aplicar para todos los usuarios, incluyendo administradores (usuarios privilegiados), usuarios externos e internos, para casos normales y de emergencia. Los derechos y obligaciones relacionados al acceso a los sistemas e información del Organismo deben acordarse contractualmente y en forma fehaciente para todos los tipos de usuarios. La gerencia debe llevar a cabo una revisión regular de todas las cuentas y los privilegios asociados. Garantizar que la implementación de la seguridad en TI sea probada y monitoreada de forma proactiva. La seguridad en TI debe ser acreditada periódicamente para garantizar que se mantiene el nivel de seguridad aprobado. Debe existir una función de ingreso al sistema y de monitoreo que permita la detección oportuna de actividades inusuales o anormales que pueden requerir atención. Garantizar que las características de los posibles incidentes de seguridad sean definidas y comunicadas de forma clara, de manera que los problemas de seguridad sean atendidos de forma apropiada por medio del proceso de administración de problemas o incidentes. Incluir una descripción de lo que se considera un incidente de seguridad y su nivel de impacto. Definir un número limitado de niveles de impacto para cada incidente, e identificar las acciones específicas requeridas y las personas que necesitan ser notificadas. 80 Garantizar que la tecnología importante relacionada con la seguridad no sea susceptible de sabotaje y que la documentación de seguridad no se divulgue de forma innecesaria. Determinar que las políticas y procedimientos para organizar la generación, cambio, revocación, destrucción, distribución, certificación, almacenamiento, captura, uso y archivo de llaves criptográficas estén implantadas, para garantizar su protección contra modificaciones y divulgación no autorizadas. Garantizar que se cuente con medidas de prevención, detección y corrección (en especial contar con parches de seguridad y control de virus actualizados) a lo largo de toda la organización para proteger a los sistemas de información y a la tecnología contra software malicioso (virus, gusanos, spyware, correo basura, software fraudulento desarrollado internamente, etc.). Garantizar que se utilizan técnicas de seguridad y procedimientos de administración asociados (por ejemplo, firewalls, dispositivos de seguridad, segmentación de redes, y detección de intrusos) para autorizar acceso y controlar los flujos de información desde y hacia las redes. Garantizar que las transacciones de datos sensibles sean intercambiadas solamente a través de una ruta o medio confiable con controles para brindar autenticidad de contenido, prueba de envío y recepción, y no repudio del origen. Deberá procurarse la protección de los datos sensibles, incluso frente a los administradores de las bases de datos. 6.3.6. Identificar y asignar costos Desarrollar un modelo orientado a los centros de costos. Identificar todos los costos de TI para soportar un modelo de costos transparente. Vincular los servicios de TI a los procesos del Organismo de forma que cada temática pueda identificar los niveles de costo de los servicios asociados. Registrar y asignar los costos actuales de acuerdo con el modelo de costos definido. Analizar y reportar las variaciones entre los presupuestos y los costos actuales de acuerdo con los sistemas de medición financiera del Organismo. 81 Definir, con base en la característica del servicio, un modelo de costos que incluya costos directos, indirectos y fijos de los servicios, y que ayude al cálculo de montos de reintegros por servicio. Alinear el modelo de costos con los procedimientos de contabilización de la organización. El modelo de costos de TI debe garantizar que los cargos por servicios sean identificables, medibles y predecibles por parte de los usuarios para propiciar el adecuado uso de recursos. La gerencia del usuario debe poder verificar el uso actual y los cargos de los servicios. Revisar y comparar de forma regular lo apropiado del modelo de costos/recargos para mantener su relevancia para el tema en evolución y para las actividades de TI. 6.3.7. Educación y capacitación de los usuarios Establecer y actualizar de forma regular un programa de entrenamiento para cada grupo objetivo de empleados, que incluya: o Estrategias y requerimientos actuales y futuros del ente. o Valores corporativos (valores éticos, cultura de control y seguridad, etc.). o Implementación de nuevo software e infraestructura de TI (paquetes y aplicaciones). o Habilidades, perfiles de competencias y certificaciones actuales y/o credenciales necesarias. o Formas de capacitación (por ejemplo, aula, web), tamaño del grupo objetivo, accesibilidad y tiempo. Identificar, en base en las necesidades de entrenamiento: a los grupos objetivo y a sus miembros, a los mecanismos de capacitación más eficientes, a maestros, instructores y consejeros. Designar instructores y organizar el entrenamiento con tiempo suficiente. Debe tomarse nota del registro (incluyendo los prerrequisitos), la asistencia, y las evaluaciones de desempeño. 82 Al finalizar el entrenamiento, evaluar el contenido del entrenamiento respecto a la relevancia, calidad, efectividad, percepción y retención del conocimiento, costo y valor. Los resultados de esta evaluación deben contribuir a la definición futura de los planes de estudio y de las sesiones de entrenamiento. 6.3.8. Administrar la mesa de servicio y los incidentes Establecer la función de mesa de servicio, la cual es la conexión del usuario con TI, para registrar, comunicar, atender y analizar todas las llamadas, incidentes reportados, requerimientos de servicio y solicitudes de información. Establecer procedimientos de monitoreo y escalamiento basados en los niveles de servicio acordados, que permitan clasificar y priorizar cualquier problema reportado como incidente, solicitud de servicio o solicitud de información. Medir la satisfacción del usuario final respecto a la calidad de la mesa de servicios y de los servicios de TI. Establecer una función y sistema que permita el registro y rastreo de llamadas, incidentes, solicitudes de servicio y necesidades de información. Debe trabajar estrechamente con los procesos de administración de incidentes, administración de problemas, administración de cambios, administración de capacidad y administración de disponibilidad. Clasificar los incidentes de acuerdo al tema y a la prioridad del servicio, derivarlo al equipo de administración de problemas apropiado y mantener informados a los usuarios sobre el estado de sus consultas. Establecer procedimientos de mesa de servicios de manera que los incidentes que no puedan resolverse de forma inmediata sean escalados apropiadamente de acuerdo con los límites acordados en el acuerdo de nivel de servicios y, si es adecuado, brindar soluciones alternas. Garantizar que la asignación de incidentes y el monitoreo del ciclo de vida permanecen en la mesa de servicios, independientemente de qué grupo de TI esté trabajando en las actividades de resolución. 83 Establecer procedimientos para el monitoreo puntual de la resolución de consultas de los usuarios. Cuando se resuelve el incidente, la mesa de servicios debe registrar la causa raíz, si la conoce, y confirmar que la acción tomada fue acordada con el usuario. Emitir reportes de la actividad de la mesa de servicios para permitir a la gerencia medir el desempeño del servicio y los tiempos de respuesta, así como para identificar tendencias de problemas recurrentes de manera que el servicio pueda mejorarse de forma continua. 6.3.9. Administrar la configuración Establecer una herramienta de soporte y un repositorio central que contenga toda la información relevante sobre los elementos de configuración. Monitorear y registrar todos los activos y sus cambios. Mantener una línea base de los elementos de la configuración para todos los sistemas y servicios como punto de comprobación al cual volver tras un cambio. Establecer procedimientos para soportar la gestión que permitan seguir el rastro de todos los cambios al repositorio de configuración. Revisar periódicamente los datos de configuración para verificar y confirmar su integridad actual e histórica. Revisar periódicamente si el software instalado está de acuerdo con la política de uso de software para identificar software personal o no licenciado o cualquier otra instancia de software en exceso del contrato de licenciamiento actual. Reportar, actuar y corregir errores y desviaciones. Incorporar todo los equipos al dominio de la AFIP. 6.3.10. Administración de problemas Garantizar una adecuada administración de problemas e incidentes. Implementar procesos para reportar y clasificar problemas que han sido identificados como parte de la administración de incidentes. Categorizar los problemas de manera apropiada en grupos o dominios relacionados (por ejemplo, hardware, software, software de soporte). Estos grupos pueden 84 coincidir con las responsabilidades organizacionales o con los grupos de usuarios y son la base para asignar los problemas al personal de soporte. El sistema de administración de problemas debe mantener pistas de auditoría adecuadas que permitan rastrear, analizar y determinar la causa raíz de todos los problemas reportados considerando: o Todos los elementos de configuración asociados. o Problemas e incidentes sobresalientes. o Errores conocidos y probables. o Seguimiento de las tendencias de los problemas. Identificar e iniciar soluciones sostenibles indicando la causa raíz. Disponer de un procedimiento para cerrar registros de problemas ya sea después de confirmar la eliminación exitosa del error conocido o después de acordar con el responsable del tema cómo manejar el problema de manera alternativa. 6.3.11. Administración de datos Establecer mecanismos para garantizar que el proceso reciba los documentos originales correctos, que se procese toda la información recibida, que se preparen y entreguen todos los reportes de salida requeridos y que las necesidades de reinicio y reproceso estén soportadas. Definir e implementar procedimientos para el archivo y almacenamiento de los datos, de manera tal que estos permanezcan accesibles y utilizables. Definir e implementar procedimientos para mantener un inventario de medios de almacenamiento en sitio y garantizar su integridad y su uso. Definir e implementar procedimientos para prevenir el acceso a datos sensitivos y al software desde equipos o medios una vez que son eliminados o transferidos para otro uso. Definir e implementar procedimientos de respaldo y restauración de los sistemas, datos y configuraciones que estén alineados con los requerimientos de la misión y con el plan de continuidad. 85 Verificar el cumplimiento de los procedimientos de respaldo y verificar la capacidad y el tiempo requerido para tener una restauración completa y exitosa. Probar los medios de respaldo y el proceso de restauración. Establecer mecanismos para identificar y aplicar requerimientos de seguridad aplicables a la recepción, procesamiento, almacenamiento físico y entrega de información y de mensajes sensitivos que incluyen registros físicos, transmisiones de datos y cualquier información almacenada fuera del sitio. 6.3.12. Administración de instalaciones Definir y seleccionar los centros de datos físicos para los equipos de TI que soportan la estrategia de tecnología ligada a la estrategia del Organismo. Debe tomar en cuenta el riesgo asociado con desastres naturales y causados por el hombre, considerando las leyes y regulaciones correspondientes. Definir e implementar medidas de seguridad físicas alineadas con los requerimientos del ente. Establecer las responsabilidades sobre el monitoreo y los procedimientos de reporte y de resolución de incidentes de seguridad física. Definir, implementar y monitorear procedimientos para otorgar, limitar, registrar y revocar el acceso a locales, edificios y áreas de acuerdo con las necesidades del Organismo, incluyendo las emergencias. Diseñar e implementar medidas de protección contra factores ambientales. Deben instalarse dispositivos y equipo especializado para monitorear y controlar el ambiente. Administrar las instalaciones, incluyendo el equipo de comunicaciones y de suministro de energía, de acuerdo con las leyes y los reglamentos, los requerimientos técnicos y del ente, las especificaciones del proveedor y los lineamientos de seguridad y salud. Disponer un sitio alternativo de procesamiento. Llevar control de las visitas a la sala cofre. 86 Incorporar a un plan de contingencia los procedimientos que mitiguen los daños que puedan presentarse en situaciones de exposición al riesgo 6.3.13. Administración de operaciones Definir, implementar y mantener procedimientos estándar para operaciones de TI y garantizar que el personal de operaciones está familiarizado con todas las tareas de operación relativas a ellos. Organizar la programación de trabajos, procesos y tareas en la secuencia más eficiente, maximizando el desempeño y la utilización para cumplir con los requerimientos del tema. Implementar procedimientos para identificar, investigar y aprobar las salidas de los programas estándar establecidos. Definir e implementar procedimientos para monitorear la infraestructura de TI y los eventos relacionados. Garantizar que en los registros de operación se almacena suficiente información cronológica para permitir la reconstrucción, revisión y análisis de las secuencias de tiempo de las operaciones y de las otras actividades que soportan o que están vinculadas a estas. Establecer resguardos físicos, prácticas de registro y administración de inventarios adecuados sobre los activos de TI más sensitivos tales como formularios, impresoras de uso especial o dispositivos de seguridad. Definir e implementar procedimientos para garantizar el mantenimiento oportuno de la infraestructura para reducir la frecuencia y el impacto de las fallas o disminución del desempeño. 6.4. Monitorear y evaluar 6.4.1. Monitorear y evaluar el desempeño de TI Enfoque del Monitoreo. Establecer un marco de trabajo de monitoreo general que abarque a todas las áreas y un enfoque que definan el alcance, la metodología y el proceso a seguir para medir la solución y la entrega de servicios de TI. Monitorear 87 la contribución de TI a los objetivos estratégicos del Organismo. Integrar el marco de trabajo con el sistema de administración del desempeño organizacional. Definición y recolección de datos de monitoreo. Trabajar con las áreas decisorias para definir un conjunto de objetivos de desempeño. Definir referencias con las que comparar los objetivos, e identificar datos disponibles a recolectar para medirlos. Se deben establecer procesos para recolectar información oportuna y precisa para reportar el avance contra las metas. Método de monitoreo. Implantar un método de monitoreo que brinde una visión sucinta y completa del desempeño de TI, acorde al sistema de monitoreo del Organismo. Evaluación del desempeño. Comparar en forma periódica el desempeño contra las metas, realizar análisis de la causa raíz e iniciar medidas correctivas para resolver las causas subyacentes cuando hay desvíos. Reportes al consejo directivo y a ejecutivos. Proporcionar reportes administrativos para ser revisados por la alta dirección sobre el avance de la organización hacia metas identificadas, específicamente en términos del desempeño. Éstos deben incluir el grado en el que se han alcanzado los objetivos planeados, los resultados obtenidos, las metas de desempeño alcanzadas y los riesgos mitigados. Durante la revisión, se debe identificar cualquier desviación respecto al desempeño esperado e iniciar y reportar las medidas de administración adecuadas. Acciones correctivas. Identificar e iniciar medidas correctivas basadas en el monitoreo del desempeño, evaluación y reportes. Esto incluye el seguimiento de todo el monitoreo, de los reportes y de las evaluaciones con: o Revisión, negociación y establecimiento de respuestas de administración. o Asignación de responsabilidades por la corrección. o Rastreo de los resultados de las acciones comprometidas. 88 6.4.2. Monitorear y evaluar el control interno Monitoreo del marco de trabajo de control interno. Monitorear de forma continua, comparar y mejorar el ambiente de control de TI y el marco de trabajo de control de TI para satisfacer los objetivos del Organismo. Monitorear y evaluar la eficiencia y efectividad de los controles internos de revisión de la gerencia de TI. Identificar las excepciones de control, y analizar e identificar sus causas raíz subyacentes. Escalar las excepciones de control y reportar a los interesados apropiadamente. Establecer acciones correctivas necesarias. Control de auto-evaluación. Evaluar la completitud y efectividad de los controles de gerencia sobre los procesos, políticas y contratos de TI por medio de un programa continuo de auto-evaluación. Aseguramiento del control interno. Obtener, según sea necesario, aseguramiento adicional de la completitud y efectividad de los controles internos por medio de revisiones de terceros. Control interno para terceros. Evaluar el estado de los controles internos de los proveedores de servicios externos. Confirmar que los proveedores de servicios externos cumplen con los requerimientos legales y regulatorios y obligaciones contractuales. Acciones correctivas. Identificar, iniciar, rastrear e implementar acciones correctivas derivadas de los controles de evaluación y los informes. 6.4.3. Garantizar el cumplimiento con requerimientos externos Identificar los requerimientos de las leyes, regulaciones y cumplimientos contractuales. Identificar, sobre una base continua, leyes, regulaciones, y otros requerimientos externos que se deben de cumplir para incorporar en las políticas, estándares, procedimientos y metodologías de TI de la organización. Optimizar la respuesta a requerimientos externos. Revisar y ajustar las políticas, estándares, procedimientos y metodologías de TI para garantizar que los requisitos legales, regulatorios y contractuales son direccionados y comunicados. 89 Evaluación del cumplimiento con requerimientos externos. Confirmar el cumplimiento de políticas, estándares, procedimientos y metodologías de TI con requerimientos legales y regulatorios. Aseguramiento positivo del cumplimiento. Obtener y reportar garantía de cumplimiento y adhesión a todas las políticas internas derivadas de directivas internas o requerimientos legales externos, regulatorios o contractuales, confirmando que se ha tomado cualquier acción correctiva para resolver cualquier brecha de cumplimiento por el dueño responsable del proceso de forma oportuna. Reportes integrados. Integrar los reportes de TI sobre requerimientos legales, regulatorios y contractuales con documentos similares provenientes de otras funciones del Organismo. 6.4.4. Proporcionar gobierno de TI Establecimiento de un marco de gobierno de TI. Definir, establecer y alinear el marco de gobierno de TI con la visión completa del entorno de control y Gobierno Corporativo. Basar el marco de trabajo en un adecuado proceso de TI y modelo de control. Proporcionar la rendición de cuentas y prácticas inequívocas para evitar la pérdida del control interno. Confirmar que el marco de gobierno de TI asegura el cumplimiento de las leyes y regulaciones y que está alineado a la estrategia y objetivos del Organismo. Informar del estado y cuestiones de gobierno de TI. Alineamiento estratégico. Facilitar el entendimiento de la alta gerencia sobre temas estratégicos de TI tales como el rol de TI, características propias y capacidades de la tecnología. Garantizar que existe un entendimiento compartido entre las altas gerencias y la función de TI sobre la contribución potencial de TI a los objetivos estratégicos del Organismo. Trabajar con el consejo directivo para definir e implementar organismos de gobierno, tales como un comité estratégico de TI, para brindar una orientación a la gerencia respecto a TI, garantizando así que tanto la estrategia como los objetivos se distribuyan hacia las unidades operativas y hacia las unidades de TI. 90 Entrega de valor. Administrar los programas de inversión con TI, así como otros activos y servicios de TI, para asegurar que ofrezcan el mayor valor posible para apoyar la estrategia y los objetivos del Organismo. Asegurarse de que los resultados esperados de las inversiones habilitadas por TI y el alcance completo del esfuerzo requerido para lograr esos resultados esté bien entendido y que los aprueben los interesados, que los activos y las inversiones se administren a lo largo del ciclo de vida económico, y que se lleve a cabo una administración activa del logro de los beneficios, tales como la contribución a nuevos servicios, ganancias de eficiencia y un mejor grado de reacción a los requerimientos. Implementar un enfoque disciplinado de la administración de los programas de inversión. Administración de recursos. Revisar inversión, uso y asignación de los activos de TI por medio de evaluaciones periódicas de las iniciativas y operaciones para asegurar recursos y alineamiento apropiados con los objetivos estratégicos y los imperativos actuales y futuros. Administración de riesgos. Trabajar con el máximo nivel para definir el nivel de riesgo de TI aceptable por el Organismo y obtener garantía razonable que las prácticas de administración de riesgos de TI son apropiadas para asegurar que el riesgo actual de TI no excede el riesgo aceptado por la dirección. Introducir las responsabilidades de administración de riesgos en la organización, asegurando que el desarrollo de proyectos y TI regularmente evalúan y reportan riesgos relacionados con TI y su impacto y que la posición de los riesgos de TI del Organismo es entendida por los interesados. Medición del desempeño. Confirmar que los objetivos de TI se han conseguido o excedido, o que el progreso hacia las metas de TI cumple las expectativas. Donde los objetivos confirmados no se han alcanzado o el progreso no es el esperado, revisar las acciones correctivas. Informar a dirección los grupos de proyectos relevantes, programas y desempeños de TI, soportados por informes para permitir a la alta dirección revisar el progreso de la empresa hacia las metas identificadas. 91 Aseguramiento independiente. Garantizar de forma independiente (interna o externa) la conformidad de TI con la legislación y regulación relevante; las políticas del Organismo, estándares y procedimientos; prácticas generalmente aceptadas; y la efectividad y eficiencia del desempeño de TI. 7. Conclusiones El proyecto de auditoría estuvo enfocado en el área correspondiente a la Dirección General Impositiva, por lo que el presente proyecto no fue una auditoría de seguimiento al aprobado por Resolución 165 del 2004. De todas maneras, dada la existencia de sectores que proveen servicios informáticos tanto a la dirección auditada como a la Dirección General de Aduana y a la Dirección Nacional de Seguridad Social, quedaron pocas áreas sin relevar. En este contexto pudo observarse una evolución del Organismo en lo atinente a tecnología de la información en sintonía con las recomendaciones que figuran en el informe del año 2004. Para el estudio realizado la madurez de la TI en el Organismo se encuentra entre los niveles Repetible y Proceso definido.(ver Anexo I) Se evidencia que el proceso de integración de las tres Direcciones Generales sustantivas (Impositiva, Aduana y Seguridad Social), se encuentra todavía inconcluso, por lo que se presentan los siguientes inconvenientes: Convivencia de distintas modalidades de contratación y convenios colectivos de trabajo, generando inconvenientes administrativos y funcionales en las áreas de TI que prestan servicios a distintas Direcciones Generales. Casos en que se depende de individuos claves en tareas sensitivas. Variedad de plataformas de hardware y software que generan redundancia de información y exceso de carga para su mantenimiento y actualización. Además, la gestión de TI carece de una visión general e integradora, que se evidencia con la ausencia de: Un plan estratégico de TI, con sus correspondientes planes tácticos, alineados con el Plan Estratégico de la Organización. 92 Un plan de Aseguramiento de la Calidad, que permita medir la eficacia y la eficiencia de los servicios brindados por TI a los objetivos estratégicos del Organismo. Un marco de trabajo de Administración de Proyectos centralizado que permita administrar el conjunto de proyectos vigentes y futuros en un ambiente controlado. Un marco de trabajo de Administración de Riesgos, que permita gestionarlos con su correspondiente formalización del curso de acción a tomar en caso de presencia de cada evento, el riesgo residual o el riesgo asumido, si lo hubiere. Integración entre las Direcciones de Capacitación y las Direcciones de TI. Un plan de Contingencia que garantice la continuidad del servicio. Es necesario que existan alternativas de procesamiento para el caso de colapso del centro de cómputos principal. Un diccionario de datos único para todo el Organismo. Acuerdos de nivel de servicio definidos para los convenios que implican intercambio de datos con otros organismos. Finalmente, existe un problema funcional con áreas que prestan servicios de TI en forma transversal a distintas direcciones y que tienen el mismo nivel que las áreas usuarias, dificultando, por lo tanto, la aplicación de las directivas que generan. 8. LUGAR Y FECHA BUENOS AIRES, Marzo 2013 9. FIRMA 93 ANEXO I 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. El organismo 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 otros organismos. 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. 94 ANEXO II Gráficos de brecha para los niveles de madurez de los objetivos de control considerados. 95 96 Nivel de madurez promedio en Planear y Organizar: 2.10 97 Nivel de madurez en Adquirir e Implementar: 2.50 98 Nivel de madurez promedio en Entregar y Dar Soporte: 3.00 99 Nivel de madurez promedio en Monitorear y Evaluar: 2.50 ANEXO III Estimación de los Niveles de Riesgo para los requerimientos de la información según los procesos informáticos considerados Los veloces cambios que caracterizan a la tecnología informática obligan a optimizar la gestión de los riesgos inherentes. Las misiones y funciones críticas de los organismos dependen en forma creciente de los sistemas de tecnología de la información, 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 34 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 siguientes requerimientos que debe satisfacer la información dentro de un organismo para permitirle cumplir con sus misiones y funciones: Eficacia: Que la información sea relevante y pertinente para la misión del ente, así como a que su entrega sea oportuna, correcta, consistente y utilizable. Eficiencia: La provisión de información a través de la utilización óptima (más productiva y económica) de recursos. Confidencialidad: La protección de información sensible contra divulgación no autorizada. Integridad: La precisión y suficiencia de la información, así como a su validez de acuerdo con los valores y expectativas del organismo. Disponibilidad: La disponibilidad de la información cuando ésta es requerida para cumplir con las misiones del organismo, ahora y en el futuro. También se refiere a la salvaguarda de los recursos necesarios y capacidades asociadas. 100 Cumplimiento: Cumplimiento de aquellas leyes, regulaciones y acuerdos contractuales a los que el organismo está sujeto. Confiabilidad: La provisión de información apropiada a la administración para operar la entidad y para ejercer sus responsabilidades de reportes financieros y de cumplimiento. En los 34 casos se indica dentro de las observaciones qué requerimientos son afectados en forma primaria y secundaria por el objetivo de control (ver tabla). El objeto de este anexo es brindar parámetros cuantificables que permitan establecer un Tablero de Control para conocer los problemas con mayor riesgo y al mismo tiempo controlar las mejoras futuras 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 0 y 1 (0 representa la situación más segura y 1 la más insegura). El proceso de cálculo parte de la base de que el riesgo es directamente proporcional al impacto (definido como 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%). La probabilidad de ocurrencia está directamente vinculada a la calidad del control que se realiza, y este 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: 101 Tabla de incidencia de los criterios de la información en cada uno de los procesos analizados (P: primaria, S: secundaria) 102 ANEXO IV Gráficos de los niveles de riesgo de cada uno de los requerimientos de la información para los 34 objetivos de control considerados y su promedio general. 103 104 105 106 107 108 109 110 111 ANEXO V - Análisis de la Vista 4.1. Planificar y organizar 4.1.1 Definir un plan estratégico para TI Objetivo de control: Se requiere una planeación estratégica de Tecnología de la Información (TI) para administrar y dirigir todos los recursos de TI de acuerdo con los objetivos estratégicos del Organismo y las prioridades. La función de TI y los participantes del negocio son responsables de garantizar que se materialice el valor óptimo de los proyectos y servicios. El plan estratégico debe mejorar el entendimiento de los interesados clave respecto a las oportunidades y limitaciones de TI, evaluar el desempeño actual y aclarar el nivel de inversión requerido. La estrategia de negocio y las prioridades se deben reflejar en los proyectos de inversión y deben ser ejecutadas por los planes tácticos de TI, los cuales establecen objetivos, planes y tareas específicas, entendidas y aceptadas tanto por el negocio como por TI. Este objetivo de control afecta, primariamente: la efectividad y en forma secundaria: la eficiencia Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Repetible. La planeación estratégica de TI se comparte con la gerencia correspondiente según se necesite. La actualización de los planes de TI ocurre como respuesta a las solicitudes de la dirección. Las decisiones estratégicas se toman proyecto por proyecto, sin ser consistentes con una estrategia global del Organismo. Los riesgos y beneficios al usuario, resultado de decisiones estratégicas importantes, se reconocen de forma intuitiva. Observaciones: La normativa vigente (Anexo VI – Nota 1) exige la existencia de un Plan de Gestión Anual que deberá cumplir el Administrador Federal de Ingresos Públicos. Indicando además cómo y cuándo se controlará su cumplimiento y las penalidades para el caso en que ello no ocurra. 112 Para el período analizado por esta auditoría, no existía un Plan Estratégico de TI formalizado, alineado con el Plan Estratégico del Organismo aunque existen iniciativas, relacionadas con la infraestructura, incluidas en este último. Al cierre de los trabajos de campo está en etapa de revisión y aprobación final el Plan Estratégico de TI del presente año. Aclaraciones y/o comentarios del área responsable: Se comparte parcialmente lo observado. La Subdirección General de Planificación ha revisado el proyecto de Plan Estratégico de TI que fuera conocido por la AGN, señalando que el Plan Estratégico es Institucional. Por lo tanto sugirió que, alineado con el mismo, se apruebe un Plan Táctico de TI, el que cubre desde el año 2012 hasta el año 2015. El mismo ha sido enviado a la citada Subdirección General para la formalización final de su aprobación. Comentario de AGN: Tal como se menciona en la respuesta del organismo, el Plan Estratégico de TI y los planes tácticos que lo sustentan, no se encontraba formalmente aprobado al momento de la auditoria. Por lo tanto se mantienen las observaciones previas. Las mejoras a realizar se evaluarán en una próxima auditoría. 4.1.2 Definir la arquitectura de información Objetivo de control: La función de los sistemas de información debe crear y actualizar de forma regular un modelo de información y definir los sistemas apropiados para optimizar el uso de esta información. Esto incluye el desarrollo de un diccionario corporativo de datos que contiene las reglas de sintaxis de los datos del Organismo, el esquema de clasificación de datos y los niveles de seguridad. Este proceso mejora la calidad de la toma de decisiones gerenciales asegurándose que se proporciona información confiable y segura, y permite racionalizar los recursos de los sistemas de información para igualarse con las estrategias del Organismo. Este proceso de TI también es necesario para incrementar la responsabilidad sobre la integridad y seguridad de los datos y para mejorar la efectividad y control de la información compartida a lo largo de las aplicaciones y de las entidades. Este objetivo de control afecta, primariamente: la eficiencia la integridad 113 y en forma secundaria: la efectividad la confidencialidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Repetible. Existe un proceso de arquitectura de información y procedimientos similares, aunque intuitivos e informales, que se siguen por distintos individuos dentro de la organización. Las personas obtienen sus habilidades al construir la arquitectura de información por medio de experiencia práctica y la aplicación repetida de técnicas. Los requerimientos tácticos impulsan el desarrollo de los componentes de la arquitectura de la información por parte de los individuos. Observaciones: No existe un diccionario de datos de la organización ni un procedimiento formalizado que obligue a la progresiva constitución del mismo. Tampoco existe un modelo de datos del Organismo. Queda a criterio de cada sector del Organismo la administración de la información, por lo cual se es proclive a generar redundancia de datos. No existe un esquema de clasificación de datos basado en la criticidad y sensibilidad la información. Se está trabajando en la homogeneización de los múltiples entornos de trabajo, producto de la fusión de los distintos organismos originales en la actual AFIP. Existen algunas iniciativas como el Padrón Único de Contribuyentes (PUC), el Sistema Único de Parámetros de AFIP (SUPA), el Repositorio Único de Declaraciones Juradas (RUCD) o Repositorio de Documentos Internos (RUCDI) que tienen un uso común para todas las aplicaciones del Organismo. Aclaraciones y/o comentarios del área responsable: Si bien en el momento de la Auditoria se mencionó que se encontraba en homologación un sistema que actúa como diccionario de datos, el 1 ° de enero de 2013 se puso en producción un servicio interactivo, al que se accede a través del SUA (Sistema Único de Autenticación), denominado Clasidat cuyo objetivo es la documentación, descripción y clasificación de la Información estructurada en bases de datos. Este servicio fue desarrollado para cumplir con la IG N° 5/12 (AFIP) la cual trata sobre 114 la Clasificación de la Información Tal como norma la mencionada IG, las áreas definidoras de sistemas y procesos de información -en forma conjunta con las áreas que desarrollan los mismos-, utilizarán Clasidat para identificar cada instancia de base de datos, las tablas que las componen y sus campos, indicando tanto su descripción como su criticidad. Comentario de AGN: Se mantienen las observaciones. Para el período auditado, no se encontraba vigente la IG N° 5/12 (AFIP) ni la implementación del sistema “Clasidat”. Las mejoras expresadas se evaluarán en una próxima auditoría. 4.1.3 Determinar la dirección tecnológica Objetivo de control: La función de servicios de información debe determinar la dirección tecnológica para dar soporte a los objetivos de la organización. Esto requiere de la creación de un plan de infraestructura tecnológica y de un consejo de arquitectura que establezca y administre expectativas realistas y claras de lo que la tecnología puede ofrecer en términos de productos, servicios y mecanismos de aplicación. El plan se debe actualizar de forma regular y debe abarcar aspectos tales como arquitectura de sistemas, dirección tecnológica, planes de adquisición, estándares, estrategias de migración y contingencias. Esto permite mejorar los tiempos de reacción manteniendo entornos competitivos, mejorar la economía de escala en los sistemas de información utilizados por el personal o para la toma de decisiones, como también en interoperabilidad entre las plataformas y las aplicaciones. Este objetivo de control afecta, primariamente: la efectividad la eficiencia Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Definido. La gerencia está consciente de la importancia del plan de infraestructura tecnológica. El proceso para su planificación es sólido. Existe un plan de definido, documentado y bien difundido, aunque se aplica de forma inconsistente. La orientación de la infraestructura tecnológica incluye el entendimiento con la alineación de la estrategia del Organismo. Los proveedores clave se seleccionan en base a su 115 entendimiento de la tecnología a largo plazo y de los planes de desarrollo de productos, de forma consistente con la dirección tecnológica del Organismo. Observaciones: La Dirección de Infraestructura Tecnológica actualiza anualmente el Plan de Infraestructura y ha desarrollado un sistema que permite el seguimiento de proyectos, facilita la ejecución de los procesos y la realización de controles con el propósito de optimizar la gestión del área. Sin embargo, la ausencia de planes estratégicos a nivel de la Subdirección General de Sistemas y Telecomunicaciones, para el período auditado, no permite establecer la dirección tecnológica. Se siguen procesos intuitivos y reactivos basados en un trabajo sobre tendencias del mercado y posibles necesidades futuras, tanto para establecer el mantenimiento de la infraestructura como su crecimiento. Las áreas de desarrollo de sistemas están poco involucradas en la definición de la dirección tecnológica. Aclaraciones y/o comentarios del área responsable: No se comparte la observación ya que la dirección tecnológica de la AFIP ha sido señalada en los respectivos planes estratégicos. Desde hace años la estrategia está planteada hacia sistemas abiertos, basados en servicios WEB, interactivos con los contribuyentes y usuarios internos. La Estructura Orgánico Funcional de la Subdirección General de Sistemas y Telecomunicaciones cuenta con un área de TI denominada Dirección de Infraestructura Tecnológica que atiende los aspectos inherentes en la materia. Las áreas de desarrollo van adecuando y migrando los sistemas en uso en la medida de las respectivas posibilidades, lo que origina un diferente grado de madurez en este aspecto. Comentario de AGN: Se mantiene la observación. Los planes de gestión anuales, pertenecen a la Dirección de Infraestructura tecnológica. Falta un plan del más alto nivel que defina los objetivos estratégicos de TI que involucre a todas las direcciones. 4.1.4 Definir los procesos, organización y relaciones de TI Objetivo de control: Una organización de TI se debe definir tomando en cuenta los requerimientos de personal, funciones, delegación, autoridad, roles, responsabilidades y supervisión. La organización estará inserta en un marco de trabajo de procesos de TI que asegura la transparencia y el control, así como el involucramiento de los altos ejecutivos de nivel decisorio. Un comité estratégico debe garantizar la vigilancia del consejo directivo 116 sobre TI, y uno o más comités administrativos, en los cuales participan tanto los sectores operativos como TI, deben determinar las prioridades de los recursos de TI alineados con las necesidades del Organismo. Deben existir procesos, políticas administrativas y procedimientos para todas las funciones, con atención específica en el control, el aseguramiento de la calidad, la administración de riesgos, la seguridad de la información, la propiedad de datos y de sistemas y la segregación de tareas. Para garantizar el soporte oportuno de los requerimientos, TI se debe involucrar en los procesos importantes de decisión. Este objetivo de control afecta, primariamente: la efectividad la eficiencia Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Definido. Existen roles y responsabilidades definidos para la organización de TI y para terceros. La organización de TI se desarrolla, documenta, comunica y se alinea con la estrategia de TI. Se define el ambiente de control interno. Se formulan las relaciones con terceros, incluyendo los comités de dirección, auditoría interna y administración de proveedores. La organización de TI está funcionalmente completa. Existen definiciones de las funciones a ser realizadas por parte del personal de TI y las que deben realizar los usuarios. Los requerimientos esenciales de personal de TI y experiencia están definidos y satisfechos. Existe una definición formal de las relaciones con los usuarios y con terceros. La división de roles y responsabilidades está definida e implantada. Observaciones: Existe normativa que aprueba la estructura, define responsabilidades y roles para cada perfil hasta el nivel de división. (Anexo VI – Nota 2) Falta segregación de funciones a los niveles inferiores, lo que provoca que las definiciones para el personal subalterno sean difusas y poco precisas. Se depende de individuos clave para responsabilidades específicas. Existe una matriz de perfiles de puestos, agrupados por cada especialización, con las competencias técnicas requeridas para cubrirlo. 117 Algunas áreas como las relativas a la administración de riesgos y aseguramiento de la calidad no se encuentran contempladas en el organigrama. La política utilizada para la incorporación de personal provoca que en algunas áreas exista dependencia crítica de individuos clave por falta de agentes especializados. Esto también limita el intercambio de conocimientos, el planeamiento de la sucesión y la posibilidad de respaldarse o reemplazarse mutuamente. A esto se agrega que existe personal contratado realizando tareas relevantes. La ubicación del Departamento de Seguridad Informática dependiendo de la Dirección de Infraestructura no es la ideal, ya que debería encontrarse en un nivel superior. Aclaraciones y/o comentarios del área responsable: No se comparte lo observado en cuanto a que falta segregación de funciones a los niveles inferiores, lo que provoca que las definiciones para el personal subalterno sean difusas y poco precisas, toda vez que existen secciones y oficinas debajo de las Divisiones con acciones y tareas definidas por Disposiciones emitidas por el Subdirector General de Sistemas y Telecomunicaciones. Se comparte parcialmente la observación referida a la inexistencia de un área encargada del aseguramiento de la calidad. Al respecto se informa que cada área de desarrollo que depende de esta Subdirección General tiene expresas funciones de control de calidad y se encuentra reflejada estructuralmente. Comentario de AGN: Se mantiene la observación. Se han detectado casos de falta de segregación de funciones, entre ellos, las áreas de desarrollo, donde faltan definir niveles inferiores de la estructura actual para permitir una mejor separación de roles y responsabilidades. 4.1.5 Administrar la inversión en TI Objetivo de control: Establecer y mantener un marco de trabajo para administrar los programas de inversión en TI que abarquen costos, beneficios y prioridades dentro del presupuesto. Trabajar con los interesados para identificar y controlar los costos y beneficios totales dentro del contexto de los planes estratégicos y tácticos de TI, y tomar medidas correctivas según sean necesarias. El proceso fomenta la sociedad entre TI y los interesados, facilita el uso efectivo y eficiente de recursos de TI, y brinda transparencia y responsabilidad dentro 118 del costo total de la propiedad, la materialización de los beneficios y el retorno sobre las inversiones en TI. Este objetivo de control afecta, primariamente: la efectividad la eficiencia y en forma secundaria: la confiabilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Repetible. Existe un entendimiento implícito de la necesidad de seleccionar y presupuestar las inversiones en TI. La necesidad de un proceso de selección y presupuesto se da a conocer a los interesados. El cumplimiento depende de la iniciativa de individuos dentro de la organización. Surgen técnicas comunes para desarrollar componentes del presupuesto de TI. Se toman decisiones presupuestales reactivas y tácticas. Observaciones: Existe normativa (Anexo VI – Nota 3) que establece el marco general del sistema presupuestario. Un área coordinadora elabora, con participación de las Áreas Responsables, un anteproyecto de Plan de Gestión que contendrá las principales líneas de acción y actividades previstas para el año siguiente sobre la base de los lineamientos del Plan Estratégico de AFIP. Además, la SDG SIT quedó comprendida por el Régimen Económico Financiero vigente para las Direcciones Regionales Impositivas y Aduaneras, quedando en manos de la Subdirección General de Administración Financiera la determinación de qué contrataciones se efectuarán en forma centralizada. (Anexo VI – Nota 4) No se ha establecido formalmente un marco de Administración Financiera de TI para elaborar y administrar un presupuesto que refleje las prioridades establecidas en los programas de inversión, la administración de costos y los beneficios esperados que permita medir la contribución de TI a los objetivos estratégicos del Organismo. Existen iniciativas aisladas en algunas direcciones pero no se ha formalizado un procedimiento de trabajo común a toda la SDG SIT. 119 Las áreas de Desarrollo no contemplan en la metodología de ciclo de vida de desarrollo de sistemas, un marco de administración presupuestaria que comprenda cálculos de costos y beneficios esperados de los desarrollos, imputaciones por centro de costos y análisis comparativo entre lo presupuestado y lo efectivamente gastado. Aclaraciones y/o comentarios del área responsable: Se comparte la observación referida a que las áreas de desarrollo no contemplan en la metodología de ciclo de vida de desarrollo de sistemas, un marco de administración presupuestaria que comprenda cálculos de costos y beneficios esperados de los desarrollos. Al respecto se informa que se analizará la manera de implementar la asignación de costos en las áreas de desarrollo. No se comparte la observación referida a que no se ha establecido formalmente un marco de administración financiera de TI para elaborar y administrar un presupuesto que refleje las prioridades establecidas en los programas de inversión, la administración de costos y los beneficios esperados. Al respecto se informa que anualmente se confecciona una solicitud de presupuesto, el cual es asignado total o parcialmente de acuerdo a las políticas y prioridades establecidas por la Administración Federal, con independencia de atender los imprevistos y urgencias propios de la gestión del año. Comentario de AGN: Se mantienen las observaciones. De acuerdo con la información suministrada a esta auditoría, se reconoce la existencia de un marco de administración financiera del organismo, pero en relación a la SDG-SIT, éste es incompleto, ya que sólo cubre temas de infraestructura. La falta del marco presupuestario (incluyendo cálculo de costos y beneficios esperados) de las áreas de desarrollo y mantenimiento de aplicaciones, puede impactar en las planificaciones referidas a toda la subdirección. 4.1.6 Comunicar las aspiraciones y la dirección de la gerencia Objetivo de control: La dirección debe elaborar un marco de trabajo de control organizacional para TI, y definir y comunicar las políticas. Un programa de comunicación continua se debe implantar para articular la misión, los objetivos de servicio, las políticas y procedimientos aprobados y apoyados por la dirección. La comunicación apoya el logro de los objetivos de TI y asegura la concientización y el entendimiento de los riesgos. El proceso debe garantizar el cumplimiento de las leyes y reglamentos relevantes. Este objetivo de control afecta, primariamente 120 la efectividad y en forma secundaria: el cumplimiento Nivel de riesgo: [ ] Alto [X] Medio [ ] Bajo Nivel de Madurez: Repetible. La gerencia tiene un entendimiento implícito de las necesidades y de los requerimientos de un ambiente de control de información efectivo, aunque las prácticas son, en su mayoría, informales. La gerencia ha comunicado la necesidad de políticas, procedimientos y estándares de control, pero la elaboración se delega a la discreción de gerentes y áreas individuales. La calidad se reconoce como una filosofía deseable a seguir, pero las prácticas se dejan a discreción de los gerentes. El entrenamiento se realiza de forma individual, según se lo requiera. Observaciones: La Administración Federal de Ingresos Públicos, como entidad autárquica, se encuentra facultada para reglamentar su funcionamiento interno, dictar nomas reglamentarias e interpretativas de alcance general respecto de terceros y la de fijar las políticas y criterios generales de conducción. Existe normativa vigente (Anexo VI – Nota 5) por la cual se regulan los actos de carácter individual y general, normativos o de ejecución, en el ámbito del Organismo, así como también la competencia de los distintos funcionarios, ya sea originaria o delegada en que se fundamenten los actos administrativos. En el caso de la implantación y comunicación de políticas de TI, se implementan y/o regulan a través de Disposiciones y/o Instrucciones Generales (Anexo VI – Nota 6). Las mismas se encuentran disponibles para el personal del Organismo en su intranet. Sin embargo, la ausencia de un Plan Estratégico de TI, hace difícil transmitir las políticas de TI generales para la organización, salvo algunas iniciativas aisladas. Aclaraciones y/o comentarios del área responsable: No hay comentarios del Organismo. Comentario de AGN: El Organismo no realiza comentarios, por lo que se mantiene la observación realizada. 121 4.1.7 Administrar los recursos humanos de TI Objetivo de control: Adquirir, mantener y motivar una fuerza de trabajo para la creación y entrega de servicios de TI para el negocio. Esto se logra siguiendo prácticas definidas y aprobadas que apoyan el reclutamiento, entrenamiento, la evaluación del desempeño, la promoción y la terminación. Este proceso es crítico, ya que las personas son activos importantes, y el ambiente de gobierno y de control interno depende fuertemente de la motivación y competencia del personal. Este objetivo de control afecta, primariamente: la efectividad la eficiencia Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Parcialmente definido. Existe un proceso definido y documentado para administrar los recursos humanos de TI. Existe un plan informal de administración de recursos humanos. Existe un enfoque estratégico para la contratación y la administración del personal de TI. El plan de entrenamiento formal está diseñado para satisfacer las necesidades de los recursos humanos de TI. Está establecido un programa de rotación, diseñado para expandir las habilidades gerenciales. Observaciones: Existe normativa que regula la política de ingreso de personal, así como la estructura organizativa de la Administración Federal de Ingresos Públicos hasta el nivel de Subdirección General, inclusive. (Anexo VI – Nota 7) También está definido el organigrama de la Subdirección con un detalle de los roles y responsabilidades para cada perfil hasta nivel de división. (Anexo VI – Nota 8) En relación a las competencias del personal, existe una matriz de perfiles de puestos, agrupados por cada especialización, con las competencias técnicas requeridas para cubrirlo. (Anexo VI – Nota 7) Como resultado de un proceso de integración de distintos organismos (impositivo, aduanero y seguridad social) persisten la convivencia de distintos convenios colectivos de trabajo que generan asimetrías tanto administrativas como funcionales dentro de una misma área de TI que brinda servicios a distintas Direcciones Generales. 122 La política restrictiva de incorporación de personal, provoca que: En algunas áreas existe dependencia crítica de individuos clave por falta de personal especializado. Esto también limita el intercambio de conocimientos, el planeamiento de la sucesión y la posibilidad de respaldarse o disponer una adecuada rotación. Limita el establecimiento de un Plan de Carrera con movilidades ascendentes u horizontales, que permitan a los individuos una perspectiva de desarrollo a largo plazo. Existen concursos a niveles de jefaturas, pero no en los niveles inferiores. También existe la posibilidad de ascender de categoría con la obtención de un título universitario. La política de retención del personal está basada en la estabilidad del empleo público y los niveles salariales. Existe un riesgo latente de que si cambian estas condiciones, podría originarse un éxodo de personal altamente especializado a otras organizaciones. Se realizan evaluaciones de desempeño anuales, de cuyo resultado depende un incentivo económico. El procedimiento, que está sistematizado, no contempla una evaluación de los niveles inferiores hacia los niveles superiores. No existen mecanismos de autoevaluación. En relación a la capacitación, el Organismo elabora un Plan de Capacitación en base a una “Encuesta de necesidades de capacitación” que se incluyen en la confección del Plan de Gestión Anual, no en función del Plan estratégico de la SDG SIT. La capacitación se realiza en forma interna y externa. Se cuenta con una herramienta de capacitación virtual denominada “Campus Virtual” donde se deja a disposición del personal materiales referidos a distintas temáticas. En relación a la capacitación de usuarios internos de las aplicaciones implantadas, las denominadas “Pautas para el desarrollo y mantenimiento de sistemas informáticos en la AFIP”, establecen los esquemas de documentación que son elaborados por las divisiones de control de calidad de las áreas de desarrollo, que posteriormente quedan disponibles en la página de la Dirección de Capacitación. Aclaraciones y/o comentarios del área responsable: Se comparte parcialmente la observación. Recientemente se han efectuado convocatorias internas para reforzar las 123 áreas de sistemas, las cuales han resultado fallidas, razón por la que se efectuó el requerimiento de personal al área de Recursos Humanos. No obstante lo expuesto, se ha acordado con las áreas operativas establecer en el corto plazo la modalidad de teletrabajo para los informáticos que revistan en dichas dependencias, quienes realizarán tareas propias de esta Subdirección General, bajo supervisión de esta Instancia. Comentario de AGN: Se mantienen las observaciones. Las mejoras se evaluarán en una próxima auditoría. 4.1.8 Administrar la calidad Objetivo de control: Se debe elaborar y mantener un sistema de administración de calidad, el cual incluya procesos y estándares probados de desarrollo y de adquisición. Esto se facilita por medio de la planeación, implantación y mantenimiento del sistema de administración de calidad, proporcionando requerimientos, procedimientos y políticas claras de calidad. 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 desviaciones y la comunicación de los resultados a los interesados. La administración de calidad es esencial para garantizar que TI está dando valor a los objetivos de la organización, mejora continua y transparencia para los interesados. Este objetivo de control afecta, primariamente: la efectividad la eficiencia y en forma secundaria: la integridad la confiabilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Inicial. Existe conciencia por parte de la dirección de la necesidad de un Sistema de Administración de Calidad (SAC). La administración de la calidad es 124 impulsada por individuos cuando éste ocurre. La dirección realiza juicios informales sobre la calidad. Observaciones: Si bien en el Plan Estratégico del Organismo se plantea la necesidad de establecer lineamientos para desarrollar procesos de calidad, no se evidenció al momento de esta auditoría, la existencia de políticas de calidad, un plan de calidad y/o un sistema de administración de la misma, ni a nivel de la organización ni en la SDG SIT. No está definida en el organigrama el área correspondiente en la SDG SIT para llevarlo a cabo. Hay iniciativas aisladas en las direcciones de Operaciones y de Infraestructura Tecnológica para mantener la continuidad de los servicios a niveles razonables y en las áreas de desarrollo en la fase de homologación de aplicaciones. Aclaraciones y/o comentarios del área responsable: Se comparte parcialmente la observación referida a la inexistencia de un área encargada del aseguramiento de la calidad. Al respecto se informa que cada área de desarrollo que depende de esta Subdirección General tiene expresas funciones de control de calidad lo cual se encuentra reflejado estructuralmente. Comentario de AGN: Se mantienen las observaciones. Si bien existen las funciones referidas a aseguramiento de calidad, en las áreas de desarrollo, su alcance es limitado. Falta establecer y mantener un sistema de Administración de la Calidad que se aplique a toda la organización de TI. El cual proporcione un enfoque estándar, formal y continuo. Este debe incluir, entre otros: estándares de o codificación de software o normas de nomenclatura o formatos de archivos o diseño o para desarrollo y pruebas. diccionario de datos interfaces de usuario indicadores de eficiencia y de desempeño 125 También debe contemplar la definición de las mediciones para monitorear el cumplimiento que puedan ser usadas posteriormente por el dueño del proceso para tomar posibles medidas correctivas. 4.1.9 Evaluar y administrar los riesgos de TI Objetivo de control: Crear y dar mantenimiento a un marco de trabajo de administración de riesgos. El marco de trabajo documenta un nivel común y acordado de riesgos de TI, estrategias de mitigación y riesgos residuales acordados. Cualquier impacto potencial sobre las metas del Organismo, causado por algún evento no planeado se debe identificar, analizar y evaluar. Se deben adoptar estrategias de mitigación de riesgos para minimizar los riesgos residuales a un nivel aceptable. El resultado de la evaluación debe ser entendible para los participantes y se debe expresar en términos financieros, para permitir a los participantes alinear los riesgos a un nivel aceptable de tolerancia. Este objetivo de control afecta, primariamente: la confidencialidad la integridad la disponibilidad y en forma secundaria: la efectividad la eficiencia el cumplimiento la confiabilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Parcialmente repetible. Existe un enfoque de evaluación de riesgos inmaduro y en evolución. La administración de riesgos se da por lo general a altos niveles y se aplica de manera típica sólo a proyectos grandes o como respuesta a problemas. Los procesos de mitigación de riesgos están en implantación donde éstos se identifican. Observaciones: No está definida la función correspondiente en el organigrama. Tampoco se dispone de un marco de trabajo general de administración de riesgos de TI, integrado al 126 gobierno y el marco de control. Existen iniciativas aisladas en algunas direcciones o departamentos que corresponden a las misiones y funciones que se fijaron para ellos. El área de Auditoría Interna cuenta con un marco de administración de riesgos para poder priorizar los procesos a controlar, ya que éste no es provisto por un área específica a tal fin. El Organismo cuenta con una herramienta de Gobierno Corporativo, Administración de Riesgos y Cumplimiento Regulatorio (GRC), pero sólo es utilizada por el área de Auditoría Interna. Aclaraciones y/o comentarios del área responsable: No hay comentarios del Organismo. Comentario de AGN: El Organismo no realiza comentarios, por lo que se mantiene la observación realizada. 4.1.10 Administrar proyectos Objetivo de control: Establecer un programa y un marco de control administrativo de proyectos para la administración de todos los proyectos de TI. El marco de trabajo debe garantizar la correcta asignación de prioridades y la coordinación de todos los proyectos. El marco de trabajo debe incluir un plan maestro, asignación de recursos, definición de entregables, aprobación de los usuarios, un enfoque de entrega por fases, aseguramiento de la calidad, un plan formal de pruebas, revisión de pruebas y revisión post-implantación para garantizar la administración de los riesgos del proyecto y la entrega de valor para el Organismo. Este enfoque reduce el riesgo de costos inesperados y de cancelación de proyectos, mejora la comunicación y el involucramiento de los interesados y de los usuarios finales, asegura el valor y la calidad de los entregables de los proyectos, y maximiza su contribución a los programas de inversión en TI. Este objetivo de control afecta, primariamente: la efectividad la eficiencia Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Repetible. La alta dirección ha obtenido y comunicado la conciencia de la necesidad de la administración de los proyectos de TI. La organización está en proceso de desarrollar y utilizar algunas técnicas y métodos proyecto por proyecto. Los 127 proyectos de TI han definido objetivos técnicos y de negocio de manera informal. Hay participación limitada de los interesados en la administración de los proyectos de TI. Las directrices iniciales se han elaborado para muchos aspectos de la administración de proyectos. La aplicación a proyectos de las directrices administrativas se deja a discreción de cada responsable de proyecto. Observaciones: No se ha normalizado un proceso de administración de proyectos que se aplique a todas las áreas. Se utilizan distintas herramientas y distintos criterios para el seguimiento de los proyectos, según sea el sector involucrado. Aclaraciones y/o comentarios del área responsable: Se comparte parcialmente la observación. Cada área de desarrollo administra sus proyectos. Se analizará la factibilidad de la normalización de un proceso de administración de proyectos que se aplique a todas las áreas. Comentario de AGN: El comentario del organismo, no contradice lo expuesto en las observaciones, por lo tanto, se mantienen las mismas. Las mejoras a realizar se evaluarán en una próxima auditoría. 4.2. Adquirir e implementar 4.2.1 Identificar soluciones automatizadas Objetivo de control: La necesidad de una nueva aplicación o función requiere de análisis antes de la compra o desarrollo para garantizar que los requisitos del proyecto se satisfacen con un enfoque efectivo y eficiente. Este proceso cubre la definición de las necesidades, considera las fuentes alternativas, realiza una revisión de la factibilidad tecnológica y económica, ejecuta un análisis de riesgo y de costo-beneficio y concluye con una decisión final de desarrollar o comprar. Todos estos pasos permiten a las organizaciones minimizar el costo para adquirir e implantar soluciones, mientras que al mismo tiempo facilitan el logro de los objetivos del Organismo. Este objetivo de control afecta, primariamente: la efectividad y en forma secundaria: la eficiencia 128 Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Parcialmente definido. Existen orientaciones claras y estructuradas para determinar las soluciones de TI. El enfoque para la determinación de las soluciones de TI requiere la consideración de alternativas evaluadas entre otros, contra los requerimientos del proyecto o del usuario, las oportunidades tecnológicas, la factibilidad económica y las evaluaciones de riesgo. El proceso para determinar las soluciones de TI se aplica para algunos proyectos con base en factores tales como las decisiones tomadas por el personal involucrado, la cantidad de tiempo administrativo dedicado, y el tamaño y prioridad del requerimiento de proyecto original. Se usan enfoques estructurados para definir requerimientos e identificar soluciones de TI. Observaciones: Está definido el proceso de Ciclo de Vida de Desarrollo de Sistemas, alineado a la política de seguridad, aprobada por normativa vigente. (Anexo VI – Nota 9) Se establecen además procedimientos de interacción entre las áreas denominadas “Definidoras” y las áreas de desarrollo de aplicaciones de la SDG SIT, cuya documentación se encuentra formalizada en una serie de documentos entregables que incluyen desde la definición del requerimiento de las necesidades funcionales, determinación de los responsables tanto del área usuaria como del área informática, la asignación de recursos y el cronograma estimado de trabajo. Sin embargo, el procedimiento adolece de fuertes exclusiones, tales como: e) La atención de requerimientos de mantenimiento de sistemas del tipo correctivo originados debido a desvíos y/o errores en la programación. f) Los desarrollos realizados para satisfacer requerimientos puntuales de información. g) Los subcontratos o acuerdos de tercerización de software. h) Los desarrollos realizados en carácter de pruebas de concepto como parte de tareas de investigación. Asimismo, la Subdirección General de Sistemas y Telecomunicaciones pueda autorizar la no utilización de estas pautas para determinados casos. Dada la ausencia de procedimientos para el tratamiento de situaciones de emergencia, en estos casos se utilizan las excepciones antes mencionadas, y no contempla un procedimiento de revisión de pistas de auditoría sobre las acciones tomadas. 129 Por otra parte, el procedimiento carece, en su etapa de evaluación preliminar, de consideraciones relativas al análisis de factibilidad, análisis de riesgos y criterios formalizados para la administración de prioridades, estimación de costos y beneficios esperados que permitan la evaluación de cursos de acción alternativos, como la tercerización del desarrollo. Además, permite que la adopción de los documentos entregables sea a criterio de cada división de desarrollo, mientras cumpla con los contenidos mínimos requeridos para cada fase (definición, diseño, construcción e implementación) lo que genera que éstas hayan adoptado un conjunto distinto de documentos. (Anexo VI – Nota 10) En relación al entregable “REQ” (Requerimiento de Sistemas) no todas las áreas definidoras formalizan su confección, por lo cual esta tarea suele ser hecha por las áreas de desarrollo. Al momento de esta auditoría se encuentra en elaboración una Instrucción General que establecerá una nueva metodología de ciclo de vida de desarrollo de sistemas, que reemplazará a la actual y que toma en consideración algunos aspectos aquí observados. Aclaraciones y/o comentarios del área responsable: La IG 02/05 (SDG SIT) fue reemplazada por la IG 05/12 (SDG SIT), la cual contempla los siguientes puntos abarcados por la auditoría: a) La atención de requerimientos de mantenimiento de sistemas del tipo correctivo originados por desvíos y/o errores en la programación. b) Los desarrollos realizados para satisfacer requerimientos puntuales de información. d) Los desarrollos realizados en carácter de pruebas de concepto como parte de tareas de investigación. En el caso del punto c) “Los subcontratos o acuerdos de tercerización de software”, el tema no es contemplado debido a que esta Administración Federal no realiza tercerización del desarrollo. Asimismo la IG 5/12 (SDG SIT) ahora contempla la posibilidad que la Subdirección General de Sistemas y Telecomunicaciones pueda autorizar diferir la confección de la documentación indicada en las pautas para casos de urgencia. 130 También en la nueva normativa, se incluye un formulario para el análisis de factibilidad y riesgo del desarrollo. Comentario de AGN: Durante los trabajos de campo la disposición vigente fue la IG 2/05 no así la 5/12. Por lo tanto se mantienen las observaciones realizadas. Las mejoras planteadas en la IG 05/12 se evaluarán en una próxima auditoría. 4.2.2 Adquirir o desarrollar y mantener software aplicativo Objetivo de control: Las aplicaciones deben estar disponibles de acuerdo con los requerimientos del Organismo. Este proceso cubre el diseño de las aplicaciones, 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 elegidos. Esto permite al Organismo apoyar la operatividad de forma apropiada con las aplicaciones correctamente automatizadas. Este objetivo de control afecta, primariamente: la efectividad la eficiencia y en forma secundaria: la integridad la confiabilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Parcialmente 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 de la organización. 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 lo que es muy probable que se salten pasos. Las actividades de mantenimiento se planean, programan y coordinan. Observaciones: La Subdirección General de Informática y Telecomunicaciones implementó las “Pautas para el desarrollo y mantenimiento de Sistemas Informáticos en la AFIP” (Anexo VI – Nota 9) donde se define el proceso de Ciclo de Vida de Desarrollo de 131 Sistemas (CVDS). Las Pautas, están alineadas a la política de seguridad, aprobada mediante “Pautas y consideraciones de seguridad a tener en cuenta en el Ciclo de Vida del Desarrollo y Mantenimiento de Sistemas en relación con la Seguridad de la Información”. La misma contempla documentación, aprobaciones y escalamiento en las etapas relevantes tales como el diseño de alto nivel, el diseño detallado, fase de construcción, pruebas, implementación y el pase a producción de aplicaciones. Las misiones y funciones de las divisiones de Control de Calidad de las áreas de desarrollo contemplan la etapa de aseguramiento de la calidad del software enfocada a las pruebas y a la calidad de la documentación. Falta incluir en la metodología de CVDS un análisis de la calidad del desarrollo del software (Anexo VI – Nota 11) aunque existen algunas iniciativas para los desarrollos de servicios web. La metodología de CVDS tampoco contempla consideraciones de costos ni la posibilidad de tercerizar el desarrollo o el mantenimiento. Al momento de esta auditoría se encuentra en elaboración una Instrucción General que establecerá una nueva metodología de ciclo de vida para el desarrollo de sistemas, que reemplazará a la actual, y que toma en consideración algunos aspectos aquí observados. En algunos casos, la contratación de servicios externos de desarrollo de sistemas se efectúa a través de contratos con universidades, en cuyas cláusulas contractuales se estipula la entrega de todo el software y documentación necesaria que permite al Organismo la independencia del proveedor en tareas de mantenimiento futuro. Aclaraciones y/o comentarios del área responsable: En la IG 5/12 (SDG SIT) se incluye el Anexo 11, “PROCEDIMIENTO PARA EL CONTROL DE CALIDAD DE LA DOCUMENTACIÓN DE LOS PROYECTOS DE DESARROLLO, MANTENIMIENTO Y DISCONTINUIDAD DE SISTEMAS INFORMÁTICOS”. Comentario de AGN: Durante los trabajos de campo la disposición vigente fue la IG 2/05 no así la 5/12. Por lo tanto se mantienen las observaciones realizadas. Las mejoras planteadas en la IG 05/12 se evaluarán en una próxima auditoría. 132 4.2.3 Adquirir y mantener infraestructura tecnológica Objetivo de control: El Organismo debe contar con procesos para adquirir, implantar y actualizar la infraestructura tecnológica. Esto requiere de un enfoque planeado para adquirir, mantener y proteger la infraestructura de acuerdo con las estrategias tecnológicas convenidas y la disposición del ambiente de desarrollo y pruebas. Esto garantiza que exista un soporte tecnológico continuo para las aplicaciones. Este objetivo de control afecta, primariamente: la eficiencia y en forma secundaria: la efectividad la integridad la disponibilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Parcialmente definido. Existe un claro, definido y generalmente entendido proceso para adquirir y dar mantenimiento a la infraestructura de TI. El proceso respalda las necesidades de las aplicaciones críticas de lo organización y concuerda con la estrategia de TI, pero no se aplica en forma consistente. Se planea, programa y coordina el mantenimiento. Existe un ambiente independiente para pruebas de factibilidad. Observaciones: Por ser la AFIP un organismo que recibió los recursos informáticos de la Dirección General Impositiva, la Dirección General de Aduanas y de Dirección de Seguridad Social existe una gran diversidad de plataformas de software y de motores de base de datos. Cuentan con algunos productos obsoletos, discontinuados por sus fabricantes, lo que implica que carezcan de soporte. No se encontró un plan formalmente definido para la integración efectiva de las áreas y sistemas que permita reducir la cantidad de plataformas existentes en la actualidad. No existe un plan de adquisición de infraestructura tecnológica formalmente definido y aprobado. Las compras de equipamiento se realizan en función de las necesidades detectadas y de las proyecciones a futuro de acuerdo a distintos parámetros obtenidos de los sistemas de control instalados. 133 Existe la posibilidad que pueda producirse atraso tecnológico al momento de recepción de equipos nuevos debido al excesivo tiempo que insume el proceso completo de compras, desde la formulación del requerimiento hasta la recepción del producto solicitado, que puede superar el año. Si bien se realizan los mantenimientos adecuados a los servidores, equipos de comunicaciones y estaciones de trabajo, no existe un procedimiento automatizado para la instalación de actualizaciones en los sistemas operativos de computadoras personales por carecer de una herramienta necesaria para la instalación de los mismos. La falta de un plan de análisis de riesgo y evaluación de vulnerabilidades no permite identificar los posibles problemas que la falta de actualización en los sistemas operativos puedan producir. Aclaraciones y/o comentarios del área responsable: Se comparte parcialmente lo observado en cuanto a que no se encontró un plan formalmente definido para la integración efectiva de las áreas y sistemas que permita reducir la cantidad de plataformas existentes en la actualidad. Desde el año 2011 se encuentra como una de las iniciativas del Plan de Gestión de la AFIP, la migración de los Sistemas de la Seguridad Social, por lo cual los principales módulos y aplicaciones de dicho ámbito, residentes en el Mainframe IBM (base de datos D82), se ejecutarán en forma operativa en el SUN/Solaris (base de datos de la base ORACLE). No se comparte la observación acerca de la inexistencia de un plan de adquisición de infraestructura tecnológica formalmente definido y aprobado, ya que existe un plan de adquisiciones formalmente definido y en dichas compras se prevé las proyecciones a futuro durante el periodo de vigencia de la orden de compra. Producto de esta política, la AFIP cuenta con un centro de cómputos con la tecnología de vanguardia, capaz de satisfacer las necesidades propias de esta Administración Federal y de varios Organismos del estado nacional. Se comparte parcialmente la observación referida a la posibilidad de que pueda producirse atraso tecnológico al momento de recepción de equipos nuevos debido al excesivo tiempo que insume el proceso completo de compras, ya que en caso de 134 obsolescencia tecnológica entre el momento de la definición del pliego y la entrega del equipo el oferente está obligado por el pliego de bases y condiciones a entregar un equipamiento sustituto que lo reemplaza. Las actualizaciones de los distintos upgrade de SO o IOS, están contemplados en los pliegos de contratación, pero su actualización es analizada caso por caso sobre todo teniendo en cuenta el impacto en la infraestructura. En relación a que no existe un procedimiento automatizado para la instalación de actualizaciones en los sistemas operativos de computadoras personales, se comparte parcialmente la observación ya que, independientemente de la compra del software de administración de la infraestructura de Estaciones de Trabajo distribuidas en AFIP, desde hace aproximadamente dos años se está utilizando la herramienta WSUS en alrededor de 10.000 equipos (56% del parque) para la distribución de parches de seguridad en las estaciones de trabajo. Comentario de AGN: El plan de Infraestructura solo contempla la sala cofre. Durante las tareas de campo no se encontró por ejemplo un plan de renovación de PCs que asegure que todo el parque informático se encuentre dentro de la vida útil del mismo. En consecuencia se mantiene la observación. Las mejoras a realizar se evaluarán en una próxima auditoría. 4.2.4 Facilitar la operación y el uso Objetivo de control: El conocimiento sobre los nuevos sistemas debe estar disponible. Este proceso requiere la generación de documentación y manuales para usuarios y TI, y proporciona entrenamiento para garantizar el uso y la operación correctos de las aplicaciones y la infraestructura. Este objetivo de control afecta, primariamente: la efectividad la eficiencia y en forma secundaria: la integridad la disponibilidad el cumplimiento 135 la confiabilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Repetible. Se utilizan enfoques similares para generar procedimientos y documentación, pero no se basan en un enfoque estructural o marco de trabajo. No hay un enfoque uniforme para el desarrollo de procedimientos de usuario y de operación. Individuos o equipos de proyecto generan los materiales de entrenamiento, y la calidad depende de los individuos que se involucran. Los procedimientos y la calidad del soporte al usuario son variables, con insuficiente consistencia e integración a lo largo de la organización. Se proporcionan o facilitan programas de entrenamiento para las áreas decisorias y los usuarios, pero no hay un plan general para ofrecer o dar entrenamiento. Observaciones: El Decreto 618 del 10 de julio de 1997 establece que, entre otras facultades, que el Administrador Federal de Ingresos Públicos reglamenta el funcionamiento interno. El artículo 4 del mismo decreto prevé la posibilidad de delegar dichas potestades a favor de los Directores Generales y Subdirectores Generales. Estos actos internos de carácter resolutivo son formalizados a través de la aprobación de Resoluciones, Disposiciones o Instrucciones Generales. La Subdirección General de Sistemas y Telecomunicaciones genera este acto administrativo en cada política o procedimiento a aplicar. Dependiendo del alcance que se le quiera dar, es aprobada por una jerarquía acorde. En el caso de las áreas de desarrollo y mantenimiento de aplicaciones, las respectivas áreas de Control de Calidad deben verificar que la documentación esté confeccionada de acuerdo a los estándares establecidos. Sin embargo, su cumplimiento depende del criterio adoptado por cada área. Toda la documentación referida a disposiciones, resoluciones e instrucciones generales se encuentra disponible para los agentes del Organismo en la intranet. No existe un mecanismo formalmente definido para la delegación de la capacitación en las aplicaciones a los usuarios finales, desde las áreas de desarrollo de software a la Dirección de Capacitación. Aclaraciones y/o comentarios del área responsable: Se comparte parcialmente la observación, en cuanto a que la calidad de los materiales de entrenamiento depende de los 136 individuos que se involucren. En las adquisiciones de hardware y/o software se solicita capacitación, más allá de las necesidades que cada área puede plantear. Comentario de AGN: El organismo acepta las observaciones realizadas por lo tanto se mantienen las mismas. 4.2.5 Adquirir recursos de TI Objetivo de control: Se deben suministrar recursos de TI, incluyendo personas, hardware, software y servicios. Esto requiere de la definición y ejecución de los procedimientos de adquisición, la selección de proveedores, el ajuste de arreglos contractuales y la adquisición en sí. El hacerlo así garantiza que se tengan todos los recursos de TI que se requieren de una manera oportuna y rentable. Este objetivo de control afecta, primariamente: la eficiencia y en forma secundaria: la efectividad el cumplimiento Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Definido. Existen políticas y procedimientos para la adquisición de TI, éstas toman como guía el proceso general de adquisición de la organización. Las compras de TI se integran en gran parte con los sistemas generales de adquisición del Organismo. Existen estándares de TI para la adquisición de recursos de TI. La administración de TI comunica la necesidad de contar con una administración adecuada de adquisiciones y contratos en toda la función de TI. Observaciones: Las adquisiciones se llevan a cabo en el marco de administración de proyectos y siguiendo la normativa de compras del Estado. Los procedimientos de adquisición son auditables. La ausencia de un Plan Estratégico lleva a que las decisiones de adquisición sean reactivas a las necesidades coyunturales. Existen además normativas internas que rigen para todas las áreas de AFIP. (Anexo VI – Nota 12) 137 De las órdenes de compras analizadas surge que se tuvieron en cuenta los aspectos legales y técnicos para cada contratación tales como responsabilidades y obligaciones legales, financieras, organizacionales, de seguridad y de protección de propiedad intelectual. La contratación de servicios externos de desarrollo de sistemas se efectúa a través de: Contratos con universidades, en cuyas cláusulas se estipula la entrega de todo el software y documentación necesaria que permite al Organismo la independencia del proveedor en tareas de mantenimiento. En algunos casos, el mantenimiento de estos sistemas, producen una sobrecarga de trabajo a la dotación existente que no está en condiciones de absorberlo adecuadamente. Personal contratado a plazo fijo. Estos contratos tienen una vigencia de tres meses y generalmente son renovables. El agente que trabaja más de cinco años en esta modalidad, cambia la figura a contrato por tiempo indeterminado. Esta indefinición provoca incertidumbre en la disponibilidad de recursos para proyectos a mediano y largo plazo. Aclaraciones y/o comentarios del área responsable: La Subdirección General de Planificación de la AFIP ha revisado el proyecto de Plan Estratégico de TI que fuera conocido por esa AGN, señalando que el Plan Estratégico es Institucional. Por lo tanto sugirió que, alineado con el mismo, se apruebe un Plan Táctico de TI, el que cubre desde el año 2012 hasta el año 2015. El mismo ha sido enviado a la citada Subdirección General para la formalización final de su aprobación. Comentario de AGN: El organismo acepta las observaciones realizadas por lo tanto se mantienen las mismas. Las mejoras a realizar se evaluarán en una próxima auditoría. 4.2.6 Administrar cambios Objetivo de control: Todos los cambios, incluyendo el mantenimiento de emergencia y actualizaciones, relacionados con la infraestructura y las aplicaciones dentro del ambiente de producción, deben administrarse formal y controladamente. Los cambios (incluyendo procedimientos, procesos, sistemas y parámetros del servicio) se deben registrar, evaluar y autorizar previo a la implantación y contrastar contra los resultados planeados después de 138 la misma. Esto garantiza la reducción de riesgos que impactan negativamente en la estabilidad o integridad del ambiente de producción. Este objetivo de control afecta, primariamente: la efectividad la eficiencia la integridad la disponibilidad y en forma secundaria: la confiabilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Parcialmente definido. Existe un proceso formal definido para la administración de cambios, que incluye la autorización del cambio y la administración de la liberación. Se dan soluciones temporales a los problemas y los procesos pero en ocasiones no se cumplen. El análisis de impacto de los cambios de TI se está formalizando para apoyar la implantación planeada de nuevas aplicaciones y tecnologías. Observaciones: Existe una instrucción general que define el proceso de Ciclo de Vida de Desarrollo de Sistemas para las aplicaciones desarrolladas por el Organismo (Anexo VI – Nota 9). Esta, está alineada a la política de seguridad, y aprobada formalmente. (Anexo VI – Nota 13) Se contempla documentación, aprobaciones y escalamiento en las etapas relevantes tales como el diseño de alto nivel, el diseño detallado, fase de construcción, aseguramiento de la calidad, pruebas, implementación y liberación de aplicaciones de software. La etapa de aseguramiento de la calidad de software está enfocada a las pruebas y a la calidad de la documentación, no así a un análisis de la calidad del desarrollo del software. Existen algunas iniciativas en este sentido para los desarrollos de servicios web (web services). Faltan procedimientos para el tratamiento de situaciones de cambios de emergencia, que contemplen una etapa de revisión obligatoria de pistas de auditoría sobre las acciones tomadas. 139 Se observa en la aplicación práctica de esta metodología, las mismas falencias que en los desarrollos nuevos: falta de consideraciones de análisis de prioridades, factibilidad, riesgo, costos y beneficios esperados. La gestión de aseguramiento de la calidad está enfocada solamente a las pruebas. Al momento de esta auditoría se encuentra en elaboración una Instrucción General que establecerá una nueva metodología de ciclo de vida de desarrollo de sistemas, que toma en consideración algunos aspectos aquí observados. En relación a las actualizaciones de sistema operativo, existe un procedimiento formal para su instalación. Con respecto a las estaciones de trabajo nuevas, existe un procedimiento inicial por el cual se entrega al proveedor el software de base (Windows XP Service Pack III, Zip central, Adobe Reader, Adobe Flash Player, OpenOffice, Antivirus Panda) para que instale una imagen del mismo en las máquinas a entregar. Cualquier incidente posterior es canalizado por la Mesa de Ayuda que escala el problema de acuerdo al procedimiento del Sistema de Registración de Incidentes (SRI). Aclaraciones y/o comentarios del área responsable: La IG 5/12 (SDG SIT), que reemplaza a la IG 2/05 (SDG SIT), contempla la posibilidad que la Subdirección General de Sistemas y Telecomunicaciones pueda autorizar diferir la confección de la documentación indicada en las pautas para casos de urgencia. También en la nueva normativa, se incluye un formulario para el análisis de factibilidad y riesgo del desarrollo. Comentario de AGN: Durante los trabajos de campo la disposición vigente fue la IG 2/05 no así la 5/12. Por lo tanto se mantienen las observaciones realizadas. Las mejoras planteadas en la IG 05/12 se evaluarán en una próxima auditoría. 4.2.7 Instalar y acreditar soluciones y cambios Objetivo de control: Los nuevos sistemas necesitan estar funcionales una vez que su desarrollo se completa. Esto requiere pruebas adecuadas en un ambiente dedicado con datos de prueba relevantes, definir la transición e instrucciones de migración, planear la liberación y la transición en sí al ambiente de producción, y revisar la post-implantación. 140 Esto garantiza que los sistemas operacionales estén en línea con las expectativas convenidas y con los resultados. Este objetivo de control afecta, primariamente: la efectividad y en forma secundaria: la eficiencia la integridad la disponibilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Parcialmente definido. Se cuenta con una metodología formal en relación con la instalación, migración, conversión y aceptación. Los procesos de TI para instalación y acreditación están integrados dentro del ciclo de vida del sistema y están automatizados hasta cierto punto. El entrenamiento, pruebas y transición y pase a producción tienen, probablemente, variaciones respecto al proceso definido, con base en decisiones individuales. Observaciones: Existe una instrucción general que define las actividades a seguir para la puesta efectiva en producción de las aplicaciones (Anexo VI – Nota 14), se incluye allí las responsabilidades de las áreas involucradas (Control de Calidad, Soporte Técnico y Área Definidora) y la documentación que debe generarse, con sus correspondientes aprobaciones. En relación a los desarrollos de servicios Web, al momento de esta auditoría se encontraba a la firma del Administrador Federal de Ingresos Públicos una resolución general que establece los procedimientos que deben utilizar los desarrolladores de aplicaciones de uso propio o de terceros y que además contempla la posibilidad de que los usuarios finales, puedan acceder al entorno de prueba (testing) y pase a producción. Resta incluir en la metodología general un procedimiento de emergencia que abarque las actuales exclusiones que permite esta resolución, tales como: La atención de requerimientos de mantenimiento de sistemas del tipo correctivo debidos a desvíos y/o errores en la programación. 141 Los desarrollos realizados para satisfacer requerimientos puntuales de información. Los subcontratos o acuerdos de tercerización de software. Los desarrollos realizados en carácter de pruebas de concepto como parte de tareas de investigación. Casos expresamente autorizados por la SDG SIT. El pase de los aplicativos a producción los solicitan las áreas de Control de Calidad a las áreas de Operaciones a través de aplicativos. Este paso contempla la aprobación de las Áreas Definidoras, aunque no en todos los casos se cumple. La documentación de la aprobación de las etapas de pruebas no es homogénea en todos los departamentos de desarrollo. Aclaraciones y/o comentarios del área responsable: La IG 02/05 (SDG SIT) fue reemplazada por la IG 05/12 (SDG SIT). La cuál contempla los siguientes puntos abarcados por la auditoría: - La atención de requerimientos de mantenimiento de sistemas del tipo correctivo debidos a desvíos y/o errores en la programación. - Los desarrollos realizados para satisfacer requerimientos puntuales de información. - Los desarrollos realizados en carácter de pruebas de concepto como parte de tareas de investigación. - Casos expresamente autorizados por la SDG SIT. Los subcontratos o acuerdos de tercerización de software no es contemplado ya que esta Administración no contempla la contratación de servicios de desarrollo de software. Comentario de AGN: Durante los trabajos de campo la disposición vigente fue la IG 2/05 no así la 5/12. Por lo tanto se mantienen las observaciones realizadas. Las mejoras planteadas en la IG 05/12 se evaluarán en una próxima auditoría. 4.3. Entregar y dar soporte 4.3.1 Definir y administrar los niveles de servicio Objetivo de control: La máxima autoridad debe definir un marco que promueva el establecimiento de acuerdos de nivel de servicio que formalicen los criterios de desempeño en virtud de los cuales se medirá su cantidad y calidad. 142 Este objetivo de control afecta, primariamente: la efectividad 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. Los niveles de servicio están acordados pero no están controlados. Los reportes de los niveles de servicio están incompletos y dependen, en forma individual, de las habilidades y la iniciativa de los administradores. Están designados responsables de niveles de servicio por cada acuerdo con atribuciones definidas, pero con autoridad limitada. Si existe un proceso para el cumplimiento de los acuerdos de niveles de servicio es voluntario y no está debidamente implementado. Observaciones: De la documentación recibida surge que no existe un marco de trabajo para la administración de niveles de servicio entre las áreas usuarias y el prestador del servicio, en este caso la Dirección de Sistemas y Telecomunicaciones. Los acuerdos entre AFIP y distintos organismos, que proveen y reciben datos del mismo, carecen de definiciones técnicas precisas y de penalizaciones por incumplimiento. No existen acuerdos formalizados sobre niveles de servicio entre la Dirección de Sistemas y Telecomunicaciones y otras áreas de la AFIP, aunque en determinados casos existen plazos de tiempo no formales para la realización de tareas. Aclaraciones y/o comentarios del área responsable: De acuerdo con la observación. Comentario de AGN: El organismo acepta la observaciones realizadas por lo tanto se mantienen las mismas. 143 4.3.2 Administrar servicios de terceros Objetivo de control: La máxima autoridad debe implementar medidas de control orientadas a la revisión y al monitoreo de los contratos y procedimientos existentes para garantizar la eficacia y el cumplimiento de la política del Organismo. Este objetivo de control afecta, primariamente: la efectividad 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: Definido. Existen procedimientos bien documentados para controlar los servicios de terceros con procesos claros para tratar y negociar con los proveedores. Cuando se hace un acuerdo de prestación de servicios, la relación con el tercero es meramente contractual. La naturaleza de los servicios a prestar se detalla en el contrato e incluye requerimientos legales, operacionales y de control. Se asigna la responsabilidad de supervisar los servicios de terceros. Los términos contractuales se basan en formatos estandarizados. Observaciones: Los procesos de compras de bienes y servicios se realizan de acuerdo con normativa vigente (ANEXO VI), y por las reglamentaciones emitidas por la ONTI y por SIGEN. Los servicios de los proveedores se encuentran identificados y formalizados por medio de órdenes de compra. No existe una calificación de los servicios que tome en cuenta su importancia y su criticidad para la organización. 144 La documentación sobre las relaciones técnicas, que incluyen los roles, responsabilidades, metas y entregables se encuentran definidas en los pliegos de compras. Como no existe un plan de riesgos para la AFIP, no se encuentran identificados ni existen planes de mitigación sobre los riesgos relacionados con los proveedores que garantice una entrega segura que permita la continuidad de los servicios. Aclaraciones y/o comentarios del área responsable: No se comparte la observación que indica la inexistencia de una calificación de los servicios que tome en cuenta su importancia y su criticidad para la Organización. Los Servicios de Infraestructura que soportan el normal funcionamiento del Centro de Cómputos de esta Subdirección General de Sistemas y Telecomunicaciones son considerados todos de alta criticidad. No obstante los servicios se encuentran debidamente identificados y en algunos casos con rutinas de mantenimiento planificadas desde el momento de la concepción del pliego técnico. Para los casos de mantenimiento preventivo, cada servicio crítico posee su Planilla de Trabajos Programados. Para los demás casos donde corresponde el mantenimiento correctivo (equipos High End), la criticidad se indica en el establecimiento de un SLA estricto en cuanto a los tiempos de atención y reparación. No se comparte lo observado en cuanto a que no existe un plan de riesgos para la AFIP, ni se encuentran identificados ni existen planes de mitigación sobre los riesgos relacionados con los proveedores de manera que garantice una entrega segura que permita la continuidad de los servicios. Ello es así, ya que debido a que el proveedor del servicio de mantenimiento es asignado en forma exclusiva por el fabricante del equipo o software, el mismo no podrá alegar inconvenientes para la obtención del servicio mencionado, debiendo garantizar en toda circunstancia la posibilidad de escalamiento de los eventos o la provisión de las partes de reemplazo. En tal sentido resulta impracticable contar con prestadores alternativos y las contrataciones se realizan en forma directa “por exclusividad” de acuerdo a lo establecido en la Disposición N°297/03 (AFIP). Asimismo se le exige mediante condiciones expresas en la contratación del servicio que el personal asignado deberá ser calificado, con experiencia y conocimientos sobre el equipo, siendo requisito además que el mismo este certificado. 145 Además, en caso que el proveedor no pudiera concretar la reparación dentro de los plazos estipulados deberá solucionar el inconveniente mediante el reemplazo de la referida unidad por otra en condiciones de buen funcionamiento, sin que esto implique costo alguno para el Comprador. Por último, cabe señalar que históricamente no ha habido inconvenientes de importancia que hayan afectado a la totalidad de los servicios esenciales de la AFIP. Comentario de AGN: La observación hace referencia a la inexistencia de una Evaluación de Riesgos de la AFIP, que sumado a la falta de un Plan de Contingencia (observado en el punto 4.3.4) no queda definido explícitamente el grado de criticidad de cada uno de los proveedores. Las iniciativas son independientes por falta de un plan global que contemple todos los posibles escenarios que puedan presentarse. En consecuencia se mantiene la observación. 4.3.3 Administrar el desempeño y la capacidad Objetivo de control: Se debe implementar un proceso de administración orientado a la recopilación de datos, al análisis y a la generación de informes sobre el desempeño de los recursos de Tecnología de la Información, la dimensión de los sistemas de aplicación y la demanda de cargas de trabajo. Este proceso debe incluir el pronóstico de las necesidades futuras, almacenamiento y contingencias, y garantizar que los recursos de información que soportan los requerimientos del Organismo estén disponibles de manera continua. Este objetivo de control afecta, primariamente: la efectividad la eficiencia y en forma secundaria: la disponibilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de madurez: Administrado. Hay procesos y herramientas disponibles para medir el uso del sistema, el desempeño y la capacidad, y los resultados se comparan con metas definidas. Hay información actualizada disponible, que brinda estadísticas estandarizadas y alerta sobre incidentes causados por falta de desempeño o de capacidad. Los problemas 146 que aparezcan se enfrentan de acuerdo con procedimientos definidos y estandarizados. Se utilizan herramientas automatizadas para monitorear recursos específicos tales como espacio en disco, servidores y la electrónica de las redes. Las estadísticas de desempeño y capacidad son reportadas en términos de los procesos del Organismo. Observaciones: Se realiza el monitoreo de parámetros tales como capacidad, desempeño, ambientales del centro de cómputos y el funcionamiento del sistema de energía eléctrica, estado de las UPS y del sistema de alarma contra incendios. Los datos obtenidos de los sistemas de control alimentan dos herramientas (PATROL y TMART) que permiten obtener estadísticas que se utilizan para prever las necesidades futuras del Organismo la organización. Los dispositivos de control informan automáticamente cualquier desviación no esperada emitiendo alarmas a los operadores y enviando mensajes a los teléfonos celulares de los responsables de las áreas involucradas. Se almacenan los logs de todos los incidentes, y se confeccionan estadísticas de desempeño semanal y mensual. La seguridad de los sistemas del Organismo es controlada por la División Monitoreo y Detección que depende Departamento de Seguridad Informática de la Dirección de Infraestructura Tecnológica. Para ello se analizan los datos de las siguientes herramientas: Firewall Central de Red IPS (Intrusion Prevention Systems – Sistemas de prevención de intrusión) IDS (Intrusion Detection Systems – Sistemas de detección de intrusión) Proxy Firewalls Departamentales WAF (Detección en línea de intrusiones) Análisis de Aplicaciones WEB Se emiten alertas según parámetros establecidos y se realizan reportes sobre la cantidad de eventos que se producen. El monitoreo de los sistemas de comunicaciones lo realiza la División Gestión de Redes que se ocupa de controlar el tráfico de las redes LAN, MAN, WAN, satelital y WiFi. Este 147 control se realiza con herramientas propias y con aplicaciones suministradas por los proveedores. Aclaraciones y/o comentarios del área responsable: De acuerdo con lo observado. Comentario de AGN: El organismo acepta las observaciones realizadas por lo tanto se mantienen las mismas. 4.3.4 Garantizar la continuidad del servicio Objetivo de control: Se requiere desarrollar, mantener y probar planes para asegurar la continuidad de servicio. Al respecto, se debe almacenar respaldos fuera de las instalaciones y brindar entrenamiento periódico. Este objetivo de control afecta, primariamente: la efectividad la disponibilidad y en forma secundaria: la eficiencia Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de madurez: Repetible. Se asigna la responsabilidad para mantener la continuidad del servicio. Los enfoques para asegurar la continuidad están fragmentados. No hay un plan de continuidad de TI documentado, aunque hay compromiso para mantener disponible la continuidad del servicio y sus principios más importantes se conocen. Existe un inventario de sistemas y componentes críticos, pero puede no ser confiable. Las prácticas de continuidad en los servicios emergen, pero el éxito depende de los individuos. Observaciones: No existe un Plan de Continuidad de Servicios que contemple todos los posibles escenarios que puedan presentarse. Actualmente se encuentra en proceso de definición la realización de un estudio de análisis de riesgo que servirá como base para redacción del Plan de Continuidad. No existe un sitio alternativo de procesamiento. Aclaraciones y/o comentarios del área responsable: Se comparte parcialmente lo observado. En los últimos años la Subdirección General de Sistemas y Telecomunicaciones ha 148 desarrollado una importante cantidad de medidas y proyectos tendientes a garantizar la continuidad de los servicios Informáticos de la AFIP, minimizando los riesgos producidos por factores externos o del contexto inherentes a los sistemas informáticos, entre los que se incluye la implementación de la sala Cofre, la instalación de motogeneradores, de equipos de provisión de energía ininterrumpida, de sistemas de video vigilancia, etc. Todas ellas resultan soluciones necesarias para enfrentar distintos tipos de eventos como por ejemplo falta de suministro eléctrico, incendios, humedad, ataques por radiofrecuencia, magnetismo, etc., Realizar estas actividades significó haber avanzado fuertemente en la prevención y mitigación de incidentes de bajo impacto operativo pero de una probabilidad de ocurrencia muy alta. Por ejemplo, en caso de una falta de suministro eléctrico prolongado el Sistema es capaz de mantener operativo el Centro de Cómputos por 18 horas a plena carga y hasta 36hs con las actuales condiciones de consumo. No obstante con un suministro continuo de combustible, la operatoria puede considerarse ininterrumpible. En el último trimestre del año 2012, mediante la Disposición N° 186/12, se creó una Comisión dependiente de esta Subdirección General para redactar un informe que considere los factores que intervendrían para dar continuidad a la operación de los servicios informáticos ante un eventual colapso total o parcial de la operatoria. Para la elaboración de dicho informe la Comisión ha considerado los diversos antecedentes y documentos confeccionados en esta Subdirección General relacionados con el tema, Informes de la Dirección de Infraestructura Tecnológica y también se ha seguido la Guía de Desarrollo del Plan de Continuidad de Negocio presentada como tesis en la Escuela Universitaria de Informática de la Universidad Politécnica de Madrid. En todos esos documentos se recomienda que el desarrollo del Plan de la AFIP debería ser concretado en un Plan de Gestión plurianual, estimando su realización en 4 fases: 1.- Análisis de impacto y de riesgos. 11.- Selección de la estrategia. 111.- Desarrollo del plan para la continuidad de operación de los servicios. IV.- Pruebas y mantenimiento del plan. 149 Comentario de AGN: El organismo reconoce la falta de un Plan de Continuidad de Servicios con la creación de una Comisión (mediante la disposición 186/12) que se ocupará de redactar un informe que analice los factores intervinientes. La creación de la mencionada comisión es posterior al periodo auditado y su trabajo será motivo de una posterior auditoria. En consecuencia se mantiene la observación. 4.3.5 Garantizar 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 proceso incluye el establecimiento y mantenimiento de roles y responsabilidades, políticas, estándares y procedimientos de TI. La administración de la seguridad también incluye la implementación de los controles de acceso lógico que garantizan que el ingreso a los sistemas, datos y programas está limitado a los usuarios autorizados, los monitoreos y pruebas periódicas así como 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: Administrado. Las responsabilidades sobre la seguridad de TI son asignadas, administradas e implementadas de forma clara. Regularmente se lleva a cabo un análisis de impacto y de riesgos de seguridad. Las políticas y prácticas de seguridad se complementan con referencias específicas de seguridad. El contacto con métodos para promover la conciencia de la seguridad es obligatorio. La identificación, autenticación y autorización de los usuarios está estandarizada. La certificación en seguridad es buscada 150 por parte del personal que es responsable de la auditoría y la administración de la seguridad. Las pruebas de seguridad se hacen utilizando procesos estándares y formales que llevan a mejorar los niveles de seguridad. Los procesos de seguridad de TI están coordinados con la función de seguridad de toda la organización. Los reportes de seguridad están ligados con los objetivos del Organismo. La capacitación sobre seguridad de TI se planea, administra e imparte para todo el Organismo de manera que responda a las necesidades del mismo y a los perfiles de riesgo de seguridad. Observaciones: La administración de la seguridad de los sistemas está a cargo del Departamento de Seguridad Informática que depende de la Dirección de Infraestructura Tecnológica. Este departamento está dividido en dos Divisiones: Monitoreo y Detección Administración de Accesos No tiene bajo su responsabilidad la seguridad física de la sala cofre donde se encuentran los servidores del Organismo. Existe un Comité de Seguridad compuesto por los titulares de las direcciones interesadas y presidido por la Subdirección General de Sistemas y Telecomunicaciones. La posición actual del Departamento de Seguridad Informática no se considera la más apropiada dentro de la organización porque depende de la Dirección de Infraestructura Tecnológica y esta situación podría influir en un correcto impacto horizontal hacia todo el Organismo de las decisiones tomadas por el citado departamento. Existe un Manual aprobado de Políticas de Seguridad de la Información. Desde su publicación no existieron revisiones ni modificaciones. Las actualizaciones o ampliaciones de su contenido se realizan mediante Instrucciones Generales que son impulsadas y aprobadas por el Comité de Seguridad de la Información. Los usuarios acceden a las distintas aplicaciones a través del Sistema Único de Autenticación, este es un sistema que permite que el usuario sólo necesite autenticarse una vez para acceder a los sistemas que tiene autorizados. Este está vinculado con el sistema SARHA de administración de RR HH. 151 Se contemplan también las situaciones de baja de personal, licencias ordinarias y traslado de dependencias. Aclaraciones y/o comentarios del área responsable: Existen revisiones de las Políticas de Seguridad de la Información que son las que originan las actualizaciones o ampliaciones de su contenido, concretadas a través de Instrucciones Generales. Con respecto a la seguridad física de la sala cofre, el Departamento Seguridad Informática administra los accesos, mientras que por cuestiones operativas, la seguridad física de la Sala es administrada por la Dirección de Operaciones Informáticas. Personal dependiente de esta Dirección trabaja físicamente en modalidad 7x24 en el área contigua a la Sala Cofre, y realiza el monitoreo en tiempo real de la Sala y de su infraestructura. Comentario de AGN: La respuesta del organismo no modifica las observaciones realizadas, por lo tanto se mantienen las mismas. 4.3.6 Identificar y asignar costos Objetivo de control: Se debe implementar un sistema de imputación de costos que garantice que se registren, calculen y asignen los costos de acuerdo con el nivel de detalle requerido y el ofrecimiento de servicio adecuado. Este proceso incluye la construcción y operación de un sistema para capturar, distribuir y reportar costos de TI a los usuarios de los servicios. Este objetivo de control afecta, primariamente: la eficiencia la confiabilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de madurez: Repetible. Hay conciencia general de la necesidad de identificar y asignar costos. La asignación de costos está basada en los del hardware. No hay capacitación o comunicación formal sobre la identificación de costos estándar y sobre los procedimientos de asignación. No está determinada la responsabilidad sobre la recopilación o la asignación de los costos, particularmente del software desarrollado. Observaciones: Los costos de TI asociados al desarrollo de sistemas no son identificados para ser imputados a las áreas correspondientes. 152 Los costos de los servicios de TI no están vinculados a los procesos del Organismo, no existe un modelo definido para la asignación de los mismos. Solamente se imputan a las áreas respectivas aquellos vinculados a las compras de hardware que patrimonialmente queden a su cargo. Aclaraciones y/o comentarios del área responsable: Se comparte la observación. Se analizará la manera de presupuestar los costos de desarrollo Comentario de AGN: El organismo acepta las observaciones realizadas por lo tanto se mantienen las mismas. Las mejoras a realizar se evaluarán en una próxima auditoría. 4.3.7 Educación y capacitación de los usuarios Objetivo de control: Se debe establecer y mantener un plan integral de capacitación y desarrollo. Para ello, se requieren identificar las necesidades de entrenamiento de cada grupo. Además, este proceso debe incluir la definición y ejecución de una estrategia para llevar a cabo un entrenamiento efectivo y para medir los resultados. Este objetivo de control afecta, primariamente: la eficacia y en forma secundaria: la eficiencia Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de madurez: Definido. El programa de entrenamiento y educación se institucionaliza y comunica, y los empleados y gerentes identifican y documentan las necesidades de entrenamiento. Los procesos de entrenamiento y educación se estandarizan y documentan. Para soportar el programa de entrenamiento y educación, se establecen presupuestos, recursos, instructores e instalaciones. Se imparten clases formales sobre conducta ética y sobre conciencia y prácticas de seguridad en los sistemas. La mayoría de los procesos de entrenamiento y educación son monitoreados, pero no todas las desviaciones son susceptibles de detección por parte de la gerencia. El análisis sobre problemas de entrenamiento y educación sólo se aplica de forma ocasional. Observaciones: El relevamiento de las necesidades de capacitación y de la organización de los distintos cursos es responsabilidad de la Dirección de Capacitación. 153 La recolección de las necesidades de capacitación de las distintas áreas del Organismo se realiza mediante encuestas automatizadas Se otorgan becas para capacitar externamente a los agentes (el capacitado de dictar cursos de lo aprendido a solicitud del Organismo), y se contratan cursos de capacitación con los proveedores cuando se adquiere nueva infraestructura. La capacitación interna se realiza con personal propio, y se dictan cursos por medio de procedimientos WEB utilizando una herramienta llamada CAMPUS. En las áreas de desarrollo se notó falta de cursos de alto nivel para los agentes con mayor capacidad técnica. En estas mismas áreas la cantidad acotada de personal no permite que el mismo pueda dedicar las horas necesarias para capacitación. Aclaraciones y/o comentarios del área responsable: No se comparte lo observado. En los pliegos de compra de software está prevista la capacitación para el personal de esta Subdirección General. Asimismo las necesidades de capacitación de las distintas áreas de esta Subdirección General son canalizadas a través de la Dirección de Infraestructura Tecnológica, quien se encarga de adquirir la capacitación acorde a las necesidades funcionales. Comentario de AGN: Si bien en los pliegos de compra de software está prevista la capacitación, no existen ni se planifican capacitaciones posteriores que permitan mantener o aumentar las competencias del personal. En consecuencia se mantiene las observaciones. 4.3.8 Administrar la mesa de servicio y los incidentes Objetivo de control: Responder de manera oportuna y efectiva a las consultas de los usuarios de TI, requiere de una mesa de servicio bien diseñada y ejecutada, y de un proceso de administración de incidentes. Este proceso incluye la creación de una función de mesa de servicio con registro, escalamiento de incidentes, análisis de tendencia, análisis causaraíz y resolución. Los beneficios incluyen el incremento en la productividad gracias a la resolución rápida de consultas. Además, permite identificar la causa raíz (tales como un pobre entrenamiento a los usuarios) a través de un proceso de reporte efectivo. Este objetivo de control afecta, primariamente: 154 la efectividad la eficacia Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de madurez: Definido. Se reconoce y se acepta la necesidad de contar con una función de mesa de servicio y un proceso para la administración de incidentes. Los procedimientos se estandarizan y documentan, pero se lleva acabo entrenamiento informal. Se deja la responsabilidad al individuo de conseguir entrenamiento y de seguir los estándares. Se desarrollan guías de usuario y preguntas frecuentes (FAQs), pero los individuos deben encontrarlas y puede ser que no las sigan. Las consultas y los incidentes se rastrean de forma manual y se monitorean de forma individual, pero no existe un sistema formal de reporte. No se mide la respuesta oportuna a las consultas e incidentes. Los usuarios han recibido indicaciones claras de dónde y cómo reportar problemas e incidentes. Observaciones: La función la realiza en su mayor parte la División Mesa de Ayuda que depende del Departamento de Soporte Técnico. Para el registro de los incidentes se utiliza una herramienta llamada Sistema de Registración de Incidentes (SRI). Estos pueden llegar vía telefónica, o por correo electrónico. En ambos casos el sistema genera un ticket con un número único para su identificación. Si es resuelto en el momento, el incidente es cerrado por el operador, si este no lo puede resolver puede consultarlo al personal con mayor experiencia sobre el tema, y si aún así no puede ser resuelto se deriva el mismo al área que corresponda. Al recibir la conformidad, el operador cierra el ticket. Si bien el sistema SRI puede discriminar cada ticket por importancia, esta clasificación no es utilizada para asignar un orden en la resolución de incidentes, sino que son resueltos a medida que ingresan al sistema. En el sistema no queda almacenada la conformidad del usuario sobre la solución del incidente. 155 El sistema almacena información sobre distintos parámetros que permiten realizar informes sobre el desempeño de la Mesa de Ayuda, pero los mismos sólo se realizan si son solicitados con algún fin específico. No se realizan encuestas de satisfacción del usuario. Aclaraciones y/o comentarios del área responsable: Se comparte parcialmente lo observado en cuanto a que si bien el sistema SRI puede discriminar cada ticket por importancia, esta clasificación no es utilizada para asignar un orden en la resolución de incidentes, sino que son resueltos a medida que ingresan al sistema. Se posee una clasificación de los eventos críticos los cuales tienen prioridad de resolución (ej. Virus, Factura Electrónica, Osiris), utilizándose dicha prioridad para el tratamiento de los incidentes. Además, se consideran los eventos repetitivos que aluden a un único inconveniente producido por la salida de servicios de un sistema. Los mismos son cerrados en forma general al solucionarse el inconveniente. También se comparte parcialmente lo observado en relación a que en el sistema no queda almacenada la conformidad del usuario sobre la solución del incidente. No está como condición obligatoria previa al cierre del ticket la conformidad del usuario, ya que ante eventos generales de alta repetición, se consulta una muestra de casos y se procede al cierre del resto. En la mayoría de los casos relacionados a eventos particulares, la conformidad queda en la interacción con los usuarios. Por último, la Mesa de Ayuda realiza un chequeo de los tickets que aun no fueron cerrados por los usuarios solicitando su conformidad para el cierre. En caso de no recibir respuesta se procede a cerrarlos de oficio pasados los 90 días. No se comparte lo observado en cuanto a que el sistema almacena información sobre distintos parámetros que permiten realizar informes sobre el desempeño de la Mesa de Ayuda, pero los mismos sólo se realizan si son solicitados con algún fin específico. Los informes estadísticos gerenciales sobre el desempeño de la Mesa de Ayuda, se encuentran disponibles en forma on-line para nivel de Departamento y de Dirección. Cabe 156 señalar que, este método reemplazó a los informes en papel que eran emitidos de manera periódica. Comentario de AGN: El organismo acepta que no utiliza la discriminación de cada ticket según la clasificación disponible en el SRI. Durante las tareas de campo no se encontró evidencia de un procedimiento formal de asignación de prioridad de solicitudes. Reconoce además que para el cierre del ticket no es condición necesaria la aprobación del usuario sobre la resolución del mismo. En consecuencia se mantiene la observación. 4.3.9 Administrar la configuración Objetivo de control: Se deben implementar controles que identifiquen y registren todos los bienes de Tecnología de la Información y su ubicación física, y un programa de verificación regular que confirme su existencia. Este programa debe incluir la recolección de información de la configuración inicial, el establecimiento de normas, la verificación y auditoría de la información de la configuración y la actualización del repositorio de configuración conforme se necesite. Este objetivo de control afecta, primariamente: la efectividad y en forma secundaria: la eficiencia la disponibilidad la confiabilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de madurez: Definido. Los procedimientos y las prácticas de trabajo se han documentado, estandarizado y comunicado, pero la capacitación y la aplicación de estándares dependen del individuo. Además se han implementado herramientas de administración de configuración entre plataformas. Es poco probable detectar las desviaciones de los procedimientos y las verificaciones físicas se realizan de manera inconsistente. Se lleva a cabo algún tipo de automatización para ayudar a rastrear cambios 157 en el software o en el hardware. La información de la configuración es utilizada por los procesos interrelacionados. Observaciones: Con respecto al parque informático de PC de usuarios, existen dos ámbitos bien diferenciados, por un lado todos los equipos ingresados al dominio de la AFIP (aproximadamente un 80%) y por otro los que están fuera de él ubicados principalmente el edificio de Hipólito Yrigoyen (aproximadamente 370 equipos). No existe una herramienta que permita monitorear cambios en el software instalado de las estaciones de trabajo. Tampoco existe una herramienta que permita actualizar los sistemas operativos de forma automática. Los equipos nuevos son entregados con una configuración que le es entregada al proveedor para que él mismo las instale. Si bien en la actualidad los usuarios de dominio no tienen privilegios de administración de sus equipos, los que están fuera de él podrían tener estos privilegios, lo que tendría como consecuencia la falta de control del software instalado en los mismos. No existen mecanismos físicos que impidan el reemplazo de componentes internos de las estaciones de trabajo por personal no autorizado. Aclaraciones y/o comentarios del área responsable: Se comparte parcialmente lo observado en cuanto a que en relación al parque informático de PCs de usuarios, existen dos ámbitos bien diferenciados, por un lado todos los equipos ingresados al dominio de la AFIP (aproximadamente un 80%) y por otro los que están fuera de él ubicados principalmente en el edificio de Hipólito Irigoyen (aproximadamente 370 equipos). Actualmente el parque de equipamiento ingresado a dominio alcanza al 86%. En cuanto a los equipos que están ubicados en el Edificio de Hipólito Yrigoyen (370 equipos), entendemos que se trata de un error de tipeo (Hipólito Yrigoyen 370 es la dirección del edificio central). También se comparte parcialmente lo observado en relación a: - Inexistencia de una herramienta que permita monitorear cambios en el software instalado de las estaciones de trabajo - Inexistencia de una herramienta que permita actualizar los sistemas operativos de forma automática. 158 - Los equipos nuevos son entregados con una configuración que le es entregada al proveedor para que él mismo las instale. Si bien en la actualidad los usuarios de dominio no tienen privilegios de administración de sus equipos, los que están fuera de él podrían tener estos privilegios, lo que tendría como consecuencia la falta de control del software instalado en los mismos. Desde hace dos años se está utilizando la herramienta WSUS en aproximadamente 10.000 equipos (56% del parque) para la distribución de parches de seguridad en las estaciones de trabajo. Por otra parte se encuentra en proceso de adquisición el software de administración de la infraestructura de estaciones de trabajo distribuidas en AFIP. Una vez implementada, y en conjunto con la disponibilidad de dominio en la totalidad de los equipos AFIP, se podrá realizar la instalación de software en forma centralizada aplicando políticas comunes. El mismo software permitirá registrar cualquier cambio o modificación de componentes de HW realizado en el equipo. Comentario de AGN: Si bien AFIP está trabajando en la regularización de la situación del parque informático, hay un porcentaje alto de equipos que todavía no cuentan con las herramientas mencionadas. En consecuencia se mantiene la observación. Las mejoras a realizar se evaluarán en una próxima auditoría. 4.3.10 Administración de problemas Objetivo de control: Se debe implementar un sistema de administración de problemas que registre y de respuesta a todos los incidentes. El proceso también incluye la identificación de recomendaciones para la mejora, el mantenimiento de registros y la revisión de estatus de las acciones correctivas. Este objetivo de control afecta, primariamente: la eficacia la eficiencia y en forma secundaria: la disponibilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo 159 Nivel de madurez: Definido. Se acepta la necesidad de un sistema integrado de administración de problemas y se evidencia con el apoyo de la gerencia y la asignación de presupuesto para personal y capacitación. Se estandarizan los procesos de escalamiento y resolución de problemas. El registro y rastreo de problemas y de sus soluciones se dividen dentro del equipo de respuesta, utilizando las herramientas disponibles sin centralizar. Es poco probable detectar las desviaciones de los estándares y de las normas establecidas. La información se comparte entre el personal de manera formal y proactiva. La revisión de incidentes y los análisis de identificación y resolución de problemas son limitados e informales. Observaciones: Los problemas son reportados por los usuarios por medio de llamadas telefónicas o a través de correos electrónicos a Mesa de Ayuda donde el operador genera un ticket. La División de Mesa de Ayuda no tiene un segundo nivel de escalamiento de problemas, sino que cuenta con referentes. Los incidentes que pueden presentarse son derivados a las áreas correspondientes cuando los operadores no pueden resolverlos. De esta forma se recargan las tareas de sectores como los de desarrollos que deben dedicar personal y recursos para actividades que no figuran en sus misiones y funciones. La aceptación de la solución del problema la realiza el usuario por medio de un correo electrónico no quedando dicha constancia en el SRI. El cierre del ticket en el sistema lo realiza el operador en forma manual cuando recibe el correo electrónico de parte del usuario con la aprobación de la solución brindada. Aclaraciones y/o comentarios del área responsable: Se comparte parcialmente lo observado en cuanto a que los problemas son reportados por los usuarios por medio de llamadas telefónicas o a través de correos electrónicos a Mesa de Ayuda donde el operador genera un ticket. Si el usuario llama por teléfono es el operador quien genera el ticket; en el caso en que envíen un correo electrónico a la cuenta [email protected] es el propio sistema SRI el que genera el ticket en forma automática. También se comparte parcialmente lo observado en relación a que la División de Mesa de Ayuda no tiene un segundo nivel de escalamiento de problemas, sino que cuenta con referentes; y que los incidentes que pueden presentarse son derivados a las áreas 160 correspondientes cuando los operadores no pueden resolverlos, recargando las tareas de sectores como los de desarrollo que deben dedicar personal y recursos para actividades que no figuran en sus misiones y funciones. Al respecto se aclara que la División Mesa de Ayuda tiene segundo nivel de escalamiento de problemas. Asimismo, el Organismo se encuentra en un proceso de madurez que permitirá a la Mesa de Ayuda reducir el escalamiento de eventos, lo que se lograría manteniendo actualizada la base de conocimientos, por parte de las distintas áreas de servicio y manteniendo capacitados a los agentes de la citada Mesa de Ayuda con los nuevos proyectos, sistemas o normativas. No se comparte lo observado en cuanto a que la aceptación de la solución del problema la realiza el usuario por medio de un correo electrónico no quedando dicha constancia en el SRI. Todos los usuarios tienen habilitado por default el sistema SRI, por lo que cada uno de ellos puede crear o cerrar un evento dentro del mismo. Asimismo, el usuario puede cerrar el evento enviando una respuesta indicando en el asunto el nro. de ticket, el cual es tomado por el sistema, registrando el cierre en forma manual. En ambas situaciones, la aceptación de la solución del problema queda registrada en el SRI. Comentario de AGN: El organismo reconoce en su respuesta al punto 4.3.8 que “No está como condición obligatoria previa al cierre del ticket la conformidad del usuario…”. Por lo tanto se mantienen las observaciones. 4.3.11 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. El proceso de administración de información también incluye el establecimiento de procedimientos efectivos para administrar la librería de medios de soporte para el respaldo y la recuperación de datos, así como su eliminación apropiada. Este objetivo de control afecta, primariamente: 161 la integridad la confiabilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de madurez: Definido. Se entiende y acepta la necesidad de la administración de datos, tanto dentro de TI como a lo largo de toda la organización. Se establece la responsabilidad sobre la administración de los datos. Se asigna la propiedad sobre los datos a la parte responsable que controla la integridad y la seguridad. Los procedimientos de administración de datos se formalizan dentro de TI y se utilizan algunas herramientas para respaldos/recuperación y desecho de equipo. Se lleva a cabo algún tipo de monitoreo sobre la administración de datos. Se definen métricas básicas de desempeño. Comienza a aparecer el entrenamiento sobre administración de información. Observaciones: La propiedad de los datos internos esta formalmente asignada a las áreas definidoras No existe un diccionario de datos del Organismo, ni están definidos sus niveles de criticidad. En los casos en que se verifica que los archivos de datos recibidos de otros organismos contengan errores, se solicita que sean reenviados. En aquellos casos en que el archivo reenviado tenga el mismo nombre que el recibido con errores, se guarda en el repositorio agregándole un sufijo secuencial para diferenciarlo del primero. No está definido formalmente el tiempo que dichos archivos con datos erróneos deben permanecer en el repositorio. Aclaraciones y/o comentarios del área responsable: El 10 de enero de 2013 se puso en producción un servicio interactivo, al que se accede a través del SUA (Sistema Único de Autenticación), denominado Clasidat cuyo objetivo es la documentación, descripción y clasificación de la Información estructurada en bases de datos. Este servicio fue desarrollado para cumplir con la IG N° 5/12 (AFIP) de Clasificación de la Información. Tal como se indica en la mencionada IG, las áreas definidoras de sistemas y procesos de información en conjunto con las áreas que desarrollan los mismos, utilizarán Clasidat 162 para identificar cada instancia de base de datos, las tablas que las componen y sus campos, indicando tanto su descripción como su criticidad. Comentario de AGN: Se mantienen las observaciones. Para el período auditado, no se encontraba vigente la IG N° 5/12 (AFIP) ni la implementación del sistema “Clasidat”. Las mejoras expresadas se evaluarán en una próxima auditoría. 4.3.12 Administración de instalaciones Objetivo de control: La protección del equipo de cómputo y del personal, requiere de instalaciones bien diseñadas y administradas. Se deben instalar controles ambientales y físicos adecuados cuya revisión se efectúe periódicamente a fin de determinar su correcto funcionamiento. Este objetivo de control afecta, primariamente: la integridad la disponibilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de madurez: Definido. Se entiende y acepta a lo largo de todo el Organismo la necesidad de mantener un ambiente de cómputo controlado. Los controles ambientales, el mantenimiento preventivo y la seguridad física cuentan con presupuesto autorizado y verificado por la gerencia. Se aplican restricciones de acceso, permitiendo el ingreso a las instalaciones de cómputo sólo al personal autorizado. Los visitantes son acompañados. Las instalaciones físicas mantienen un perfil bajo y no son reconocibles de manera sencilla. Las autoridades monitorean el cumplimiento con los reglamentos de salud y seguridad. Observaciones: La AFIP dispone de una sala cofre donde se almacenan los servidores y equipos de comunicaciones principales. La misma se encuentra sellada y protege a todos los equipos contra incendios, humo, gases corrosivos, interferencias electromagnéticas, filtraciones, accesos indebidos, etc. Si bien el acceso a la sala cofre se controla mediante el uso de una tarjeta magnética y un dispositivo de lectura de huellas dactilares, no se observó la existencia de un registro de visitantes al centro de cómputos. 163 El Organismo cuenta con 3 generadores autónomos y 2 sistemas de UPS independientes que permiten el funcionamiento de todo el centro de cómputos en el caso de falta de suministro de energía eléctrica. Todos los parámetros físicos del centro de cómputos (energía, humedad, temperatura, etc.) se encuentran monitoreados en forma permanente. El Organismo no dispone de un sitio alternativo de procesamiento para el caso en que el centro de cómputos deje de operar. No existe un plan de contingencia que indique los procedimientos necesarios para los distintos escenarios que puedan presentarse. Aclaraciones y/o comentarios del área responsable: Si bien al momento de la auditoría no existía un registro de visitantes al Centro de Cómputos, se ha elaborado un instructivo que se encuentra a la firma y contempla la registración de las personas que visitan el Data Center. En cuanto a lo observado en relación al sitio alternativo y al Plan de Contingencia, se remite a lo informado en el punto 4.3.4 precedente. Comentario de AGN: El organismo acepta las observaciones realizadas por lo tanto se mantienen las mismas. Las mejoras a realizar se evaluarán en una próxima auditoría. 4.3.13 Administración de operaciones Objetivo de control: Un procesamiento completo y apropiado de la información requiere su efectiva administración y el mantenimiento del hardware involucrado. Este proceso incluye la definición de políticas y procedimientos de operación para una administración efectiva del procesamiento programado, protección de datos de salida sensitivos, monitoreo de infraestructura y mantenimiento preventivo de hardware. Este objetivo de control afecta primariamente: la efectividad la eficiencia y en forma secundaria: la integridad la disponibilidad 164 Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de madurez: Administrado. Las operaciones de cómputo y las responsabilidades de soporte están definidas de forma clara y la propiedad está asignada. Las operaciones se soportan a través de presupuestos de recursos para gastos de capital y de recursos humanos. La capacitación se formaliza y está en proceso. Las programaciones y las tareas se documentan y comunican, tanto a la función interna de TI como a los usuarios. Es posible medir y monitorear las actividades diarias con acuerdos estandarizados de desempeño y de niveles de servicio establecidos. Cualquier desviación de las normas establecidas es atendida y corregida de forma rápida. La gerencia monitorea el uso de los recursos de cómputo y la terminación del trabajo o de las tareas asignadas. Existe un esfuerzo permanente para incrementar el nivel de automatización de procesos como un medio de mejora continua. Se establecen convenios formales de mantenimiento y servicio con los proveedores. Hay una completa alineación con los procesos de administración de problemas, capacidad y disponibilidad, soportados por un análisis de causas de errores y fallas. Observaciones: Las tareas que comprenden al procesamiento son realizadas por la División de Operación de Sistemas que depende del Departamento de Operaciones. Los procedimientos se encuentran definidos formalmente por una Instrucción General que aprueba el Calendario Operativo de Gestión en el cual se establecen las frecuencias y parámetros de las tareas a realizar. Existen procedimientos formalmente definidos para el monitoreo de la infraestructura de TI, y para el control de los eventos que se produzcan. Mediante herramientas de monitoreo (PATROL y TMART) se controlan todos los parámetros necesarios (uso de memoria, espacio en disco, servicios en línea, parámetros ambientales, sistema de energía, etc.) para un correcto funcionamiento del centro de cómputos. La División Control de Datos y Procesos se encarga del pase a producción de la información recibida de organismos externos (ANSES, Banco Nación, etc.) controlando la integridad de la información recibida y poniéndola disponible para su procesamiento. Aclaraciones y/o comentarios del área responsable: De acuerdo con lo observado. 165 Comentario de AGN: El organismo acepta las observaciones realizadas por lo tanto se mantienen las mismas. 4.4 Monitorear y evaluar 4.4.1 Monitorear y evaluar el desempeño de TI Objetivo de control: Una efectiva administración del desempeño de TI requiere un proceso de monitoreo definido formalmente. Éste debe incluir la definición de indicadores de desempeño relevantes, reportes sistemáticos y oportunos y tomar medidas expeditivas cuando existan desviaciones. El monitoreo se requiere para garantizar que las cosas correctas se hagan y que estén de acuerdo con el conjunto de direcciones y políticas. Este objetivo de control afecta, primariamente: la efectividad 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. Se han identificado algunas mediciones básicas a ser monitoreadas. Los métodos y las técnicas de recolección y evaluación existen, pero los procesos no se han adoptado en todo el Organismo. La interpretación de los resultados del monitoreo se basa en la experiencia de individuos clave. Herramientas limitadas son seleccionadas y aplicadas en algunas áreas para recolectar información, pero esta recolección no se basa en un enfoque planeado. Observaciones: Existen diferencias en el monitoreo de TI según el sector de que se trate. En las áreas de desarrollo y mantenimiento de software no se ha normalizado un proceso de administración de proyectos que sea común a todas. Se utilizan distintas herramientas y criterios para el seguimiento de los proyectos. 166 La metodología de Ciclo de Vida de Desarrollo de Sistemas vigente permite la adopción de documentación entregable a criterio de cada área de desarrollo. Esto impide la uniformidad de información, y la documentación realizada difiere en estructura y calidad, según el sector de que se trate. La ausencia de un marco de trabajo de aseguramiento de la calidad, basado en estándares predefinidos, no permite mediciones de desempeño, que sean obtenidas mediante la generación de indicadores, provenientes de diversos puntos de control interno, en los procesos de desarrollo. En las áreas dependientes de la Dirección de Infraestructura, se ha establecido un monitoreo en tiempo real, con estándares de desempeño preestablecidos empleando herramientas automáticas. Los resultados obtenidos se utilizan para tomar acciones preventivas o correctivas según el caso. Los niveles de servicios los ha definido la Subdirección General de Sistemas y Telecomunicaciones. No se han formalizado acuerdos de niveles de servicio con los usuarios internos. Por otra parte, el monitoreo de la infraestructura para gestión de datos está a cargo de la División de Monitoreo y Gestión del Servicio. Mediante el cumplimiento de un procedimiento formalizado, procura la operación continua y la disponibilidad de todos los servicios por ellos suministrados. Se emiten alertas cuando se producen variaciones con respecto a los estándares fijados como óptimos. Cada incidente se identifica unívocamente. Si bien el seguimiento del incidente está normado por un procedimiento formalizado, el mismo es manual y el intercambio de información con las áreas responsables de solucionar el problema se lleva a cabo mediante correos electrónicos o comunicaciones telefónicas. Al no contar con una herramienta integrada que lo integre y que incluya el escalamiento y las comunicaciones inter áreas, se dificulta el rastreo de información histórica para un análisis posterior. Aclaraciones y/o comentarios del área responsable: No se comparte lo observado en cuanto a que si bien el seguimiento del incidente está normado por un procedimiento formalizado, el mismo es manual y el intercambio de información con las áreas responsables de solucionar el problema se lleva a cabo mediante correos electrónicos o 167 comunicaciones telefónicas. Además se observa que por no contar con una herramienta integrada que lo integre y que incluya el escalamiento y las comunicaciones inter áreas, se dificulta el rastreo de información histórica para un análisis posterior. Al respecto se aclara que toda la información del evento (seguimiento del incidente) se guarda de forma estructurada, permitiendo el acceso y búsqueda de datos para análisis posteriores. Además de registrar todo lo expuesto por las áreas de soporte se complementa con reportes de monitoreo. Se cuenta con una herramienta para la generación, administración, comunicación y seguimiento de los eventos por incidencias y/o problemas. Estos eventos alimentan una base de conocimiento, cuya información se encuentra disponible en forma en-line. Se utiliza también un tablero de disponibilidad de sistemas que se actualiza con la información de estos eventos, y permite ver en forma instantánea los sistemas afectados y los ya tratados. Dicha herramienta hace uso del correo electrónico para la comunicación de los eventos con el objeto de evitar la dependencia de una interface web, permitiendo a cualquier destinatario tomar conocimiento y acceder a toda la información del mismo, incluso desde las terminales blackberry utilizadas por la Organización. Adicionalmente, se utiliza comunicación telefónica para los casos de los eventos críticos que necesiten de una intervención urgente por parte de las áreas de Soporte Técnico. Si bien existen los sistemas de reporte de Monitoreo, el SRI, RFC y el SPP como herramientas de registro de eventos y acciones, cabe señalar que el mail y el teléfono se siguen utilizando como un método ampliatorio insustituible. Por todo lo expuesto y a modo de ejemplo, se informa lo registrado en el año 2012, en los siguientes sistemas: a) SRI: un total de 55.046 tickets, siendo solucionados en 1er. Nivel de servicio 27.364 (49.71%) Y en 2do. Nivel de servicio 27.682 (50.29%). b) RFC: 11.804 requerimientos de cambios. c) SPP: un total de 333.373 solicitudes de ejecución, de las cuales 29.046 fueron dadas de 168 alta en dicho período. d) Reporte de monitoreo: 3.501 tickets. De los cuales 3340 eran para áreas internas de AFIP (Áreas de Soporte de Hardware, de Base, de Desarrollo, de Seguridad Informática, etc.) y 161 para Organismos Externos (ANSES, Entidades de Pago, Red Link, Banelco, etc.). Comentario de AGN: Se mantiene la observación. El marco de monitoreo es limitado a la infraestructura tecnológica. No abarca lo relativo a desarrollo y mantenimiento de aplicaciones. Faltan políticas y procedimientos de administración de proyectos y un marco de aseguramiento de la calidad que abarquen a todos los proyectos de la organización de TI. En relación al marco de monitoreo de la infraestructura, se verificaron procesos manuales para poder integrar los sistemas funcionalmente. 4.4.2 Monitorear y evaluar el control interno Objetivo de control: Establecer un programa de control interno efectivo para TI requiere un proceso bien definido de monitoreo. Este proceso incluye el monitoreo y el reporte de las excepciones de control, resultados de las auto-evaluaciones y revisiones por parte de terceros. Un beneficio clave del monitoreo del control interno es proporcionar seguridad respecto a las operaciones eficientes y efectivas y el cumplimiento de las leyes y regulaciones aplicables. Este objetivo de control afecta, primariamente: la efectividad la eficiencia y en forma secundaria: la confidencialidad la integridad la disponibilidad el cumplimiento la confiabilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo 169 Nivel de Madurez: Administrado y medible. La gerencia tiene implantado un marco de trabajo para el monitoreo del control interno de TI. La organización ha establecido niveles de tolerancia para el proceso de monitoreo del control interno. Se han implantado herramientas para estandarizar evaluaciones y para detectar de forma automática las excepciones de control. Se ha establecido una función formal para el control interno de TI, con profesionales especializados y certificados que utilizan un marco de trabajo de control formal avalado por la alta dirección. Un equipo calificado de TI participa de forma rutinaria en las evaluaciones de control interno. Se ha establecido una base de datos de métricas para información histórica sobre el monitoreo del control interno. Se realizan revisiones entre pares para verificar el monitoreo del control interno. Observaciones: Hay normativa debidamente aprobada que determina las “Misiones y funciones de la Unidad de Auditoría Interna”, del cual depende el Departamento de Auditoría de Sistemas Informáticos. Existe un marco de trabajo para el monitoreo del control interno de TI, siguiendo el cumplimiento de la resolución de SIGEN 48/05 respecto a las Normas de Control Interno para Tecnología de la Información y los lineamientos estratégicos dispuestos en el Anexo I del decreto 378/2005 del Plan Nacional de Gobierno Electrónico. La metodología está establecida por el Manual de Auditoría Interna de la Unidad de Auditoría Interna de la Administración Federal de Ingresos Públicos de acuerdo con la resolución de SIGEN 152/02 “Normas de Auditoría Interna Gubernamental” según en el marco de la ley 24.156 de Administración Financiera y de los Sistemas de Control del Sector Público Nacional. El Organismo cuenta con un Departamento de Auditoria de Sistemas Informáticos, dependiente de la Subdirección General de Auditoría Interna, que cuenta con profesionales internacionalmente certificados en Auditoría de Sistemas (CISA) y Certificación de Riesgos (CRISC). Se ha adquirido una herramienta de Gobierno Corporativo, Administración de Riesgos y Cumplimiento Regulatorio denominada GRC. A través de ésta, se lleva a cabo un análisis de riesgo donde se identifican la mayoría de los procesos involucrados en la operatoria de 170 TI, la evaluación de los riesgos asociados a cada proceso (la magnitud de la pérdida o daño posible y la probabilidad que dicha pérdida o daño llegue a ocurrir). En función de la criticidad que refleje cada caso individual, se asigna prioridades en el Plan Ciclo de Auditoría, donde se fija la frecuencia de la revisión y la carga de recursos a asignar (principalmente, horas hombre). El Plan Ciclo de Auditoría contempla información histórica de 5 (cinco) años hacia atrás del período presente y una proyección de 5 (cinco) años hacia adelante. Están contempladas un promedio de 8.386 horas de auditoría para cada año. Aclaraciones y/o comentarios del área responsable: No hay comentarios del Organismo. Comentario de AGN: Ante la ausencia de comentario se considera que se acepta la observación. 4.4.3 Garantizar el cumplimiento con requerimientos externos Objetivo de control: Una supervisión efectiva del cumplimiento regulatorio requiere del establecimiento de un proceso independiente de revisión para garantizar el cumplimiento de las leyes y regulaciones. Este proceso incluye la definición de una declaración de auditoría, independencia de los auditores, ética y estándares profesionales, planeación, desempeño del trabajo de auditoría y reportes y seguimiento a las actividades de auditoría. El propósito de este proceso es proporcionar un aseguramiento positivo relativo al cumplimiento de TI de las leyes y regulaciones. Este objetivo de control afecta, primariamente: el cumplimiento y en forma secundaria: la confiabilidad Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo Nivel de Madurez: Repetible. Existe el entendimiento de la necesidad de cumplir con los requerimientos externos y la necesidad se comunica. En los casos en que el cumplimiento es recurrente se han desarrollado procedimientos individuales al respecto. No existe un enfoque estándar. Hay dependencia del conocimiento y responsabilidad de los individuos y 171 los errores son posibles. Se brinda entrenamiento informal respecto a los requerimientos externos y a los temas de cumplimiento. Observaciones: No se encontró un catálogo de requerimientos legales y regulatorios relacionados con la prestación del servicio de TI ni un procedimiento formal para su desarrollo. No existen informes sobre el cumplimiento de las actividades de TI con los requerimientos externos legales y regulatorios. Aclaraciones y/o comentarios del área responsable: A raíz de una observación practicada por la Unidad de Auditoría Interna, personal de la Dirección de Infraestructura Tecnológica se encuentra analizando el tema. Comentario de AGN: La respuesta del organismo no modifica las observaciones realizadas, por lo tanto se mantienen las mismas. 4.4.4 Proporcionar gobierno de TI Objetivo de control: El establecimiento de un marco de trabajo de gobierno efectivo, incluye la definición de estructuras, procesos, liderazgo, roles y responsabilidades organizacionales para garantizar que las inversiones en TI estén alineadas y de acuerdo con las estrategias y objetivos del Organismo. Este objetivo de control afecta, primariamente: la efectividad 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. Existe conciencia sobre los temas de gobierno de TI. Las actividades y los indicadores de desempeño del gobierno de TI, los cuales incluyen procesos planeación, entrega y supervisión de TI, están en desarrollo. Los procesos de TI 172 seleccionados se identifican para ser mejorados con base en decisiones individuales. Se han identificado mediciones básicas para el gobierno de TI, así como métodos de evaluación y técnicas; sin embargo, el proceso no ha sido adoptado a lo largo del Organismo. La comunicación respecto a los estándares y responsabilidades de gobierno se deja a los individuos. Los individuos impulsan los procesos de gobierno en varios proyectos y procesos de TI. Los procesos, herramientas y métricas para medir el gobierno de TI no abarcan la totalidad de la gestión de TI. Observaciones: El marco de gobierno de TI es incompleto: Falta un Plan Estratégico de TI alineado con el plan Estratégico del Organismo, que garantice un entendimiento compartido entre los objetivos y la función de TI. No se ha normalizado un proceso de administración de proyectos que se aplique a todas las áreas. Se utilizan distintas herramientas y distintos criterios para los aspectos considerados para el seguimiento. No se ha definido un programa de administración de la calidad, inserto en un sistema donde se pueda evaluar el desempeño de la función de TI, su contribución a los objetivos estratégicos del Organismo y que sirva como herramienta de toma de decisiones ante posibles desvíos entre los resultados esperados y los reales. No existe un marco de administración presupuestaria que abarque todas las áreas de TI, que contemple la contabilidad por centro de costos imputándolos a los proyectos y calculándose los beneficios esperados y su contribución a las misiones y funciones de la organización. Falta la definición y ejecución de un marco integral de administración de riesgos que defina cuál es el nivel de riesgo aceptado por el Organismo y que, con prácticas de administración de riesgo, se asegure que el mismo no exceda las pautas establecidas. Aclaraciones y/o comentarios del área responsable: En cuanto a lo observado en relación a la falta de un plan estratégico de TI alineado con el plan estratégico del organismo, se remite a lo informado en el punto 4.1.1 precedente. En relación a que no se ha normalizado un proceso de administración de proyectos que se 173 aplique a todas las áreas, se remite a lo informado en el punto 4.1.10 precedente. En lo referente a la inexistencia de un marco de administración presupuestaria que abarque todas las áreas de TI que contemple la contabilidad por centro de costos, imputándolos a los proyectos y calculándose los beneficios esperados y su contribución a las misiones y funciones de la organización, se remite a lo informado en el punto 4.1.5 precedente. Comentario de AGN: La respuesta del organismo no modifica las observaciones realizadas, por lo tanto se mantienen las mismas. Las mejoras a realizar se evaluarán en una próxima auditoría. 174 ANEXO VI – NOTAS (1) El Decreto Nro 1.399/01, de fecha 4 de noviembre de 2001, en su artículo 9 establece que el Plan de Gestión Anual que deberá cumplir el Administrador Federal de Ingresos Públicos será elaborado por la Jefatura de Gabinete de Ministros con arreglo al sistema reglado por la Ley N° 25.152 y el Decreto N° 103/01. Dicho plan, de acuerdo con el artículo 10 del decreto, será controlado y evaluado trimestralmente por un Consejo Asesor formado por: el Secretario de Ingresos Públicos del Ministerio de Economía, un representante del Presidente del Banco Central de la República Argentina, los Presidentes de las Comisiones de Presupuesto y Hacienda de la Honorable Cámara de Diputados de la Nación y del Honorable Senado de la Nación, o los legisladores que ellos designen, el Director Ejecutivo de la Administración Nacional de la Seguridad Social, dos expertos de reconocida trayectoria en materia tributaria o de gestión pública y un representante de las Provincias a propuesta del Consejo Federal de Inversiones. El Consejo Asesor no tendrá funciones ejecutivas en la gestión de la AFIP, pero puede efectuar recomendaciones y sugerencias al Administrador Federal de Ingresos Públicos. El artículo 7 del decreto mencionado, establece que el Poder Ejecutivo Nacional puede remover al Administrador Federal de Ingresos Públicos en caso de incumplimiento sustancial del Plan de Gestión Anual durante dos años consecutivos, teniendo en consideración la evaluación realizada por el Consejo Asesor. La Disposición Nro 672/04 AFIP de fecha 29 de octubre de 2004, en su artículo 11 establece que las áreas responsables de la fijación de metas que eventualmente se incluirán en los proyectos de Plan de Gestión deberán arbitrar los medios necesarios para disponer de los mismos durante el mes de agosto de cada año. Consecuentemente con el Plan de Gestión se elaboran planes estratégicos del organismo que abarcan períodos de cuatro o cinco años. (2) El decreto 898/05 aprueba la estructura organizativa de la Administración Federal de Ingresos Públicos hasta el nivel de Subdirección General, inclusive. 175 La responsabilidad primaria de la Subdirección General de Sistemas y Telecomunicaciones aprobada por el citado decreto es asistir al Administrador Federal de Ingresos Públicos en todo lo relativo al diseño, desarrollo, operación y coordinación de los sistemas informáticos y de telecomunicaciones requeridos para la operación de la Administración Federal de Ingresos Públicos, en concordancia con las políticas, planes, programas y criterios dictados por el mismo. Posteriormente, con la disposición 65/08 y 428/09 de AFIP y sus anexos, se definió el organigrama de la Subdirección con un detalle de los roles y responsabilidades para cada perfil hasta nivel de división. (3) Disposición 672/04 AFIP de fecha 29 de octubre de 2004. (4) La Disposición 538/05 AFIP del 19 de septiembre del 2005 en su artículo 1 establece que la SDG SIT queda comprendida por el Régimen Económico Financiero vigente para las Direcciones Regionales Impositivas y Aduaneras a partir del 1 de octubre del 2005, quedando en manos de la Subdirección General de Administración Financiera la determinación de qué contrataciones se efectuarán en forma centralizada. (5) Disposición Nro 446/2009. (6) De acuerdo al inciso c) “Actos Internos de Carácter Resolutivo” del Anexo I de la Disposición 446/2009, las Disposiciones son normas de aspecto administrativo y de organización interna, de cumplimiento obligatorio para todas las jefaturas de dependencia y personal de la Administración Federal de Ingresos Públicos, en el marco de las facultades de los Artículos 4to y 6to del Decreto Nro 618/97, sus modificatorios y sus complementarios, y demás normas vigentes relativas a la organización, competencia y funcionamiento del Organismo. Las Instrucciones son normas de procedimiento o trámite, de cumplimiento obligatorio para las jefaturas de dependencia y personal definido en las mismas para el desarrollo de las tareas o funciones que les fueran asignadas. También son de orden interno y de carácter resolutivo. (7) La política de ingreso de personal está regida por las disposiciones 437/05 y 543/08. El decreto 898/05 aprueba la estructura organizativa de la Administración Federal de Ingresos Públicos hasta el nivel de Subdirección General, inclusive. 176 (8) La disposición 65/08 y 428/09 de AFIP y sus anexos, se definió el organigrama de la Subdirección con un detalle de los roles y responsabilidades para cada perfil hasta nivel de división. (9) A través de la Instrucción General Nro 2/2005 de la Subdirección General de Informática y Telecomunicaciones “Pautas para el desarrollo y mantenimiento de Sistemas Informáticos en la AFIP” del 30 de noviembre de 2005 se define el proceso de Ciclo de Vida de Desarrollo de Sistemas. Esta instrucción general, está alineada a la política de seguridad, aprobada mediante la Disposición 76/05 de AFIP y la disposición 42/2011 “Pautas y consideraciones de seguridad a tener en cuenta en el Ciclo de Vida del Desarrollo y Mantenimiento de Sistemas en relación con la Seguridad de la Información”. (10) El punto 7.1 de la resolución 02/2005 permite que la adopción de los documentos entregables sea a criterio de cada división de desarrollo, mientras cumpla con los contenidos mínimos requeridos para cada fase (definición, diseño, construcción e implementación) lo que genera que éstas hayan adoptado un conjunto distinto de documentos. (11) Análisis de Caja Blanca. (12) Las compras de TI se realizan de acuerdo a la Disposición 74/2002 que rige para todas las áreas de la AFIP, teniendo en cuenta las normativas emitida por la ONTI y por la SIGEN. (13) Disposición 76/05 de AFIP y la disposición 42/2011 “Pautas y consideraciones de seguridad a tener en cuenta en el Ciclo de Vida del Desarrollo y Mantenimiento de Sistemas en relación con la Seguridad de la Información”. (14) Punto 11 del Anexo I define las actividades a seguir para la puesta efectiva en producción de las aplicaciones La resolución General Nro 2/2005 SDG SIT que establece las “Pautas para el Desarrollo y Mantenimiento de Sistemas Informáticos de la AFIP”. 177 ANEXO VII – DESCARGO DEL ORGANISMO 178 179 180 181 182 183 184 185 186 187 188 189 190 191