Auditoría informatica I. Concepto

CEF Temas 31, 32 y 33. Auditoría

EMOT Ene 2010 P á g i n a | 1

31. Auditoría Informática I: Concepto y contenidos. Administración, planeamiento, organización, infraestructura técnica y prácticas operativas

1. Introducción. 2. Administración, planificación. 3. Organización, infraestructura técnica. 4. Prácticas operativas.

Bibliografía.

1. INTRODUCCIÓN La Auditoría de los SSII debe entenderse como una herramienta más que ayudará a las organizaciones a supervisar su sistema de control, a gestionar sus riesgos. El objetivo que se persigue es conseguir establecer una relación de confianza en el uso de las tecnologías de la información y de las comunicaciones y a reforzar la gestión de su seguridad y calidad. DEFINICIÓN: Auditoría de los Sistemas de Información incluye a la auditoría informática, y consiste en el examen de los SSII de la organización con el objetivo de facilitar la consecución de los objetivos de negocio que se han establecido. En la auditoría Informática, el objeto a auditar es un producto o proceso informático y su gestión. Por este motivo se considera una auditoría parcial de la organización, la importancia estratégica y el carácter transversal de las TIC “tecnologías de la información y las comunicaciones” en el mundo moderno confieren a este tipo de auditoría una relevancia creciente. Definición de ISACA: “ la auditoría de los sistemas de información es cualquier auditoría que abarca la revisión y evaluación de todos los aspectos de los sistemas automáticos de procesamiento de la información (o una parte de ellos), incluidos los procedimientos no automáticos relacionados con ellos y las interfaces correspondientes”.

1.1 Historia Revolución neolítica: Sociedad nómada sedentaria. Revolución industrial: Sociedad rural urbana. Revolución de la información: Sociedad industrial sociedad de la información, el

objeto fundamental del cambio ha sido el ordenador y la materia prima la información.

Entre las características más destacables de esta “revolución informática” podemos citar algunas de carácter social (globalizaciones económica y cultural, nuevas leyes “protección datos, propiedad intelectual, reformas código penal contemplando la informática, firma digital...”, y empresarial (dependencia de las TIC, automatización de funciones, reducción de



costes, nuevos modelos de negocio (ej. Bancos...) La diferencia más notable respecto a los otros hitos históricos ha sido la alta velocidad de transición. Ninguna revolución fue tan vertiginosa en toda la Historia. En las organizaciones, la información y la tecnología que la soporta representan los activos más valiosos. La productividad de cualquier organización depende del funcionamiento ininterrumpido de sus sistemas de información, lo que conlleva la transformación de todo el entorno en un proceso crítico adicional. Dependencia de los SSII, y de las TIC’s. Se habla de análisis y gestión de los riesgos asociados a las TIC, y la función auditora asociada a estas actuaciones. Es necesario identificar los objetivos del área informática, en línea con los objetivos de negocio de la organización: la idea es asumir compromisos por el área TIC que deben ser satisfechos en unos plazos y con una calidad predeterminada. Algo de Hª… En un primer momento la orientación era la detección y prevención del fraude y errores; después se usó para evaluar situación financiera (la detección y prevención del fraude y errores era un objetivo menor). Simultáneamente se ha producido una evolución metodología:

Hasta s. XIX se realiza un examen exhaustivo; Después s. XIX: se emplean técnicas de muestreo de datos, y revisión de los controles

internos. Egipto-Roma: aparece el concepto de auditoría. Surgen figuras como terratenientes /aparceros. Se producía la Liquidación verbal de cuentas con los “auditores” (los que oyen). Edad Media: en Castilla los “veedores” de cuentas. s. XVIII, surge la Sociedad Anónima en Holanda; aparece el concepto de separación de la propiedad y una nueva profesión, la gerencia. Aparecen también los fraudes para aparentar buen funcionamiento, lo que hace necesarios:

1) la creación de un método y de un sistema normalizado de contabilidad, y 2) expertos independientes para controlar a los gestores y revisar las cuentas.

En 1862, la Ley Británica de Sociedades Anónimas, reconoce la auditoría como profesión. En 1880 se crea, en Inglaterra, la Primera Sociedad de Auditores. Hasta 1905 la auditoría floreció como profesión en Inglaterra. En 1900 se introduce en EE.UU. En 1912 aparece en España con el Colegio de Contadores Públicos. En 1954 se crea el primer sistema de contabilidad informatizada. En esta época, la Auditoria gira alrededor del ordenador (se comprobaban las salidas en función de las entradas). En los años 60 la atención se centra en el CPD (Centro de Proceso de Datos). Se produce una revolución cuantitativa: muchas operaciones, gestión versus Propiedad; se presenta un nuevo enfoque: es imposible verificar TODA la información por lo que se analizan extractos. En los años 70 el foco se dirige a los programas y su lógica interna. En 1977, se publica la Primera edición de Control Objetives, antecesor de CobiT (Control objectives for Information and Related Technology). También el perfil del auditor ha sufrido paralelamente una evolución temporal:

Al principio el auditor, sobre todo auditor de cuentas, se limitaba a revisar la información que obtenía del ordenador con una metodología semejante a la del resto de actuaciones que desarrollaba.



Posteriormente, el auditor comienza a emplear técnicas específicas para analizar los sistemas de información, como las pistas o trazas de auditoría.

Con la revolución TIC, el auditor se apoya cada vez más en el ordenador como instrumento de trabajo. Gracias a la tecnología es posible acceder directamente a los sistemas de información auditados y desarrollar en ellos, de forma completa o parcial, tareas de comprobación (lenguajes de programación y consulta a BBDD).

Finalmente el auditor aplica directamente técnicas de auditoría específicas para SSII y servicios informáticos, con objeto de determinar la eficacia y eficiencia de su funcionamiento. Se usan medios informatizados para los procedimientos de auditoría (CAAT, Computed-Assisted Audit Techniques).

La auditoría informática debe cumplir cinco funciones que enumeramos a continuación:

1. Velar por la eficacia y eficiencia del sistema informático, de forma que se alcancen con el menor coste posible los objetivos que le han sido establecidos.

2. Verificar el cumplimiento de las normas y estándares vigentes en la organización. 3. Verificar la calidad de los sistemas de información y proponer mejoras en los mismos.

La Administración General del Estado ha fijado por Real Decreto Real Decreto 951/2005, de 29 de julio, por el que se establece el marco general para la mejora de la calidad en la Administración General del Estado.

4. Supervisar los mecanismos de control interno establecidos en los centros de proceso de datos y en la organización en su conjunto para proteger los recursos informáticos humanos y materiales y para mantener la integridad de los datos.

5. Comprobar e impulsar la seguridad de los sistemas de información (es decir, garantizar la disponibilidad de las infraestructuras de información, la integridad y la confidencialidad de los datos, su autenticidad y la identidad de las partes que los usan).

Las tres normas básicas en la auditoría de los sistemas de información son pues:

Planificación y supervisión Estudio y evaluación del sistema de control interno Obtención de evidencia suficiente y adecuada (justificación del trabajo realizado y la

opinión expresada)

1.2 Concepto de control en las organizaciones La planificación y el control se incluyen como funciones directivas desde las reflexiones de los primeros teóricos de la organización como Fayol.

El Control Interno es cualquier actividad manual o automática empleada para prevenir y corregir errores que puedan afectar al funcionamiento de un sistema en relación a la consecución de sus objetivos.

El Control Interno Informático controla que todas las actividades del SI (Sistema de Información) sean realizadas cumpliendo los procedimientos, estándares y normas de la dirección así como las normas legales.

El control consiste en un proceso de observación y medida que compara sistemáticamente los objetivos con los resultados y que tiene la capacidad necesaria para regular los sistemas con la intención de que sean alcanzados los objetivos. Una nueva definición de Auditoría Informática: el Proceso de recoger, agrupar y evaluar evidencias para determinar si un sistema informatizado salvaguarda los activos, mantiene la integridad de los datos, cumple eficazmente los fines de la organización, y hace uso eficiente de los recursos.



El auditor es responsable de informar a la Dirección de la organización sobre el diseño y funcionamiento de los controles implantados y sobre la fiabilidad de la información suministrada. Los controles deberían ser:

Simples y fiables Revisables Adecuados Rentables

Los controles pueden clasificarse atendiendo a diferentes características: CLASIFICACIÓN CONTROLES Por el momento en que actúan

Preventivos: “a priori”, ej. Impedir accesos no autorizados

Reactivos: “a posteriori” Concurrente o concomitante (establecido durante la

realización del proceso que se observa y mide).

Por su frecuencia Continúo Periódico Esporádico

Por su naturaleza Generales (organizativos y operativos, de desarrollo y mantenimiento de aplicaciones, de hardware, de software, de acceso, de procedimiento).

De aplicación (controles de entrada, de proceso, de salida).

Otra clasificación De desarrollo que comprueba que el resultado

obtenido concuerda con las especificaciones iniciales De proceso que asegura que la explotación se realiza

con la versiones adecuadas de los programas y de los datos

De continuación que determinaría que se evita la pérdida o corrupción de información, efectuando las salvaguardas y recuperaciones necesarias

Además podemos hablar de controles Detectivos o Correctivos. Como reacción ante escándalos cuyos indicios no fueron debidamente detectados o evaluados, se publica en 1992 el informe COSO. http://www.erm.coso.org/Coso/coserm.nsf/frmWebCOSOExecSum?ReadForm.

El principal objetivo del Control Interno es garantizar que la empresa alcance sus objetivos. En este sentido, el Control Interno (CI) puede actuar de 2 distintas maneras: 1. Evitar que se produzcan desviaciones con respecto a los objetivos establecidos; 2. Detectar, en un plazo mínimo, estas desviaciones. En el primer caso, el Control Interno evita que estas desviaciones se produzcan. Un ejemplo practico podría ser el caso de una empresa que, establecidos unos objetivos en términos de exposición de sus cuentas a cobrar, analiza cada cliente antes de concederle crédito, evitando de esta forma que se produzcan situaciones de cuentas impagadas. En el segundo caso, por el contrario, el Control Interno no evita que se produzcan estas desviaciones, pero por lo menos hace saltar la alarma, de tal forma que la dirección de la empresa puede reaccionar rápidamente.

Este informe define el control interno como “un proceso efectuado por el Consejo de Administración, la dirección y el resto del personal de una entidad, diseñado con el objeto de



proporcionar un grado de seguridad razonable en cuanto a la consecución de objetivos dentro de las siguientes categorías:

Eficacia y eficiencia de las operaciones, Fiabilidad de las operaciones financieras, Cumplimiento de las leyes y normas que le sean aplicables”.

1.3 Clases de auditoría Una auditoría consiste en la realización de un análisis metódico de la situación de una organización en cooperación con los interesados con el fin de verificar la concordancia de la realidad con lo preestablecido y la adecuación de los resultados obtenidos por la organización a los objetivos perseguidos por la misma. Por ejemplo: cumplimiento de cierta normativa legal o estándar. Los objetivos de control y auditoría están directamente relacionados: los auditores supervisan el sistema de control interno de la organización, detectando las debilidades que presenten los controles establecidos y recomendando actuaciones necesarias para reforzarlos; durante el desarrollo de la auditoría los auditores suelen reproducir los controles ordinarios establecidos por la organización para determinar su efectividad además de realizar actividades de control adicionales. CLASIFICACIÓN TIPOS DE AUDITORÍA Según el sujeto que la realiza

Interna: realizada por personal de la propia entidad Externa: la realizan profesionales ajenos a la entidad

Según su amplitud Total: afecta a toda la organización

Parcial: sólo a determinados departamentos o actividades de la organización, restringiéndose en función de su ámbito territorial o funcional

Por su frecuencia Periódica, por ejemplo anual o bienal Ocasional

Según su contenido y fines

Auditorías de regularidad: auditorias de cumplimiento, orientadas a verificar el cumplimiento de la normativa aplicable; o auditorías financieras o contables, emiten un juicio sobre el estado financiero de la entidad

Auditorías operativas o de gestión: evalúan la eficacia en la consecución de objetivos y la eficiencia en los recursos empleados para alcanzarlos

Auditorías forenses: especializadas en descubrir fraudes y delitos, en obtener evidencias válidas para su uso por las autoridades competente, policiales o judiciales

Auditorías de los SSII: realizan el examen y verificación del correcto funcionamiento y control del sistema informático de la organización

1.4 Estrategia de la auditoría de los SSII La organización comprende y gestiona los riesgos asociados con la implementación de

las nuevas tecnologías. El equipo directivo tiene un conocimiento básico de los riesgos y los límites de las TIC

con objeto de proveer una dirección eficaz y los controles adecuados.



Existe un decisión estratégica en cuanto a cuál es la inversión razonable en seguridad y control, y cómo balancear el riesgo y el control de las inversiones, es imprescindible que el órgano de dirección entienda la implicación de una gestión de riesgos en general, y los relacionados con las TIC en particular, y aseguren el establecimiento de un sistema de control interno apropiado para la organización que dirige.

La organización tiene definida, documentada, pública para todo el personal y aplicada, una política de control. En el ciclo de gestión de control la auditoría tiene la misión de analizar la implementación de los controles y corregir la gestión con la propuesta de mejoras.

En la siguiente figura se esquematiza el ciclo de gestión de control.

Políticas: Declaración de intenciones de alto nivel, refleja los objetivos de la

organización (qué y por qué), deben estar debidamente documentadas y establecer criterios de medición de resultados. Deben ser aprobadas por la alta dirección de la organización, perdurables en el tiempo (mantenerse al margen de la tecnología empleada) y conocidas por toda la organización. Misión y visión de la organización.

Normativas: Reglas generales que desarrollan las políticas de alto nivel, de obligada aplicación para las personas de la organización. Serán definidas por el órgano de dirección responsable de su supervisión. Se ajustarán al despliegue tecnológico, y serán conocidas por los usuarios de los sistemas. Por ejemplo, se podrán tener definidas o adoptadas normas sobre: control de presencia, control de acceso a los sistemas de información, estándares y normas técnicas del mercado que sean de aplicación, requerimientos legales, etc.

Procedimientos: Señalan el marco de actuación en los distintos campos de las TIC para resolver situaciones concretas. Deben ser desarrollados por la unidad responsable de su implementación y estar ajustados a normas, estar documentados y tener unos contenidos mínimos ajustados a la materia, deben mantenerse actualizados y han de ser conocidos por los encargados de ejecutarlos y por los usuarios. Como ejemplo de procedimientos, se podrán tener sobre: gestión de usuarios, resolución incidencias, copias de seguridad, pruebas a realizar en desarrollos, etc.

Instrucciones: Detallan técnicamente la forma precisa de actuar para implementar un procedimiento, señalando los pasos de obligado cumplimiento que deben seguirse. Deben estar documentadas y ser conocidas por los técnicos responsables. Como ejemplo de instrucciones señalamos las relativas a: seguimiento actividad vírica, instalación de actualizaciones, restablecimiento de sistemas, backups, etc.

Política de SeguridadPolítica de CalidadManual de Calidad

Normas deSeguridad

Planes deSeguridad y Calidad

Especificaciones de Seguridad y Calidad

Estándares de Seguridad Guías de Seguridad y Calidad

Procedimientos de Seguridad y Calidad

Instrucciones de Seguridad y Calidad

Registros de Seguridad y Calidad

Nivel Estratégico

Nivel Táctico

Nivel Operativo

Política de SeguridadPolítica de CalidadManual de Calidad

Normas deSeguridad

Planes deSeguridad y Calidad

Especificaciones de Seguridad y Calidad

Estándares de Seguridad Guías de Seguridad y Calidad

Procedimientos de Seguridad y Calidad

Instrucciones de Seguridad y Calidad

Registros de Seguridad y Calidad

Nivel Estratégico

Nivel Táctico

Nivel Operativo



1.5 Auditoría de SSII en las AAPP La función de control de la Administración Pública española se desarrolla en tres ámbitos:

Control político ejercido por el Parlamento Control judicial ejercido por los Tribunales de Justicia Control administrativo ejercido por órganos administrativos

Centrándose en el control administrativo encontramos los siguientes órganos especializados:

Tribunal de Cuentas: órgano supremo fiscalizador de las cuentas y de la gestión económica del Estado y del sector público, controla la actividad económica y presupuestaria. Es un órgano externo, de carácter administrativo que también tiene atribuidas funciones de alcance contable, y cuyo destinatario principal es el Parlamento.

Intervención General de la Administración del Estado (IGAE): un órgano interno de

la Administración que examina la gestión del gasto público por parte de los organismos gestores. Comenzó examinando exclusivamente los aspectos legal y financiero del gasto público, pero desde 1984 debe elaborar anualmente un Plan de Auditorías. Las Normas Técnicas de Auditoría Pública constituyen el núcleo de sus procedimientos de trabajo, clasifican sus actuaciones en dos grandes grupos: auditorías de regularidad y auditorías operativas. La Ley General Presupuestaria de 47/2003, de 26 de noviembre, refrenda el papel de la IGAE en el control interno, delimitando sus funciones interventora, de control financiero permanente y de auditoría pública.

Inspecciones Generales de los Servicios, según Real Decreto 799/2005, de 15 de

julio, son los órganos de la Administración General del Estado especializados en el control interno y en la evaluación de los servicios de cada uno de los Ministerios y de sus organismos públicos dependientes. Su función es supervisar el funcionamiento de los órganos administrativos, lo que incluye el seguimiento de objetivos y el análisis de riesgos y debilidades. En el artículo 2 del RD se recogen entre sus funciones, la de realizar auditorías internas. En el Real Decreto 951/2005 de 29 de julio, por el que se establece el marco general para la mejora de la calidad en la Administración General del Estado, se les atribuyen competencias en la evaluación de calidad de las organizaciones. La coordinación de la actividad de las Inspecciones Generales de los distintos Ministerios se realiza por un órgano colegiado, la Comisión Coordinadora de Inspecciones Generales de Servicios.

Inspección General del Ministerio de Economía y Hacienda y Servicio de Auditoría interna de la Agencia Tributaria, sus procedimientos de actuación están regulados por el Real Decreto 1733/1998. Le corresponde la evaluación y el control del funcionamiento interno del Ministerio de Economía y Hacienda, la inspección del modo y eficacia con que se gestionan los tributos cedidos a las Comunidades Autónomas y la coordinación de la alta inspección referente a la aplicación de los sistemas fiscales concertados y convenidos. A la Agencia Estatal de Administración Tributaria (AEAT) le corresponde facilitar a los contribuyentes el cumplimiento de sus obligaciones, recaudando los tributos exigibles y desarrollando los programas de control fiscal y prevención del fraude y la elusión fiscal. La AEAT dispone desde su creación (Ley 31/1990 de los Presupuesto Generales del Estado para 1991) de un Servicio de Auditoría Interna (SA, con rango de dirección adjunta, que desempeña funciones de control interno, evaluación de los sistemas de seguridad y de control interno de la AEAT, apoyo a los órganos rectores de la Agencia en el cumplimiento de los objetivos, y presupuestación, análisis y seguimiento de los ingresos tributarios, así como prevención y detección de las conductas irregulares de los empleados de la organización, además de formar parte de la Unidad Operativa del Consejo de Defensa del Contribuyente, que atiende las quejas y sugerencias y hace efectivo el derecho de



los ciudadano a expresar su disconformidad con el funcionamiento de los servicios públicos.

Agencia Estatal de Evaluación de Políticas Públicas y de la Calidad de los Servicios,

desarrolla una actividad institucional en la que se une la voluntad de mejorar la calidad de los servicios públicos con la de racionalizar el uso de los recursos públicos y rendir cuentas ante los ciudadanos. La Agencia es un organismo público regulados en la Ley 28/2006, de 18 de julio, de Agencias estatales para la mejora de los servicios públicos. La Agencia tiene como propósito contribuir a: mejorar los servicios públicos y el conocimiento de los efectos en la sociedad de las políticas y programas públicos, promover una mayor racionalidad del gasto público y la optimización en el uso de los recursos, favorecer la productividad y competitividad de la economía española eliminando trabas burocráticas, aumentar la rendición de cuentas respecto a los ciudadanos y la calidad democrática, promoviendo la transparencia y la participación. La evaluación de políticas públicas tiene antecedentes en numerosos países y actividades, en este sentido en España, se crea el Observatorio de la Calidad de los Servicios públicos, regulado por el Real Decreto 951/2005, que debe informar periódicamente del nivel de calidad con que se prestan los servicios públicos, presentando y difundiendo anualmente un informe de evaluación global de los servicios analizados.

Consejo Superior de Administración Electrónica, creado por Real Decreto 589/2005

de 20 de mayo, es un órgano colegiado adscrito al Ministerio de Administraciones Públicas y encargado de la preparación, elaboración, desarrollo y aplicación de la política y estrategia del Gobierno en materia de tecnologías de la información, así como del impulso e implantación de la Administración electrónica en la Administración General del Estado (AGE). Puede actuar en Pleno y en Comisión Permanente. Entre sus funciones destaca: el desarrollo de políticas y estrategias en materia de tecnologías de la información, la planificación y elaboración de directrices generales que sirvan de base a los planes estratégicos departamentales en materia de tecnologías de la información, asesoramiento y consultoría en materia presupuestaria, recursos humanos y organización de las tecnologías de la información, cooperación con las comunidades autónomas y entidades locales en la puesta en marcha de servicios públicos ínter administrativos, así como con la Unión Europea y con organizaciones internacionales, funciones de seguridad en colaboración con el Centro Criptológico Nacional del Centro Nacional de Inteligencia, difundiendo medidas de seguridad de tecnologías de información, adquisición de material de cifra y formando especialistas en seguridad de los sistemas, organizando conferencias y otras actividades para el intercambio de experiencias, análisis y estudio de la situación de la administración electrónica, actuando como Observatorio de la Administración Electrónica. Entre otras actividades de producción y difusión de estándares y recomendaciones (METRICA v3, SICRES, Guías técnicas aplicables a la contratación de bienes y servicios de tecnologías de la información y las comunicaciones) cabe citar los relacionados con la seguridad de los sistemas de la información: los Criterios SNC, aprobados por Resolución de 28 de mayo de 2003, MAGERIT v2 y su herramienta PILAR, procedimiento informático-lógico para el análisis y la gestión de los riesgos de un sistema de información; el consejo impulsa también el proyecto del Esquema Nacional de Evaluación y Certificación de la Seguridad de los Sistemas de Información a través de un Grupo ad hoc del Comité Técnico de Seguridad de los Sistemas de Información y Protección de datos (SSITAD). El Centro Criptológico Nacional tiene un notable protagonismo en este proyecto como organismo de certificación, según lo dispuesto en la Ley 11/2002 de 6 de mayo reguladora del Centro Nacional de Inteligencia y en el Real Decreto 421/2004 de 12 de mayo, por el que se regula el Centro Criptológico Nacional.



Para resumir podemos concluir que en la Administración se desarrollan funciones de auditoría de sistemas de información en dos modelos principales: auditoría interna, formando parte de los órganos de control, o si forma parte de los centro informáticos. En función del tamaño de la organización, la función de auditoría informática no necesariamente recaerá en una unidad específica, sino que podrá ser una especialización dentro de una unidad con más alcance, como pueden ser las Inspecciones de los Servicios en la Administración General del Estado (AGE). En el caso concreto de la AP que presta servicios electrónicos a los ciudadanos, se requiere el establecimiento de medidas tanto técnicas como organizativas, que aseguren el mantenimiento de las garantías en los procedimientos y fortalezcan la confianza de los usuarios y administrados. El auditor informático debe colaborar, para ello debe comprender los procesos de los servicios públicos, evaluar programas y políticas públicas para la mejora de la calidad de los servicios (con referencia a los modelos EFQM y EVAM), evaluar cartas de servicios, analizar la demanda de los usuarios, evaluar la satisfacción de los usuarios, etc.

2. ADMINISTRACIÓN, PLANIFICACIÓN Uno de los marcos de referencia más utilizados en auditoría informática es COBIT (http://www.isaca.org/cobit.htm), se trata de una institución americana, dependiente del IT Governance Institute que nació en 1996. Su misión y objetivos es investigar, desarrollar y promocionar objetivos de control relacionados con las Tecnologías de la Información a nivel internacional. COBIT se caracteriza por su orientación al negocio, recopila un juego internacional de objetivos de control actualizados que cuentan con amplia aceptación para su uso diario por parte de los encargados del negocio y de los encargados de Tecnologías de la Información.



Recoge indicadores clave de rendimiento asociados a la mejora de procesos. Otro referente claro es ITIL. Originalmente creado por el gobierno del Reino Unido, ITIL resume las mejores prácticas de implementación en la gestión de los procesos de Tecnologías de la Información. Define los procesos para desplegar y mantener servicios de TI (asimilables normalmente a aplicaciones) centrando su foco en el negocio. La filosofía ITIL gira alrededor de la gestión de incidencias como plataforma de comunicación y de una base de datos que centraliza la de gestión de la configuración (CMDB).



En un vistazo general parece que COBIT se solapa considerablemente con ITIL, sin embargo COBIT tiene una clara influencia por el área de seguridad: fusiones y adquisiciones, subcontratación, auditoría, son capítulos clave en el marco de referencia COBIT.

2.1 Proceso de una auditoría

Corresponde a la alta dirección de la organización soportar el mantenimiento de la función de auditoría de sistemas de información para el control de los recursos propios. Hay que definir la estructura organizativa donde se lleven a cabo las auditorías, bien internas, con el mandato o procedimiento de la función de auditoría interna (indicando lo que se audita y lo que no se audita), bien externa, con el mandato para la auditoría externa, siempre será éste la norma que regulará el proceso de auditoría.

Como referencia la implantación de una norma como la ISO 9001 exige como uno de los 4 procedimientos principales el de auditorías internas.

2.2 Estándares y normas técnicas

Los instrumentos de normalización y estándares son amplios y variados, en función del sector a auditar, citaremos algunos de ellos: NORMAS DEL SECTOR PÚBLICO

Normas de Auditoría del Sector Público de la IGAE: www.igae.pap.meh.es/Internet/Cln_Principal/ClnPublicaciones/ClnNormasAuditoria

Resolución de 23 de junio de 2003, del Instituto de Contabilidad y Auditoría de Cuentas, por la que se publica la norma técnica de auditoría sobre “la auditoría de cuentas en entornos informatizados”.

Serie del Centro Criptográfico Nacional “Seguridad de las Tecnologías de la Información“ (consultar CCN-STIC en https://www.ccn-cert.cni.es.

Information Technology Infrastructure Library (ITIL) desarrollada por Office of Government Commerce del H.M.Teasury de UK Government, constituye una guía de las mejores prácticas para la gestión de servicios de tecnologías de la información (disponible en www.ogc.gov.uk).

Serie de Publicaciones Especiales del Instituto Nacional de Estándares y Tecnología de EE.UU. (NIST Special Publications disponibles en http://csrc.nist.gov/publications/nistpubs/index.html).

RECOMENDACIONES DE ORGANIZACIONES INTERNACIONALES

Control Objectives for Information and Related Technologies (COBIT) de la Asociación de Auditoría y Control de Sistemas de Información (ISACA), establecen un marco para la auditoría informática y son un referente empleado por muchas organizaciones: http://www.isaca.org/Template.cfm?Section=COBIT6&Template=/TaggedPage/TaggedPageDisplay.cfm&TPLID=55&ContentID=7981.

IS Standards, Guidelines and Procedures for Auditing and Control Professionals de ISACA, define los procedimientos a realizar en determinadas actuaciones de auditoría informática e incluye su código de ética profesional (www.isaca.org).

Instituto SANS (SysAdmin, Audit, Network, Security), publica varios programas (www.sans.org).

NORMAS INTERNACIONALES

Código de buenas prácticas para la gestión de la seguridad de la información, actual ISO/IEC 27002.

Especificaciones para los sistemas de gestión de la seguridad de la información (SGSI) ISO/IEC 27001:2005.

Criterios comunes de evaluación de la seguridad de las tecnologías de la información ISO/IEC 15408:2005 (Common Criteria for Information Technology Security Evaluation



Versión 2.3 Agosto 2005, disponible en http://www.oc.ccn.cni.es/ccv2.3_es.html), desarrollados por los organismos de normalización CSE - Canadá, SCSI - Francia, BSI - Alemania, NLNCSA - Holanda, CESG - Reino Unido, NIST - EE.UU. y NSA - EE.UU.).

Gestión de la seguridad de las tecnologías de la información y las comunicaciones ISO/IEC 13335:2004.

Metodología para la evaluación de la seguridad de los sistemas de información ISO/IEC 18045:2005.

PROCEDIMIENTO ADMINISTRATIVO

Real Decreto 263/1996, de 16 febrero 1996, que regula la utilización de técnicas electrónicas, informáticas y telemáticas por la Administración General del Estado (publicado en el BOE de 29/02/1996).

Legislación sobre registros telemáticos: Real Decreto 72/1999 que regula la presentación de solicitudes, escritos y comunicaciones ante la AGE, la expedición de copias de documentos y devolución de originales y el régimen de registros; Real Decreto 209/2003 que regula los registros y notificaciones telemáticas, utilización de medios telemáticos para la sustitución de certificados, y la Orden PRE/1551/2003 que desarrolla su disposición final primera.

Resolución de la Secretaría de Estado de Administración Pública del 26 de mayo de 2003 que dispone la publicación del acuerdo del Pleno de la Comisión Interministerial de Adquisición de Bienes y Servicios Informáticos que aprobó los criterios de seguridad, normalización y conservación de las aplicaciones utilizadas por la AGE en el ejercicio de sus potestades (disponible en www.csi.map.es/csi/pg5c10.htm).

MAGERIT Versión 2, Metodología de análisis y gestión de riesgos de los sistemas de información (www.csi.map.es/csi/pg5m20.htm).

PROTECCION DE DATOS DE CARÁCTER PERSONAL

Ley Orgánica 15/1999, de protección datos de carácter personal. RD 1729/2007 Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el

Reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal.

Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica.

2.3 Planificación

La planificación consiste en la fijación de objetivos y metas, así como en la propuesta de estrategias, políticas y programas tendentes a alcanzarlos. Las actuaciones de Auditoría Informática requieren una planificación en tres niveles

En el primero de ellos se define qué se debe auditar (estableciendo prioridades):

Requerimientos legales. El resultado de un análisis de riesgos. El resultado de auditorías anteriores.

En el segundo nivel se decide cuándo auditar, priorizando las actuaciones a realizar,

y ajustando el alcance de las mismas a los recursos disponibles.

Por último, en el tercer nivel se estipula el detalle de cómo realizar las actuaciones previstas en ese plan, que se materializarán en actuaciones concretas.



Debe obtenerse toda la información preliminar sobre la actividad llevada a cabo por el área sujeta a la actuación de auditoría, en especial el esquema organizativo de control interno, contra el cual se efectuará la evaluación: políticas, normas, procedimientos e instrucciones técnicas aplicables al alcance de la actuación. De no existir un marco de control definido en la organización se podrán emplear como referencia estándares y/o buenas prácticas (ISO, Instituto Sans, COBIT, NIST, Serie CCN-STIC del CNI, etc.). Con toda la información el equipo auditor podrá definir los objetivos, proponer un calendario, identificar los interlocutores, establecer el tipo de información a recopilar y las verificaciones o pruebas de campo a efectuar durante la actuación. En definitiva, estructurar los contenidos en un Guión de la Actuación que se empleará para sistematizar las tareas.

2.4 Auditoría asistida por ordenador y software de auditoría

informatizada.

Existen herramientas que facilitan la generación de muestras, se emplean para interrogar a los SSII o para extraer información que luego será tratada por otra herramienta de análisis. No tienen por qué ser productos específicos, se pueden emplear los SSOO y SGBD que recogen datos de controles implementados en los logs. El empleo de herramientas asegura independencia en la recolección de los datos, y suelen tener las siguientes características:

Acceso a distintas estructuras o formato de datos; Reorganización de archivos, incluyendo indexación, clasificación fusión y cruce; Selección de datos, filtrado y aplicación de criterios de búsqueda; Funcionalidades estadísticas (muestreo, estratificación y frecuencias); Funcionalidades aritméticas.

Las ventajas del uso de herramientas de auditoría informática son:

Disminución del riesgo propio del proceso de auditoría en la recolección de datos; Mayor independencia; Mayor cobertura y más consistentes al poder emplear un alto número de datos,

analizando más y mayores muestras; Mayor disponibilidad; Ahorro de costes con el tiempo.

Existen productos de software, suelen denominarse CAATT (herramientas y técnicas de auditoría asistida por ordenador) que permiten realizar auditorías informatizadas en varias plataformas. Estos productos pueden realizar las siguientes funciones:

Análisis de riesgos Planificación de auditorías, Generación y gestión de los papeles de trabajo, Generación de informes, Procedimientos de tramitación de los informes, Obtención de copias para archivo, Estadísticas de las actuaciones, Administración y gestión de la seguridad del producto.

Suelen incorporan además las técnicas más sofisticadas de análisis de ficheros y extracción de datos, con objeto de detectar la manipulación o fraude y permitir el seguimiento continuo de los procesos de las organizaciones. Cuentan con herramientas como:

Cuestionario general inicial. Cuestionarios Checklist. Estándares. Monitores. Simuladores (Generadores de datos).



Paquetes de auditoría (Generadores de Programas).

3. ORGANIZACIÓN, INFRAESTRUCTURA TÉCNICA En casi todas las organizaciones, los auditores internos se organizan en un Departamento de Auditoría Interna separado, dependiente de la alta dirección y que constituye un órgano especializado de control. El tamaño de este departamento depende del tipo de organización y de las funciones de control interno (como ej. la Administración Tributaria debería contar con un 0,5 a 1 % del personal de la organización). Las funciones desempeñadas por este departamento suelen ser:

establecer, mantener y mejorar controles efectivos (evaluando su eficacia y eficiencia),

contribuir al establecimiento, mantenimiento y mejora del sistema de gestión de riesgos,

velar por el mantenimiento de la seguridad en la organización (sugiriendo mejoras aplicables a la seguridad de los activos, y la seguridad física y lógica),

regulación de normas de conducta del personal (promoción de valores éticos, prevención y detección de conductas irregulares…), y por último

ejercer como órgano de asesoría y consultoría al servicio de la dirección de la organización.

3.1 Esquema Organizativo de la Función de Auditoría. Modelos

Organizativos.

En un primer modelo, los auditores de SSII forman parte de los órganos de control, supervisión o auditoría interna (intervenciones, inspecciones generales, servicios de auditoría, etc.). Esta opción permite una mayor independencia del auditor al distanciarse en mayor medida del sujeto de su actuación. El otro modelo incluye el trabajo de los auditores informáticos en los propios centros informáticos. En este caso, las actividades de auditoría se suelen concebir como un instrumento utilizado por los responsables directivos del centro para garantizar la seguridad y la calidad de las operaciones e identificar y mitigar los riesgos. En este caso hay una implicación más directa en las tareas destinadas a mejorar la calidad y asegurar el funcionamiento de los sistemas de información, que se llevan a cabo en los propios Centros Informáticos. En cualquier modelo organizativo se han de cumplir unos principios necesarios para que la función de auditoría pueda desarrollarse con éxito:

Independencia: sin funciones operativas + no preparación y desarrollo de procedimientos, o tomar decisiones ejecutivas que comprometieran su función en auditorías posteriores.

Autoridad: acceso no restringido a la información, datos, informes, actividades y al personal de todas las unidades sujetas a auditar.

3.2 El auditor informático. Perfil técnico. Ética profesional.

Perfil técnico En el ámbito del sector privado existen organizaciones profesionales que habilitan a un profesional como auditor informático mediante la certificación profesional que gestionan. En general, las áreas de conocimiento requeridas para cubrir el perfil profesional de un auditor pueden ser:

Técnica o metodología de auditoría informática. Gestión, planificación y organización de las tecnologías de la información.



Infraestructura técnica, prácticas operativas y protección de activos informáticos. Recuperación de desastres y continuidad de la actividad soportada por los sistemas de

información. Desarrollo, adquisición, implementación y mantenimiento de sistemas de

información. Evaluación de procesos de negocio y gestión de riesgos.

La certificación se obtiene después de aprobar un examen sobre esas materias, acreditar una experiencia profesional adecuada en el campo de las TIC y aceptar un código de ética profesional; y se mantiene acreditando una formación continua. Ej. de certificaciones profesionales (destacan las emitidas por la Asociación de Auditoría y Control de Sistemas de Información (Information Systems Audit and Control Association, ISACA):

CISA, Auditor Certificado de Sistemas de Información (Certified Information Systems Auditor).

CISM, Gestor Certificado de Seguridad de la Información (Certified Information Security Manager).

Ética profesional Ej. código de ética profesional definido por ISACA, de obligado cumplimiento para sus miembros y para los poseedores de las certificaciones CISA y CISM: Apoyar el establecimiento y cumplimiento de normas y controles en los SSII Cumplir las normas de auditorías de los SSII Actuar en interés de los empleadores, accionistas, clientes y público en general, de forma diligente, leal y honesta Confidencialidad de la información recogida (no se podrá utilizar en beneficio propio o divulgarla a terceros no legitimados) Independencia y objetividad Competencia en auditoría y SSSII Obtener y documentar material suficiente para poder soportar las conclusiones y recomendaciones Informar a las partes involucradas del resultado de la auditoria Apoya la educación de la gerencia, cliente y público en general, para la mejor comprensión de la auditoría y los SSII Estándares de conductas: actividades profesionales y privadas Para los profesionales de la Administración Pública no existe un código de estas características, pero como funcionarios están sujetos a mantener una conducta y diligencia profesional adecuada:

El Real Decreto 33/1986, de 10 de enero, aprueba el Reglamento de Régimen Disciplinario en la AGE en el que se estipulan las faltas, que podrían suponer la aplicación de sanciones disciplinarias. Entre ellas se citan:

Adopción de acuerdos manifiestamente ilegales que causen perjuicio a

la Administración. No guardar el debido sigilo respeto a los asuntos que conozca por

razón de su cargo. Descuido o negligencia en el ejercicio de sus funciones. Incumplimiento de sus deberes y obligaciones.

Los Subsecretarios de los Departamentos ministeriales son los que ostentan la competencia para ordenar la incoación del expediente disciplinario.

Ley del Estatuto Básico del Empleado Público (7/2007 de 12 de abril) de los deberes

básicos de los empleados públicos, fundados en principios éticos y reglas de comportamiento, constituye un auténtico código de conducta con unos principios éticos a los que los empleados públicos deberán ajustar sus actuaciones.



4. PRÁCTICAS OPERATIVAS El proceso de una auditoría TIC tiene diferentes fases:

Planificación de la auditoría. Desarrollo de la auditoría: examen y evaluación de la información obtenida en la fase

previa. Comunicación de los resultados. Seguimiento de las recomendaciones.

PLANIFICACION DE UNA AUDITORIA Consiste en su preparación, se materializa en la elaboración de un guión de auditoría o plan de trabajo (meno denso que el guión) en el que se recogen los objetivos y el alcance de la auditoría, la metodología a seguir, y las actividades a desarrollar. La metodología se diseña para obtener las pruebas que sustenten evidencias o hallazgos suficientes, relevantes y competentes para cumplir con los objetivos de la auditoría. El trabajo de planificación concluye con la confección de un plan de trabajo o guión de auditoría:

identificación de los aspectos técnicos, riesgos, procesos y actuaciones que deben revisarse;

naturaleza y extensión de las pruebas requeridas; definición de los procedimientos de auditoría que deben aplicarse para captar,

analizar e interpretar la información; documentos e instrumentos que se van a utilizar en las actuaciones de auditoría, en

particular las muestras que deben tomarse y la forma de obtenerlas; cronograma detallado de las actividades a realizar junto con el personal del equipo

de auditoría asignado a cada tarea. FORMALIZACIÓN DEL INICIO DE LA ACTUACIÓN El inicio de la actuación debe formalizarse mediante una notificación del responsable de la unidad de auditoría de la organización dirigida al responsable de la unidad auditada, en la que se identifique al equipo auditor y el objeto de la acción a llevar a cabo. Durante la entrevista, convenida de mutuo acuerdo y en las instalaciones de la unidad auditada, el equipo auditor describirá el proceso a llevar a cabo, el tipo de auditoría a realizar, la información que necesitará recopilar durante la actuación, las pruebas y verificaciones que se harán y la colaboración requerida por parte del personal del área para que haga accesible la información solicitada y permita la realización de las comprobaciones que determine el equipo auditor. Se designará el interlocutor del área auditada para ayudar al equipo auditor, y se identificarán el resto de los interlocutores. Durante la auditoría se obtiene, analiza y documenta información de diversas fuentes, como registros informáticos, información documental, información testimonial (entrevistas, cuestionarios, informes solicitados,..) que requieren un trabajo de campo. TRABAJOS DE CAMPO En esta fase del proceso de auditoría, el equipo auditor recopilará información adicional con el fin de obtener evidencias e identificar hallazgos que reflejar como conclusiones de la actuación. Si existiera una auditoría previa, el esfuerzo se centrará en identificar los cambios operacionales o técnicos desde la última actuación, si no, hay que recoger toda la información desde el principio (supone un mayor esfuerzo). Evidencia: cualquier información empleada por el auditor para determinar si el proceso que se está auditando cumple con los criterios y objetivos de la auditoría. RAE. “certeza clara y manifiesta de la que no se puede dudar”, y en una acepción más jurídica como “prueba determinante en un proceso”.



Las conclusiones del informe de auditoría, deberán estar basadas en evidencia suficiente, relevante y competente:

Suficiente: En la cantidad necesaria para que puedan soportar las conclusiones del auditor, es decir que sean suficientes para persuadir a una persona razonable de la validez del resultado. Se pueden emplear métodos estadísticos para determinar el tamaño de las muestras o la cantidad de pruebas a realizar.

Relevante: Si tiene relación lógica y ajustada al objeto de la actuación. Competente: Que sea válida, tenga calidad, y ser consistente con el hecho a

demostrar. La forma de determinar la suficiencia, relevancia y competencia de una evidencia dependerá del origen de la misma:

Datos obtenidos por el equipo auditor. Datos recogidos por los auditados.

El grado de fiabilidad de las evidencias que se obtengan dependerá de una serie de factores: Independencia del proveedor de la evidencia, una fuente externa al área auditada

será en un principio más confiable. Cualificación del entrevistado (formación y experiencia). Objetividad (priman las evidencias objetivas frente a las subjetivas). Tiempo de disponibilidad.

Según su naturaleza, las evidencias se pueden clasificar en: Físicas: fotografías, dibujos o esquemas, muestras físicas. Documentales. Testimoniales: resultado de entrevistas, cuestionarios o listas de verificación. Analíticas: mediante comparaciones, separación de información en componentes,

cálculos o empleo de argumentos razonados. Finalmente señalar que en todo caso, si se demuestra la existencia de errores en los datos que no podrán soportar la evidencia como válida, será necesario:

Buscar otras fuentes de evidencia. Redefinir los objetivos de la auditoría para eliminar la necesidad de contar con datos. Usar los datos, pero señalando en el informe las limitaciones de los mismos, evitando

hacer conclusiones o recomendaciones sin garantías. Técnicas para la recolección de evidencias

Revisión de documentos: los documentos a estudiar en primer lugar serán aquellos solicitados en la entrevista que formalizó el inicio de la actuación organigramas, políticas, normas y estándares, documentación de SSII…

Entrevistas: obtención de información y averiguar el grado de conocimiento de los entrevistados sobre el sistema de control que será objeto de la auditoría. Material de apoyo: cuestionarios, listas de verificación…

5.

Según el momento en que se realicen y el tipo de información recopilada, se pueden clasificar en:

Preeliminares: Se mantienen con interlocutores de nivel directivo alto/medio. En esta fase se documentarán las entrevistas, se solicitarán organigramas, documentos de planificación general, y documentación sobre el sistema de control aplicado.

De detalle: Se mantienen con los mandos con responsabilidad directa en la ejecución de los controles y con responsables técnicos. Se podrá solicitar cumplimentar un cuestionario detallado o una encuesta, y podrá requerirse documentación detallada sobre el proceso evaluado (normas, procedimientos y estándares reconocidos).

De seguimiento: Durante todo el proceso de la auditoría se podrán mantener reuniones breves con la dirección del área auditada para informarle sobre los hechos observados en la actuación, y aclarar dudas o corregir malos entendimientos e inexactitudes.

Pruebas y verificaciones de campo



Pruebas de cumplimiento: Orientadas a comprobar que se cumplen determinados procedimientos de control o procesos establecidos y que funcionan según lo esperado.

Pruebas sustantivas (o de validación): Se aplican para detectar la presencia o ausencia de errores en los procesos o controles.

Hallazgos: criterios, condiciones y efectos que permitan documentar los problemas

encontrados, que dependerán del objeto de la auditoría. Se entiende por criterio un estándar empleado para determinar si el objeto de la

revisión cumple las expectativas para lo que fue pensado, por ejemplo, estándares o normas técnicas.

Por condición se hace referencia a la situación que existe y se ha determinado y documentado durante la entrevista, por ejemplo, la falta de elementos de extinción de incendios.

Por efecto entendemos las consecuencias de una condición, que pueden variar un criterio identificado en la auditoría, y evidencian la necesidad de medidas correctivas, como por ejemplo, la falta de extintores aumenta el riesgo de no poder controlar un conato de incendio.

Impacto de un hallazgo según su materialidad Bajo => descripción del hallazgo como vulnerabilidad a la que se expone el sistema. Medio => se refleja en el informe como posible debilidad del sistema de control. Alto => se identifica como una debilidad que debe compensarse o anularse con más controles, o haciendo los existentes más estrictos.

EVALUACIÓN DE LA INFORMACIÓN Se revisa toda la información recopilada así como los hallazgos. En esta fase se valorará el cumplimiento de las normas, procedimientos y estándares reconocidos, y se determinará si los procedimientos tienen una estructura de control adecuada, que sea efectiva en términos económicos, y que provea una adecuada seguridad para que las tareas se realicen según lo previsto, y que el objetivo o punto de control se cumple. Todo el análisis debe estar justificado con evidencias recogidas en la actuación. COMUNICACIÓN DE LOS RESULTADOS La comunicación de los resultados obtenidos en la auditoría se realiza mediante informes de auditoría. Al final del proceso de la auditoría se mantendrá una reunión de cierre con el máximo responsable de la unidad auditada (quien haya participado en la reunión de lanzamiento), con objeto de comunicar los principales hallazgos de la actuación. Se redacta el borrador del informe, que incluirá todos los hechos, hallazgos, conclusiones y recomendaciones. La redacción debe ser clara y concisa. Los informes de auditoría deben someterse a un procedimiento de tramitación, generalmente contradictorio. Esto significa que el órgano o entidad auditada tienen la posibilidad de plantear, en un plazo prefijado, observaciones o alegaciones al informe preliminar, que son evaluadas por los auditores al elevar el informe definitivo. SEGUIMIENTO CONTINUO En el informe se podrá señalar que las recomendaciones que deben ser llevadas a cabo en un período de tiempo determinado a contar tras su recepción, o ser la dirección de la organización quien decida cuándo y cómo llevar a cabo las recomendaciones. En las recomendaciones el auditor propone soluciones a los problemas detectados basadas en su experiencia profesional y plantea mejoras con vistas a conseguir que la organización cumpla sus objetivos. No suelen ser directamente ejecutivas (de obligado cumplimiento por parte del auditado).



4.1 Guías de Auditoría de los sistemas de información (guión, puntos

de control)

Aunque cada auditoría es única, se pueden encontrar similitudes entre ellas para los mismos objetivos de control, y en especial si tienen un carácter periódico. El guión, los documentos preliminares empleados para su elaboración, y los documentos en que se apoyarán las evidencias que se recogerán durante los trabajos de campo, constituyen los conocidos como papeles de trabajo, que tienen los siguientes fines:

Son el principal soporte para la elaboración del informe de auditoría. Ayudan al auditor a llevar a cabo la auditoría. Permitirían a terceros evaluar la calidad de las acciones realizadas.

El guión elaborado en la fase inicial de la auditoría es un documento vivo que puede verse modificado. Por lo tanto, durante la actuación el guión irá reflejando las actividades realmente desarrolladas en la actuación, y la versión final deberá incluir:

Objetivos, alcance y metodología empleada, señalando los criterios a utilizar para recoger las muestras a emplear en la realización de las pruebas.

Documentar el trabajo realizado para soportar las conclusiones del informe. Evidencias para la revisión del trabajo realizado, señalando las referencias al resto

de los papeles de trabajo. Punto de control: señala el objetivo de control a supervisar para ver en qué forma se tienen identificados y bajo control los riesgos asociados. En función del objetivo y alcance de la actuación podrán definirse varios puntos de control, que serán las consideraciones genéricas a tener presentes durante la actuación. Directriz de auditoría: para cada punto de control identifica qué tareas deben efectuarse con carácter previo o durante la actuación, desde la obtención de la comprensión del entorno a auditar (incluida la obtención de evidencias), la evaluación de los controles existentes, la valoración de la suficiencia y adecuación de los mismos, y la justificación de los hallazgo. El nivel de detalle de las directrices dependerá de los puntos de control, determinará los medios y las técnicas de auditoría que deben emplearse, lo que condicionará el calendario de la actuación.

Identificación de medios: se identificarán con qué medios humanos y técnicos se llevará a cabo la actuación.

Técnicas a emplear: Identifican cómo se desarrollarán las tareas durante la actuación.

Solicitud y revisión de documentación. Entrevistas. Encuestas. Observación del trabajo realizado. Pruebas de cumplimiento: Comprobaciones para determinar qué procedimientos o

controles específicos están adecuadamente establecidos, recogiendo evidencias de registros, documentos, observación del funcionamiento de pruebas específicas.

Pruebas sustantivas: Comprobación de la existencia o ausencia de errores o irregularidades.

Uso de herramientas informáticas: pueden ser específicas para la generación de muestras, o las de la organización obtener información de los SSII existentes.

Calendario: planificación de las tareas identificadas señalando en qué momento de la actuación se llevarán a cabo. Como ejemplo, COBIT cuenta con una directriz genérica para elaborar el guión de una actuación. El Comité Directivo de COBIT y el IT Governance Institute han elaborado el documento “Directrices de Auditoría”, que señala para cada uno de los 34 objetivos de control de alto nivel los pasos a seguir, indica las directrices de auditoría detalladas a tener en cuenta y las herramientas de auditoría a emplear en la actuación. Aunque dado lo genérico del planteamiento de COBIT, el auditor debe adecuar lo señalado por la metodología y hacerlo aplicable al entorno de la organización auditada.



COBIT cuenta también con los puntos de control que se obtienen a partir de los 34 objetivos de control de alto nivel, los que a su vez se subdividen en otros con mayor detalle. En COBIT los objetivos de control se agrupan en cuatro dominios que se corresponden con un ciclo de control de cuatro etapas: planificación, implementación, revisión y mejora. Cabrían consideraciones similares al emplear otras referencias metodológicas que señalan las mejores prácticas, como ITIL para la gestión de servicios TIC, o ISO/IEC 27002 para los sistemas de gestión de la seguridad de la información. Considerando que las auditorías informáticas suelen enfocarse en el análisis de situaciones de riesgos informáticos en áreas de actividades concretas, por ejemplo la seguridad física de los locales del centro de tecnologías de la información o la seguridad lógica de los sistemas de información, en este apartado se señalarán los principales puntos de control a tener en cuenta según la naturaleza de la auditoría. A continuación algunos controles asociados a tipos de auditorías. Auditoría de la dirección de tecnologías de la información: evaluar las áreas de riesgo relativas a cómo se planifican, organizan, coordinan y controlan las actividades propias del órgano con responsabilidad y competencias en TIC. Los controles a tener en cuenta serán:

Planificación: Comité para la planificación y seguimiento de actividades TIC, existencia de un Plan Director o Estratégico de Sistemas de Información y Comunicaciones, otros planes relacionados.

Organización y coordinación: Ubicación de la Unidad con competencias TIC dentro de la Organización, descripción de funciones y responsabilidades de la Unidad TIC, marco metodológico, recursos humanos, gestión económica, gestión de proyectos.

Protección contra delitos informáticos: medidas preventivas y controles sobre los sistemas de información para evitar su uso no autorizado o el de los datos, ya sea por personal propio, personal de apoyo o terceros.

Control interno: Definición de políticas y su desarrollo normativo, seguimiento, directrices de auditoría interna, ajuste a la normativa vigente.

Auditoría de la seguridad: evaluar la función de seguridad en la Organización, y cómo se articulan las medidas para controlar las vulnerabilidades de los entornos físicos y lógicos TIC.

Prácticas Comunes de Seguridad: Aspectos organizativos, políticas de Seguridad aplicados a los sistemas TIC, planes para contingencias y desastres, programas de seguridad, aspectos de personal, seguridad en los accesos de terceras partes a los sistemas TIC, cesión de datos e intercambio de información con terceras partes, gestión de incidencias, documento de seguridad de los datos de carácter personal.

Objetivos de la Seguridad Física: Entornos físicos e inventario de activos a proteger, establecimiento de áreas seguras, protección contra siniestralidad natural y delictiva, protección contra el fuego, suministro eléctrico, perímetro de seguridad física y su protección contra la intrusión, controles de accesos a las instalaciones, protección de medios empleados para el respaldo de la información, seguridad en la reutilización o eliminación de equipos y soportes magnéticos, actuación en caso de sustracción de equipos, contratos de soporte, asistencia, servicios de seguridad y pólizas de seguros, mecanismos para la resolución de incidencias.

Objetivos de la Seguridad Lógica: Inventario de activos a proteger, proceso de autorizaciones, restricciones de acceso lógico a los sistemas, gestión de cambios en el software, mecanismos para el respaldo del software y datos seguridad de los datos, monitoreo y detección de actividades ilícitas.

Auditoría del equipamiento informático:

Planificación de la infraestructura tecnológica: determinar el ajuste y la evolución de la infraestructura a los cambios tecnológicos y al soporte de la actividad de la organización, plataforma HW y plataforma SW.

Inventario: detectar el ajuste de los medios empleados a la legalidad vigente, y su uso como herramienta para la planificación de otras áreas, registro de los componentes, requerimientos legales y contractuales, planificación de recursos.



Mantenimiento HW: analizar los procedimientos seguidos para asegurar la correcta operatividad del equipamiento informático, adecuación del personal propio, garantías de los productos, gestión de los contratos de mantenimiento, gestión de incidencias.

Puestos de trabajo: análisis de la especialización, la protección de los recursos, los estándares de hardware y software, la protección de programas de ordenador, el almacenamiento de información, la formación, el soporte a usuarios, etc.

Redes de área local: evaluación de los controles establecidos para minimizar los riesgos asociados en las áreas centradas en desarrollo, explotación, seguridad y comunicaciones, arquitectura y organización, aplicaciones soportadas en red, gestión de la red, seguridad de la red.

Auditoría de la explotación de los sistemas de información: asegurar la correcta y segura operación de los recursos para el tratamiento de la información.

Procedimientos y responsabilidades de operación: Documentación de los procedimientos operativos, control de cambios operacionales, procedimiento de gestión de incidencias.

Planificación de los trabajos. Segregación de tareas dentro de la Unidad. Protección contra software malicioso en productos externos o en desarrollos propios. Utilización y seguridad en los soportes de información. Intercambio de información con el exterior. Protección contra fraudes informáticos: medidas técnicas y organizativas adoptadas

para evitar el uso fraudulento de datos o aplicaciones, o para contrarrestar posibles ataques informáticos (caballo de Troya, puertas falsas, ataques internos, ataques externos, sustitución de la identidad, pinchado de líneas, etc.)

Auditoría de la contratación de bienes y servicios TIC: se verificarán las políticas y los procedimientos de adquisición establecidos por la Organización. Dado que en la Administración Pública los organismos están sujetos al marco que establece la Ley de Contratos, su reglamento, así como otras disposiciones normativas; la auditoría se centrará en verificar el cumplimiento de los mismos. Además, debe asegurarse que la interpretación del marco legal se ha implementado con procedimientos internos adecuados, y que los mismos aseguran los principios de transparencia e igualdad de oportunidades para que los posibles oferentes puedan realizar la oferta más conveniente para la Organización.

Organización de la contratación: Se analizará la fluidez y operatividad de las relaciones con otras unidades de la Organización o externas que intervienen en el proceso de contratación.

Criterios seguidos en la planificación de las contrataciones: Área responsable, ajuste a los planes estratégicos y partidas presupuestarias, mecanismos para hacer frente a las demandas extraordinarias, criterios usados para la determinación de los techos presupuestarios.

Políticas y criterios para la adquisición de bienes y servicios informáticos: Formación en contratación TIC del personal técnico directivo, criterios de contratación (tipos de contratos), objeto del contrato con adecuado nivel de detalle, requisitos mínimos detallados y cuantificados, criterios de adjudicación objetivos, clausulado especial incluido en los pliegos de cláusulas específicas, criterios seguidos para la adjudicación de los contratos.

Otros tipos de auditorías de sistemas de información

Control de accesos Bases de datos Técnica de sistemas Calidad de los productos desarrollados Seguridad en las comunicaciones Gestión de la continuidad del servicio informático Acreditación de servicio de confianza.



También se debe hacer mención a las actuaciones de auditoría de sistemas de información que cubran requerimientos dados por la normativa vigente en España, tales como:

Protección de datos: analizar el grado de cumplimiento a las directrices establecidas por la Ley Orgánica 15/1999, de protección datos de carácter personal (LOPD) y por su reglamento.

Aprobación de programas que ejercen potestades: Se deberá comprobar que los programas se adecuan a los procedimientos, según lo establecido en el Real Decreto 263/1996, por el que se regula la utilización de técnicas electrónicas, informáticas y telemáticas por la Administración General del Estado, y su adecuación a los criterios de seguridad, normalización y conservación señalados por la Resolución de la Secretaría de Estado de Administración Pública del 26 de mayo de 2003.

Registros Telemáticos: Se deberá identificar su existencia y comprobar el cumplimento de la legislación asociada.

Esquema Nacional de Seguridad.

4.2 Informes de auditoría

El objetivo fundamental del Informe de Auditoría es la comunicación de los resultados de la actuación a los usuarios u órganos directivos competentes de la organización. Su redacción debe ser clara para evitar en lo posible que se preste a interpretaciones diferentes a las que el auditor hubiese concluido. El informe además servirá para facilitar el seguimiento y comprobar posteriormente que se han tomado las acciones correctivas adecuadas.

Asunciones: todo lo que se refleje en el informe de auditoría debe ser consecuencia de asunciones explícitas, probadas y que puedan ser desafiadas. El informe debe redactase con la habilidad suficiente para que la organización pueda ser capaz de ejecutar los resultados según lo esperado.

Leguaje empleado: se cuidará el lenguaje y la gramática. Se evitará el empleo de tecnicismos propios de las TIC, en especial cuando los destinatarios del informe no sean técnicos en la materia.

Versiones del informe: la primera versión de la redacción será el borrador del informe, que debería ser cumplimentado lo antes posible, e incluirá todos los hechos, conclusiones y recomendaciones. El borrador se remitirá a la dirección del área auditada, sujeto a revisión, y su calidad de documento reservado. Al final del período de respuesta, y después de revisar y en su caso tomar en consideración las observaciones remitidas por el área auditada sobre el borrador, se elaborará el informe final de la auditoría. Si el equipo de auditoría no coincidiese con alguno de los comentarios realizados sobre el borrador, deberán ser explicadas las razones e incluidas en el informe final, que a su vez incluirá la respuesta recibida.

Distribución del informe: El informe se distribuirá a quienes, en función de la normativa interna establecida, sean competentes para conocerlo. Cuando los contenidos del informe sean considerados como sensibles para los intereses de la organización, se asegurará la restricción de la circulación del informe, que se reflejará en el propio informe para garantizar el grado de confidencialidad requerido.

Otros entregables: Las recomendaciones incluidas en el informe podrán dar lugar a instrucciones en un documento independiente, que serán dirigidas a la dirección de la unidad auditada, sugiriendo acciones para resolver las incidencias detectas en el sistema de control.

Si el informe es muy extenso o muy técnico, sería conveniente la preparación de un resumen ejecutivo para que pueda ser analizado con detenimiento por los órganos de dirección. CONTENIDO DEL INFORME Todos los informes contendrán unos apartados comunes con unos contenidos mínimos. Título: univoco + ámbito + alcance + unidad auditada + fecha + código de identificación, archivo y recuperación posterior.



Índice: todos los apartados incluidos con referencia a las páginas de su ubicación + anexos. Introducción: razones por las que se realiza la actuación de auditoría. Objetivo y alcance del trabajo desarrollado: objetivo perseguido y tipo de auditoría efectuada. El alcance de la actuación deberá estar en consonancia con los objetivos, señalando la profundidad del trabajo realizado, mencionando expresamente las técnicas empleadas y el tipo de comprobaciones efectuadas para evaluar la información. Establecer tanto dentro del alcance, como fuera del alcance. Metodología: descripción de las tareas realizadas en el curso de la actuación: técnicas de muestreo (aleatorias o no), prácticas realizadas (reuniones, entrevistas, encuestas, verificaciones, etc.), identificar los interlocutores por su cargo o puesto (y no por su nombre), indicar los documentos solicitados al órgano auditado (se incluirán en los anexos si contribuyen a la motivación de la exposición). Resultados de la actuación: se describirá y documentará las actuaciones realizadas y las evidencias obtenidas, que darán lugar a las conclusiones y propuestas del informe. Deberán documentarse los resultados para cada punto de control incluido en el alcance. Para estructurar los resultados de una forma convincente se podrá seguir el siguiente proceso en la exposición de los elementos:

Criterio: Descripción de los estándares empleados para determinar si un programa de control alcanza los resultados esperados.

Condición: Situación encontrada, que ha sido determinada y documentada durante la auditoría.

Efecto: Puede ser la medida de la consecuencia positiva o negativa de la variación de la condición respecto de los criterios determinados, o bien el impacto logrado por la aplicación de un programa para cambiar ciertas condiciones.

Causa: Motivo de la desviación de los rendimientos fijados (auditorías operativas conclusiones claramente expresadas) o del cumplimiento de pautas preestablecidas (auditoría de cumplimiento debilidades detectadas son deficiencias + fortalezas).

Se incluirán en el informe todos los incumplimientos y abusos significativos que hayan sido detectados durante o en conexión con la auditoría. El término incumplimiento comprende actos ilegales e inobservancia de normas o controles internos. Por abuso se entenderá toda conducta que se desvía de las expectativas de conducta deseable. Si el informe se realiza como consecuencia de una auditoría anterior, cada epígrafe señalará las medidas que el gestor haya decidido adoptar como consecuencia de las conclusiones y recomendaciones contenidas en los anteriores informes. Conclusiones y recomendaciones: formulación de propuestas, siendo sin duda la parte más relevante y probablemente la más leída del informe. Las conclusiones deben redactarse de forma que se puedan comprender sin necesidad de acudir al resto del informe, o a sus anexos, y recogerán todos los hechos significativos detectados en la actuación. Con objeto de facilitar el seguimiento de las recomendaciones de una auditoría anterior, en el informe se deberá manifestar la situación en que se encuentran los defectos significativos puestos de manifiesto entonces y no corregidos, así como identificar las posibles consecuencias negativas que pudieran derivarse de no corregir las deficiencias señaladas en la ocasión anterior. Las conclusiones se pueden redactar de forma:

Descriptiva: Descripción de los hechos más significativos. Se podrán orientar a evaluar la eficacia o eficiencia de los controles implementados. Este criterio es aplicable en auditorías operativas o de cumplimiento.

Dictamen: Juicio crítico que determinará el grado de ajuste de los controles a lo esperado Favorable/cumple, desfavorable/no cumple, cumple parcialmente.



Grado de madurez: Evaluación de los controles de las áreas auditadas. En este caso, para cada punto de control se aplicará una escala de medición incremental sobre la forma en que se gestiona el riesgo. Este criterio es aplicable en auditorías operativas.

Las recomendaciones se efectuarán cuando supongan una potencial mejora en el funcionamiento y harán referencia a las conclusiones de las que se derivan. Deben tener un carácter ejecutivo, es decir, comprometerán a la organización para su realización, ya que ponen en evidencia deficiencias del sistema de control. Serán descripciones de las tareas más importantes a realizar para asegurar los mejores controles posibles, y serán tanto más útiles cuanto que se dirijan a resolver las causas de los problemas detectados, deben guardar una debida proporción en materia coste-beneficio con la escala de la organización. El informe no sólo reflejará desviaciones negativas, sino que hará constar los logros más notables alcanzados por la unidad auditada, en particular cuando las mejoras de las prácticas puedan ser aplicables por otras áreas de la organización. En todo caso, deberá ponerse en conocimiento de la alta dirección o del Servicio Jurídico las prácticas irregulares detectadas. Si durante el transcurso de la actuación se descubrieran cuestiones importantes no relacionadas con el objeto de la auditoría que se está realizando y que requieran un trabajo adicional, deberán reseñarse en el informe junto con las razones que justifiquen un trabajo suplementario posterior, de cara a que se tenga en cuenta en la planificación de auditorías futuras. Anexos: detalles e informaciones adicionales que contribuyan a una mejor comprensión de los aspectos más importantes incluidos en el informe. OTRAS CONSIDERACIONES Fecha de emisión y firma: el informe deberá estar fechado, con la fecha del momento final de su elaboración, y firmado en todas sus páginas por el auditor encargado del trabajo, y podrá contener las condiciones profesionales del equipo de trabajo. Plazo de entrega: deberá presentarse en las fechas establecidas. Si los hechos identificados durante fueran considerados de importancia, se podrán emitir informes previos parciales, de carácter provisional, ya que puede ser conveniente una actuación correctiva inmediata. Alegaciones de los auditados: los responsables del área auditada revisan el borrador del informe y formulan las alegaciones y comentarios que consideren oportunos. Al incluir las alegaciones de los auditados se logra que los informes no sólo indiquen lo que se descubre y la opinión de los auditores acerca de tales hechos, sino también lo que piensan sobre ello los responsables y qué es lo que se proponen hacer al respecto. Las alegaciones deben constar por escrito, serán evaluadas objetivamente e introducidas en el informe final. Cuando estos comentarios sean contrarios a los juicios y conclusiones que aparecen en el borrador del informe, al auditor debe considerar las siguientes alternativas:

Si se consideran justificadas, se introducirán las oportunas modificaciones antes de elevar el informe definitivo, no sin antes obtener la suficiente evidencia que soporte el cambio de posición.

Si no se está conforme con los comentarios recibidos deberá señalarse esa circunstancia en el informe, añadiendo las observaciones de por qué no se aceptan las alegaciones del órgano auditado.

Una vez transcurrido el plazo concedido para que la Unidad auditada realice las alegaciones y no hubiere contestado, los auditores deberán elevar el borrador del informe a informe definitivo, haciendo constar especialmente en él las razones por las que no se incluyen las alegaciones.



BIBLIOGRAFÍA

www.wikipedia.org

Módulo “Auditoría y Sistemas de Información”, II Curso de Auditorías de Sistemas de

Información (INAP), impartido por Vicente Peirats Cuesta en 2006.

Módulo “Método y Práctica de la Auditoría de Sistemas de Información”, II Curso de Auditorías

de Sistemas de Información (INAP), impartido por Fernando Rodríguez Rivadulla en 2006.

Módulo “Confianza en los sistemas de información y Criterios de Seguridad, Normalización y

Conservación de las aplicaciones usadas en el ejercicio de Potestades, II Curso de Auditorías de

Sistemas de Información (INAP), impartido por Miguel Ángel Amutio Gómez en 2006.

Information Systems Audit and Control Foundation: COBIT 4th Edition.

www.isaca.org/Content/NavigationMenu/Members_and_Leaders/COBIT6/Obtain_COBIT/CobiT4

_Espanol.pdf

www.auditoresdesistemas.com. Institute of Internal Auditors: Model Curriculum for Information

System Auditing, Agosto 1992. ISBN 0-89413-274-1 IGAE: Normas de Auditoría del Sector

Público.

www.igae.minhac.es/Normas_Auditoria_Sector_Publico.htm

Instituto de Contabilidad y Auditoría de Cuentas: Norma Técnica de Auditoría sobre “la

auditoría de cuentas en entornos informatizados”. www.icac.mineco.es/consultas/ENTIN.HTM

Auditoría Informática, Un Enfoque Práctico 2ª Edición, Mario G. Piattini y Emilio del Peso,

Editorial RA-MA. ISBN 8478972935

Auditoría de los Sistemas de Información, Rafael Bernal Montañés y Óscar Coltell Simon,

Editorial Universidad Politécnica de Valencia. ISBN 8477213933.

Normas de Auditoría del Sector Público. IGAE.

www.igae.pap.meh.es/Internet/Cln_Principal/ClnPublicaciones/ClnNormasAuditoria

Instituto de Auditores Internos de España, www.iai.es

Consejo Superior de Administración Electrónica. MAP, www.csi.map.es (criterios de seguridad,

normalización y conservación de las aplicaciones utilizadas para el ejercicio de potestades;

magerit; normativa sobre uso de técnicas electrónicas, informáticas y telemáticas en la

Administración General del Estado; normativa sobre protección de datos de carácter personal).

Instituto para el Gobierno de las Tecnologías de la Información. IT Governance Institute (ITGI),

www.itgi.org

01CC - Auditoría y Calidad del Software – Curso 06/07 – Universidad de Murcia

dis.um.es/~jsaez/acs/curso0607/

Sans Institute : www.sans.org



32. Auditoría Informática II: Protección de activos de información, recuperación de desastres y continuidad del negocio.

1. Protección de activos de información. 2. Recuperación de desastres y continuidad del negocio.

1. PROTECCIÓN DE ACTIVOS DE INFORMACIÓN La seguridad de la información abarca un campo más amplio que la seguridad informática tradicional, a la hora de hablar de seguridad de la información todo gira en torno a un eje temático: la gestión del riesgo (equilibrar el riesgo a asumir, frente al coste que suponen sus medidas de control). Tras la gestión del riesgo aparecen los planes de continuidad del negocio, que podemos definir como la capacidad estratégica y táctica, aprobada por la dirección de una organización, para planificar la respuesta a incidentes e interrupciones del negocio con objeto de continuar con las operaciones dentro de un nivel aceptable previamente definido. (Fuente BS 25999, Standard for Business Continuity Management).

Se entiende por “incidente”, cualquier evento que no es parte de la operación normal de un servicio y el cual causa, o puede causar, una interrupción o reducción en la calidad de éste: servicio no disponible; corrupción de Software; fallo hardware; detección de un virus; “caída de un sistema”; uso no autorizado de la cuenta de un usuario; uso no autorizado de Privilegios de acceso al sistema; desfase de una o más Páginas Web; ejecución de código malicioso que destruye datos, una inundación o un incendio en el CPD, la interrupción en el suministro de energía eléctrica, un calentamiento excesivo que provoque que falle un sistema, un desastre



natural… Por ello se hace necesario gestionar estos incidentes con el objetivo de restablecer las operaciones normales tan rápido como sea posible con el menor impacto sobre el negocio y sobre el usuario, de una manera eficaz en términos económicos”. Se pueden clasificar los incidentes según la estimación de sus daños en:

Incidente sin importancia: No causa daño perceptible o significativo (ej. caída breve del SO, corte de energía momentáneo si existe UPS)

Eventos menores: tienen importancia relativa, no presentan impacto material o financiero

Incidentes mayores: tienen impacto material negativo sobre los procesos de negocio, afectando a otros sistemas, departamentos o clientes.

Crisis: incidente mayor con impacto material serio sobre el funcionamiento continuo del negocio u otros sistemas.

Se puede definir “desastres” como las interrupciones que ocasionan que los recursos críticos de información queden inoperantes por un periodo de tiempo.Los desastres requieren esfuerzos de recuperación para restaurar el estado operativo, su origen puede ser:

Desastres naturales Origen humano Indisponibilidad de servicios externos

Causas Comunes de Indisponibilidad • Inundaciones (11 %) • Incendios (10 %) • Sabotajes (5 %) • Actos Vandálicos (5 %) • Fallos Hw / Sw (8 %) • Cortes prolongados de suministro eléctrico (27 %)

Las vulnerabilidades por capas se pueden expresar:

Las organizaciones necesitan definir planes de emergencia para evitar pérdidas de vidas humanas, para favorecer su evacuación. Basados en la valoración de los daños, estos planes deben preparar un entorno de continuidad en condiciones precarias.



Necesitan además un plan de recuperación para conseguir la nueva puesta en marcha del negocio (sitios fríos, templados o calientes (espejos)). Según un estudio de la Universidad de Minnesota (1996), el periodo máximo de paro de una empresa sin poner en peligro su supervivencia es de:

Sector Seguros: 5,6 días Sector Fabricación: 4,9 días Sector Industrial: 4,8 días Sector Distribución: 3,3 días Sector Financiero: 2,0 días

Para la ISO17799 los diez dominios de control a contemplar en el Plan de Continuidad son los siguientes:

La ISO1799 presenta además diez claves para asegurar la eficacia de los planes de continuidad:

1. Probar las copias de seguridad. 2. Invertir en hardware / software de backup. Balance entre tiempo / coste. 3. Separación física de las copias periódicamente. Armarios ignífugos 4. Aislamiento de equipos (sala de servidores). Refrigeración, armarios homologados

(rack), cableado estructurado. 5. Ubicación sala de servidores. No cañerías, no accesible con vehículos, no zona de

paso... 6. No descartar amenazas; priorizarlas por nivel de criticidad para la empresa

(dirección), por probabilidad e impacto. 7. Describir acciones para cada amenaza materializable.



8. Formación y concienciación: seminarios, circulares... 9. Ejecutar simulacros. “Tirar del cable”. 10. Escribir el protocolo (secuencia temporal) con datos concretos: nombres, teléfonos...

Continuidad de Negocio no es lo mismo que Recuperación frente a desastres. Continuidad de Negocio son los procesos orientados a disminuir el riesgo en el negocio evitándolos o mitigándolos; manteniendo un nivel mínimo de servicio que soporte las funciones críticas. Recuperación ante desastres es la parte reactiva y es un subconjunto del BCP (Plan de Continuidad del Negocio) constituido por los procedimientos seguidos por los departamentos de TIC para recuperar la capacidad de proceso.

1.1 Introducción a la seguridad.

La importancia de la seguridad ha crecido en los últimos años, la sensibilización de los directivos hacia este tema ha dado un giro importante. La empresa depende de sus datos y necesita asegurarlos. Hay tres principios básicos a contemplar:

el ataque siempre se produce al eslabón más débil, la caducidad del secreto: sólo proteger el dato hasta que deje de ser importante y la eficiencia y eficacia de las medidas empleadas para protegerlos.

Con respecto a los aspectos de seguridad, CobiT identificó tres elementos clave: la confidencialidad, la integridad y la disponibilidad, estos mismos elementos son empleados a nivel mundial para describir los requerimientos de seguridad. En COBIT el dominio más directamente implicado es “Delivery and Support” (Entrega y Soporte) y en concreto los procesos DS4 – Aseguramiento de servicio continuo, y DS5 –Garantizar la seguridad de los sistemas.

1.2 Tipos de seguridad

La evolución es hacia una convergencia de Modelos; si empleamos una Visión Holística debemos contemplar:

Cumplimiento legal y estándares Políticas, normativas y procedimientos Red de comunicaciones Sistemas electrónicos de protección perimetral



Tarjetas de identificación y acreditación Cerraduras y claves – jerarquización Control de identidad y presencia Logging de visitas y accesos autorizados Centro de control de alarmas e incidencias Protección y salvaguarda

Una clasificación de la seguridad en función de los medios empleados para su consecución: lógica (claves, cifrado, firma_e…) y física (catástrofes naturales, candados, cámaras videovigilancia, detección y extinción, SAI…). Las dimensiones de seguridad son: ACID (para SNC y MAGERIT) y ACID+T (para el ENS). En ambos casos necesitamos normativas y políticas de seguridad en España tenemos entre otras: LOPD (Ley 15/99), LSSI (Ley 34/2002), Ley Firma Digital (59/2003), Esquemas Nacionales de Interoperabilidad y Seguridad…

1.3 Análisis de riesgos y gestión del riesgo.

La mayor dependencia de los medios informáticos, electrónicos y telemáticos de las organizaciones, supone grandes beneficios, pero también conllevan grandes riesgos que hay que minimizar para ello es necesario realizar un análisis de riesgos con el objetivo de poder gestionarlos. Ver MAGERIT Ver SNC Ver ENS Definiciones:

Riesgo: estimación del grado de exposición a que una amenaza se materialice sobre uno o más activos causando daños o perjuicios a la Organización. El riesgo indica lo que le podría pasar a los activos si no se protegieran adecuadamente. Para ello es necesario analizar cada sistema:

Análisis de riesgos: proceso sistemático para estimar la magnitud de los riesgos a que está expuesta una Organización sabiendo la situación hay que tomar decisiones:

Gestión del riesgo: selección e implantación de salvaguardas para conocer, prevenir, impedir, reducir o controlar los riesgos identificados.



El hecho es que del establecimiento de un buen árbol de relaciones entre activos depende en gran medida la obtención de resultados significativos en el análisis de riesgos. Este árbol debe incluir todas las elaciones significativas que permitan acumular el valor de los activos Superiores sobre los activos de nivel inferior a través de los cuales aquellos pueden ser atacados, pero al mismo tiempo hay que incluir solamente aquellas relaciones que son significativas desde esta perspectiva de acumulación de valor. A la hora de hablar de riesgos es necesario hablar de costes: la idea es encontrar el equilibro entre lo que la organización está dispuesta a gastar y las pérdidas económicas o de imagen que el daño en los activos pueden ocasionar.

El riesgo se puede eliminar, reducir, asumir, transferir, o asegurar. El Coste Total es igual a la suma del Coste de Interrupción y el Coste de Recuperación: CT = CI + CR El Coste de Interrupción es función del tiempo de duración de la interrupción. Los factores que intervienen son:

Inactividad, Lucro cesante, Demora, Indirectos

CT = F(t,lna,Lc,D,Ind) El Coste de Recuperación es el asociado a la existencia de un plan de continuidad del negocio. Son necesarios recursos para: - Su elaboración - Su implantación - Pruebas y mantenimiento



Con objeto de Gestionar el Riesgo debemos establecer unos controles que nos faciliten esta tarea. Los controles se pueden clasificar de diversas maneras (como ejemplo los controles establecidos por COBIT). Una posible clasificación sería:



2. RECUPERACIÓN DE DESASTRES Y CONTINUIDAD DEL NEGOCIO. En SSII, la estrategia más habitual de recuperación es aquella que implica la activación de una réplica de la infraestructura en otro sitio alejado del emplazamiento habitual, donde haya podido acontecer el desastre. Así hablamos de sitios calientes, templados, fríos y sitios espejo calientes. Por lo tanto hay que definir la estrategia más adecuada según la relación efectividad/coste. No todos los datos requieren el mismo tratamiento:

15% son datos de Misión Crítica Datos asociados a los procesos críticos de la organización. Deben ser retenidos por motivos legales.

20% son datos vitales Son datos usados en procesos considerados normales y son de importancia para la organización, aunque no sean requeridos de forma inmediata para la continuidad del negocio.

25% Datos sensibles Datos que son usados de forma normal, pero para los cuales existe otra fuente alternativa y por tanto son fácilmente reconstruibles.

40% Datos No-Críticos Datos que pueden ser reconstruidos fácilmente.

2.1 Parámetros para definir la recuperación (RTO, RPO, …)

Tolerancia a desastre Es la brecha de tiempo en la cual el negocio puede aceptar indisponibilidad de los servicios de Tecnologías de la Información (TI).

Ventana de interrupción Es el tiempo que una organización puede esperar desde el punto de fallo hasta la recuperación de los servicios críticos. Después de este tiempo, las pérdidas progresivas causadas por la interrupción no son permisibles.

Objetivo de entrega de servicio (Service Delivery Objective SDO)

El nivel de servicios a proveer durante el modo de proceso alterno hasta que se restaure la situación normal.

Costes máximos tolerables

Tiempo máximo que la organización puede soportar procesar en modo alterno. Después de este punto, pueden surgir diferentes problemas, en especial, si el SDO alterno es inferior al SDO habitual.

Objetivo de Punto de Recuperación (RPO- Recovery Point Objective)

Se determina en base a la pérdida aceptable de datos en caso de interrupción de las operaciones. El RPO cuantifica la cantidad permitida de pérdida de datos en caso de interrupción. Existirán "Catchup data" o "puesta al día de los datos" (transacciones existentes entre el RPO y la interrupción, que deberán volver a realizarse tras la



recuperación), y datos huérfanos, son aquellos que se perderán tras recuperar las transacciones perdidas.

Objetivo de Tiempo de Recuperación (RTO- Recovery Time Objective):

Es el tiempo máximo tolerable de interrupción. Indica el punto más próximo en el tiempo en que deben recuperarse las operaciones tras la aparición del desastre. Cuanto más bajo sea el RTO más baja será la tolerancia ante el desastre. A menor RTO, más bajo será el tiempo de recuperación requerido (RTO/RPO) y más elevado será el costo de las estrategias de recuperación. Si el RPO está en minutos, el mirroring o la duplicación de datos será la estrategia de recuperación más aconsejable.

Requerimientos de los procesos críticos de negocio > Tiempo máximo de recuperación (RTO) > Pérdida máxima de información (RPO)

2.2 Tipos de planes de continuidad de negocio.

Las características principales de un Plan de Continuidad de negocio son las siguientes: Es un proceso de mejora continua de la gestión de riesgos de la organización. Está orientado a recuperar los procesos de negocio críticos. Es diseñado para integrarse con el resto de elementos de seguridad. Permite la automatización de tareas para evitar su planificación en momentos de

crisis. Tipos de planes relacionados con el objetivo de recuperación, continuidad de negocio, contingencia…

Plan de continuidad de negocio (PCN/BCP): conjunto de planes de actuación, financieros, de comunicación, de contingencias, etc.; destinados a "mitigar el impacto" provocado por la concreción de determinados riesgos sobre la información y los procesos de negocio de una compañía.

Disaster Recovery Plan (DRP): estrategia planificada en fases cuyo objetivo es

recuperar todos los servicios TIC y los recursos que los conforman en el menor tiempo posible, a partir de un evento que ocasiona una interrupción en su funcionamiento.



Bussiness Resumption Plan (BRP): plan que organiza la reanudación de los procesos de negocio de la organización que se hayan visto afectados por un fallo o incidente.

Plan de Continuidad de Operaciones (COOP): su objetivo es conseguir la continuidad

en las funciones estratégicas de una organización desempeñadas en sus instalaciones corporativas.

Plan de Contingencia (CP): su objetivo es conseguir la recuperación de los servicios y

recursos de TI después de un desastre que provoca una interrupción en su funcionamiento.

Plan de Respuesta de Emergencia: salvaguarda de los empleados, el público, el medio ambiente, así como del resto de activos de la organización ante una situación de desastre.

2.3 Alternativas para la Recuperación

Existen diferentes alternativas de recuperación en función de los parámetros que la Organización esté dispuesta a asumir (RTO/RPO). HOT SITES Totalmente configurados

Tiempo de recuperación pequeño. Listo para operar en varias horas.

Equipos, red y SW deben ser compatibles con la instalación respaldada.

Solo necesitan personal, programas, archivos de datos y documentación.

Costes elevados: Coste básico de suscripción, cuota mensual, cargos de prueba, costes de activación y cargos por uso por hora o por día.

El contrato debe incluir: la cantidad de tiempo que se necesita, la frecuencia y el tiempo especificado para pruebas.

Destinado para: operaciones de emergencia durante un periodo limitado de tiempo y no para uso prolongado (es un medio de lograr la continuidad de las operaciones esenciales durante varias semanas después del desastre o emergencia). RTO aprox. de minutos.

WARM SITES Parcialmente configurados

Instalación con cableado, electrónica de red, equipos básicos. Falta HW principal o de menor capacidad. RTO de 2- 7 días.

La ubicación e instalación de la CPU y otras unidades no disponibles llevará varios días o semanas.

Menos costoso que un Hot Site.

COLD SITES Instalación alternativa con cableado, falsos suelos, acondicionado y potencia eléctrica. RTO + de 1 semana.

Listo para recibir los equipos, pero no ofrece ningún componente en el lugar antes de necesitarse su uso. Su activación llevará varias semanas.

INSTALACIONES REDUNDANTES

Lugares de recuperación dedicados preparados para la interrupción, respalda las aplicaciones críticas. La instalación es completa con replicación de datos y/o balanceo de carga. El RTO es inmediato.

Puede adoptar varios formatos: desde “Hot site” listo y en espera, hasta contrato recíproco para uso de la instalación de otra empresa.



Principios de viabilidad: o No sujeto a los mismos desastres naturales que el sitio

principal. o Compatibilidad de HW/SW entre Principal y Respaldo.

Disponibilidad de recursos: Monitorización de las cargas de trabajo.

Necesidad de acuerdos respecto a la prioridad de agregar aplicaciones hasta que se hayan utilizado plenamente todos los recursos de recuperación

Necesidad de pruebas periódicas.

SITIOS MÓVILES Remolque diseñado que puede ser transportado rápidamente a un lugar de negocio.

Alternativa útil en el caso de un desastre expandido. Alternativa eficiente en costes para duplicar las instalaciones de

procesamiento de información de una organización con múltiples oficinas.

ATENDIENDO A SU DISPONIBILIDAD

Mirrored : Centro duplicado del entorno primario tanto en lo referente al software como a los datos.

Standby : Centro en el cual existe total o parcialmente el software y la actualización de los datos se realiza cada cierto periodo de tiempo.

Split Workload : La carga se reparte entre dos centros, aunque todo el entorno se puede respaldar en uno.

ACUERDOS RECÍPROCOS CON OTRAS ORGANIZACIONES

Los participantes acuerdan mutua provisión de tiempo de cómputo en caso de emergencia.

Ventajas: Bajo coste. Desventajas: Ausencia de obligatoriedad. Diferentes

configuraciones. Cambios no notificados en configuraciones o cargas de trabajo.



2.4 Planificación de la continuidad del negocio.

Creación de una Política de Continuidad del Negocio. Análisis de Impacto sobre el Negocio. Clasificación de las operaciones y análisis de criticidad. Desarrollo del Plan de Continuidad del Negocio. Prueba e implementación del Plan. Mantenimiento.

Instalación y configuración de infraestructura de contingencia: hw, sw,

comunicaciones, Evaluación Incidentes Desastre: Identificación de las causas y alcance de los

daños (Parcial/Total) Comité de Emergencia: Reponsables de la activación del plan y de la toma de

decisiones Staff de emergencia: Personal involucrado en la recuperación (sistemas,

comunicaciones, etc.) Recursos necesarios: HW, SW, dispositivos de comunicaciones, etc.

Contactos con soporte, proveedores, etc. Procedimientos de Recuperación de Sistemas/Servicios: Procedimientos

específicos de recuperación ante desastres y adicionales a la operación diaria



Procedimientos de Recuperación de Comunicaciones Procedimientos de Recuperación de Áreas de Usuarios

Pruebas y simulacros Validación del entorno de contingencia: infraestructuras, procedimientos y

requisitos del BIA (procesos, tiempos y datos) Metodología de mantenimiento del Plan Gestión On-site: de sistemas, aplicaciones y comunicaciones Gestión Remota

Algunas soluciones tecnológicas:



El concepto de failover extendido a varias localizaciones se convierte en una solución de recuperación automática ante desastres. Las mismas tareas realizadas en el CPD A pueden ser realizadas en el CPD B de forma automatizada y viceversa. Algunas de las opciones que nos proporciona la tecnología actual para llegar a este objetivo (ver Bloque IV de comunicaciones al completo):

GSLB – Global Server Load Balancing (implementados históricamente basados en DNS, también en BGP-Border Gateway Protocol).

Routing dinámico Entradas DNS Múltiples Extensión de VLANs Extensión de VLANs - Resumen

Para todo lo anterior es necesario llevar una serie de actuaciones como Creación de una política de continuidad del negocio

Compromiso y apoyo de la dirección. Elaborar un caso de negocio para buscar apoyo. Vender la necesidad de un PCN. Generar concienciación. Aproximación Top-Down. Amplio conocimiento del Negocio

Análisis de impacto en el negocio (BIA)

Identificar los activos críticos Análisis de Riesgos Identificar los eventos Tiempos críticos de recuperación Determinar los costes de recuperación Gestión de

Riesgos Asignar prioridades a los sistemas

Clasificar activos y su criticidad Crítico: No pueden ser reemplazadas por métodos

manuales. La tolerancia a interrupción es muy baja. El coste de la interrupción es muy alto.

Vital: Pueden realizarse manualmente por un breve periodo de tiempo (5 días o menos). Mayor tolerancia a la interrupción. Costes de la



interrupción más bajos. Sensible: Se pueden realizar manualmente, a un

coste tolerable y por un periodo prolongado de tiempo; pero es un proceso difícil que requiere de personal adicional.

No crítico Definición de la estrategia de recuperación

Combinación de medidas preventivas, detectivas y correctivas: si es posible eliminar la amenaza, pero también minimizar la probabilidad de la ocurrencia y el impacto.

Identifican: la mejor forma de recuperar un sistema en caso de interrupción.

Proveen: una orientación basada en qué procedimientos detallados de recuperación se pueden desarrollar.

Se desarrollan diferentes estrategias y se presentan a la dirección.

La alta dirección: selecciona la estrategia más apropiada y acepta el riesgo residual inherente.

Utilidad: desarrollar el Plan detallado de Continuidad del Negocio.



2.5 Estructura y desarrollo del plan

El Plan de Contingencia hay que considerarlo como un proceso evolutivo. Debe ser actualizado en función de las necesidades que aparezcan como consecuencia de cambios en las instalaciones, nuevas funcionalidades soportadas, etc. El Plan de Continuidad de Negocio (PCN) contempla acciones precisas que van orientadas a recuperar las funciones críticas del negocio. En este punto es necesario distinguir entre un plan de contingencias y un plan de continuidad de negocio. En un Plan de Contingencias se presume que hay una interrupción de los servicios durante un tiempo, sobre el cual se declara la emergencia, y entran a operar una serie de procedimientos que permiten que el servicio se restablezca en el menor tiempo posible. El enfoque del plan de contingencia se basa en la minimización del impacto y del tiempo de parada y se concentra en la recuperación de los sistemas causantes de la interrupción del servicio. El Plan de Continuidad está orientado, como su nombre indica, a asegurar la continuidad de los servicios ofrecidos a pesar de una catástrofe, como puede ser un terremoto, un incendio, una inundación. Su objetivo es alcanzar una disponibilidad total para la infraestructura crítica, lo que implica que el sistema siempre estará disponible. Por PCN se entienden las acciones de alto nivel emprendidas con la aparición de un evento de tipo catastrófico, y conducentes a preparar los medios humanos y técnicos con el fin de recuperar las operaciones de la organización con el nivel de servicio acordado. Incluye: el procedimiento de activación del equipo de dirección de la recuperación y su colaboración con otras unidades de negocio involucradas.



Planes de Contingencia Operativa (PCO) tienen que ver con la recuperación tecnológica de los Servicios proporcionados por Sistemas de Información y Redes de Comunicaciones. E fundamental la revisión periódica del Plan de Continuidad de Negocio para mantener su operatividad y vigencia. Es por ello por lo que se requiere la realización de pruebas periódicas para adecuarlo a las necesidades que aparezcan como consecuencia de cambios en las instalaciones, nuevas funcionalidades soportadas, cambios en la organización que lo pudieran afectar, etc. La metodología seguida en la definición del Plan de Continuidad se ajusta a lo establecido en el estándar británico BS7799 (antes ISO/IEC 17799, hoy ISO/IEC 27002).

Centro de Respaldo

Un centro de respaldo por sí sólo no basta para hacer frente a una contingencia grave. Es necesario disponer de un Plan de Contingencias corporativo. Este plan contiene tres subplanes que indican las medidas técnicas, humanas y organizativas necesarias en tres momentos clave:

El plan de respaldo. Contempla las actuaciones necesarias antes de que se produzca un incidente. Esencialmente, mantenimiento y prueba de las medidas preventivas.

El plan de emergencia. Contempla las actuaciones necesarias durante un incidente. El plan de recuperación. Contempla las actuaciones necesarias después de un

incidente. Básicamente, indica cómo volver a la operación normal. Diseño de un centro de respaldo Un centro de respaldo se diseña bajo los mismos principios que cualquier CPD, pero bajo algunas consideraciones más:

En primer lugar, debe elegirse una localización totalmente distinta a la del CPD principal con el objeto de que no se vean ambos afectados simultáneamente por la misma contingencia: a unos 10 y 20 kilómetros del CPD principal, en función de las necesidades de telecomunicaciones entre ambos centros.

En segundo lugar, el equipamiento electrónico e informático del centro de respaldo

debe ser absolutamente compatible con el existente en el CPD principal. No no es necesario duplicar todo el equipamiento, ni mantener el mismo nivel de servicio en caso de emergencia. La Sala técnica de un centro de respaldo recibe estas denominaciones en función de su equipamiento:

• Sala blanca cuando el equipamiento es exactamente igual al existente en el CPD principal. • Sala de back-up cuando el equipamiento es similar pero no exactamente igual.

En tercer lugar, el equipamiento software debe ser idéntico al existente en el CPD principal: mismas versiones y parches del software de base y de las aplicaciones que estén en explotación en el CPD principal. De otra manera, no se podría garantizar totalmente la continuidad de operación.

Por último, es necesario contar con una réplica de los mismos datos con los que se

trabaja en el CPD original.

Sincronismo de datos Existen dos políticas o aproximaciones a este problema:

La copia síncrona de datos Se asegura que todo dato escrito en el CPD principal también se escribe en el centro de respaldo antes de continuar con cualquier otra operación.

La copia asíncrona de datos No se asegura que todos los datos escritos en el CPD principal se escriban inmediatamente en el centro de respaldo, por lo que puede



existir un desfase temporal entre unos y otros. Puede ser off-line, en base a la última copia de seguridad existente.

Esta opción es viable para negocios no demasiado críticos, donde es más importante la continuidad del negocio que la perdida de datos (ej. cadenas de supermercados o pequeños negocios) pero es inviable en negocios como la banca, donde es impensable la pérdida de una sola transacción económica.

En los demás casos, la política de copia suele descansar sobre la infraestructura de almacenamiento corporativo: redes SAN y cabinas de discos con suficiente inteligencia como para implementar dichas políticas. Tanto para la copia síncrona como asíncrona, es necesaria una extensión de la red de almacenamiento entre ambos centros: un enlace de telecomunicaciones entre el CPD y el centro de respaldo. En caso de copia síncrona es imprescindible que dicho enlace goce de baja latencia. Motivo por el que se suele emplear un enlace de fibra óptica, que limita la distancia máxima a decenas de kilómetros. Existen dos tecnologías factibles para la copia de datos en centros de respaldo: iSCSI o Fiber Channel Resumimos los factores a considerar en el desarrollo del Plan:

Estar preparado antes del desastre, cubriendo la gestión de respuestas a cualquier tipo de incidentes.

Procedimientos de evacuación. Procedimientos para declaración del desastre. Circunstancias bajo las cuales se debe declarar el desastre (no todas las

interrupciones son desastres). Identificación de responsables y responsabilidades en el Plan. Identificación de información de los contratos. Identificación de los procesos a recuperar. Identificación de los diversos recursos requeridos para la recuperación. Aplicación paso por paso de la etapa de recuperación.

Componentes de un BCN:

Plan de Recuperación del Negocio (BRP) Plan de Continuidad de Operaciones (COOP) Plan de Soporte de la Continuidad / Plan de Contingencia de TI Plan de Comunicaciones de crisis Plan de Respuesta a incidentes Plan de Recuperación ante desastre (DRP) Plan de Emergencia de Ocupantes (OEP)

En la Introducción del Plan debemos reflejar:

• Objetivos • Requerimientos previos • Hipótesis (mapa de negocio, mapa de servicios, time frame, …) • Instrucciones de uso • Lista de ejemplares distribuidos

Organización de los equipos de emergencia • Inventario de equipos • Descripción de personal • Directorio de contacto por equipos • Localización de emergencia (CPD primario o de respaldo)

Plan de Acciones • Estrategia global



• Estrategia por equipos de emergencia Comunicaciones (CPD principal y respaldo)

• Inventario de líneas • Mapas de la red • Equipos de comunicaciones • Software de comunicaciones

Anexos • Anexo I : Directorio de Suministradores • Anexo II : Directorio de Usuarios

Otros Documentos

• Estrategia por entorno de negocio • Estrategia por equipo de emergencia • Estrategia de vuelta a la normalidad

Organización de Responsabilidades (se puede utilizar la matriz RASCI): Equipo de acción ante emergencia

Es el primer equipo de respuesta. Responsable de la evacuación ordenada del personal y de garantizar vidas humanas

Equipo de evaluación de daños Evalúa el grado de los daños una vez ocurrido el desastre. Además, sus miembros deben tener capacidad de estimar el tiempo requerido para las operaciones de recuperación en el lugar afectado.

Equipo de administración de la emergencia

Responsable de coordinar las actividades de los demás equipos y de la toma de decisiones clave. Determina la activación del BCP.

Equipo de almacenamiento en sede alternativa (offline)

Responsable de obtener y enviar los medios y los registros a las instalaciones de recuperación.

Equipo de sw Responsable de restaurar el SW del sistema y sus actualizaciones.

Equipo de sw de aplicaciones Se desplaza al lugar de recuperación del sistema y restaura los paquetes y programas de aplicación de usuario.

Equipo de seguridad Monitoriza el sistema de seguridad y los enlaces de comunicación, resolviendo cualquier conflicto.

Equipo de operaciones de emergencia

Operadores de turno que administrarán las operaciones del sistema durante todo el desastre y los proyectos de recuperación.

Equipo de recuperación de red Responsable del redireccionamiento del tráfico de datos y voz de la WAN. Restablece acceso al lugar de recuperación del sistema.

Equipo de comunicaciones Establece una red LAN en el lugar de recuperación. Equipo de transporte Responsable de coordinar el transporte de los

empleados de la compañía al sitio de recuperación.

Equipo de preparaciones de datos y registros

Actualiza la base de datos de aplicaciones desde los terminales instalados en el sitio de recuperación.

Equipo de soporte administrativo Equipo de suministros Apoya al equipo de HW, contactando con vendedores y



coordinando los suministros TI y de oficina.

Equipo de reubicación Coordina el traslado al sitio alternativo, o bien, a la ubicación original restaurada.

Equipo de coordinación Coordina los esfuerzos de recuperación en caso de diversas oficinas distribuidas geográficamente.

Equipo de asuntos legales Equipo de pruebas de recuperación

Según la norma BS25999-1 “Code of practice for business continuity management”, todos los documentos deberían incluir los siguientes apartados comunes:

Propósito y alcance Funciones y responsabilidades del personal Procedimiento o normas de activación Propietario y responsable del mantenimiento del plan

Para los Planes de Gestión de Crisis en particular, la norma BS25999-1 establece además:

Acciones o tareas Contacto con las personas Contacto con los medios Contacto con los principales implicados (gobiernos, accionistas, etc.) Centro de gestión de crisis Anexos (planos, listas de contactos internos y externos, etc.)

En cuanto a los Planes de Continuidad de Negocio, (PCNs) la norma BS25999-1 establece además de lo anterior:

Lista de tareas Requerimientos de recursos Información vital Personas responsables Formularios y Anexos

El último componente de una estrategia de BCM efectiva es un personal formado, entrenado y concienciado. Pueden emplearse variedad de métodos para conseguirlo, como aplicaciones Intranet, simulacros y sesiones de formación. En Plan debe contener un directorio del personal clave que necesario para iniciar y llevar a cabo los esfuerzos de recuperación.

Jefes de equipo Proveedores Hardware/Software Suministradores Instalaciones alternativas Almacenamiento en el centro alternativo Compañías de seguros Empresas contratadas Agencias legales y gubernamentales

El desarrollo del plan quedaría como sigue:



Fases del Plan de Continuidad de Negocio

Acciones en situación de emergencia Notificación Declaración de emergencia Recuperación de sistemas Recuperación de la red Recuperación de operaciones Operaciones de salvamento Procedimientos de reubicación

2.6 Prueba e implementación del Plan.

Las fases que hay que llevar para probar correctamente: Programación de la prueba: Durante un periodo que minimice las interrupciones a las operaciones normales. Personal: Es importante que los miembros clave del equipo de recuperación participen en el proceso de prueba y se les conceda tiempo para tal actividad. Objetivos de la prueba del Plan de Continuidad de Negocio

Verificar que la documentación es completa y exacta Evaluar el rendimiento del personal involucrado en el ejercicio Evaluar la coordinación entre el equipo de contingencia y los proveedores Medir la capacidad de recuperación Evaluar el estado y cantidad de consumibles reubicados en la sede alternativa Medir el rendimiento general de las actividades para mantener la capacidad del

negocio Tipos: en papel, preparación, operativa Fases de la prueba: preparación, prueba y análisis de resultados Métrica de resultados: tiempo, cantidad, calidad y exactitud



EQUIPO DE PRUEBAS: Director del Plan de Contingencias Coordinador del Plan de Contingencias Al menos el Responsable y un componente de los siguientes equipos o grupos : • Operaciones • Soporte Técnico • Bases de Datos • Logística • Control de la Producción • Sistemas • Comunicaciones • Aplicaciones (un componente por aplicación)

2.7 Mantenimiento del Plan.

Es necesario debido a: Estrategias emergentes Nuevas aplicaciones Modificaciones en Estrategia de negocio Cambios de la infraestructura

Debe existir un Coordinador que realice las siguientes funciones: Elaboración de los procedimientos de mantenimiento Planificación anual del mantenimiento Elaboración de presupuestos para mantenimiento Elaboración periódica de versiones actualizadas del documento de Plan de Contingencias Planificación de las pruebas a realizar Dirección de las pruebas del plan Confección y distribución (controlada con una lista cerrada de destinatarios) de informes sobre pruebas (tiempos, cobertura, adecuación de procedimientos, …)



Herramientas de Soporte

Son herramientas que facilitan la formalización, el mantenimiento y la gestión del

Plan de Contingencias. Carecen de aplicación en las fases iniciales del Plan (no cubren el trabajo de campo). Su utilización como herramientas de apoyo a la toma de decisiones no excluye la

necesidad de contar con Comités de decisión al más alto nivel durante la realización del Plan.

Actividades de mantenimiento • Programa de revisiones periódicas • Revisiones no programadas • Actualización en 30 días • Análisis de adecuación del plan • Adiestramiento del personal • Registro de actividades de mantenimiento • Actualización cambios del personal



BIBLIOGRAFÍA

Módulo “Auditoría del desarrollo e implantación de sistemas de información, de adquisiciones, infraestructuras y procedimientos operativos; y de planes de contingencias, recuperación de desastres y continuidad de negocios”, II Curso de Auditorías de Sistemas de Información (INAP), impartido por Miguel Regó Fernández en 2006.

"Planes de Contingencia. La continuidad del negocio en las organizaciones.", de Juan Gaspar Martínez.

Documentos de trabajo. Ministerio de Administraciones Públicas.



33. Auditoría Informática III: Desarrollo, adquisición, implementación y mantenimiento de sistemas de Evaluación de procesos y gestión de riesgos.

1. Auditoría del desarrollo, adquisición y mantenimiento.

2. Evaluación de procesos y gestión de riesgos.

1. AUDITORÍA DEL DESARROLLO, ADQUISICIÓN Y

MANTENIMIENTO. La necesidad de que una organización cuente con procedimiento de control interno se acepta como garantía de una gestión eficaz orientada a la consecución de objetivos marcados. La función auditora es precisamente la encargada de comprobar la existencia de estos procedimientos de control y de verificar su correcta definición y aplicación, determinando las deficiencias que existan al respecto y los riesgos asociados a estas carencias de control. En concreto la función auditora aplicada al área de desarrollo y mantenimiento abarca todas las fases que se deben seguir desde que aparece la necesidad de disponer de un Sistema de Información (SI) hasta que éste es construido, implantado y entra en mantenimiento (en el contexto del tema el desarrollo no incluye. Para delimitar el ámbito de este tema sobre la explotación y la retirada de las aplicaciones). El desarrollo y mantenimiento de sistemas es un proceso costoso. Por este motivo, el auditor informático debería ser tenido en cuenta en el diseño y construcción de controles en los sistemas, asesorando sobre cuáles serían los más adecuados, según el caso. Las tareas del auditor cuando realice una revisión en esta área serán: comprender adecuadamente y evaluar la metodología seguida en el desarrollo del S.I., identificar las fases de dicha metodología, evaluar la adecuación entre el proceso de desarrollo de aplicaciones y los objetivos de la organización, revisar el cumplimiento de estándares y normas de control interno en el desarrollo o adquisición de aplicaciones y determinar si se cumplen las normas de seguridad y control de cambios.

1.1 Importancia de la auditoría del desarrollo. Planteamiento y

Metodología.

Existen una serie de circunstancias que hacen especialmente importante el área de desarrollo y mantenimiento de sistemas y por tanto, también a su auditoría, frente a otras funciones o áreas dentro del departamento de informática:

El gasto destinado al sw supera al del hw. El sw como producto es muy difícil de validar (control del proceso y del producto

calidad del proceso y del producto). Las aplicaciones informáticas son el soporte para el negocio, convirtiéndose en un

factor esencial para la gestión y la toma de decisiones. La etapa de mantenimiento consume la mayor parte de los recursos empleados en un

proyecto software (a considerar la necesidad de auditoría en esta etapa). La



mantenibilidad es el factor crítico de estudio de la auditoria de mantenimiento del SI. Entendiendo por mantenibilidad, al factor de calidad que engloba todas aquellas características del software destinadas a hacer que el SI sea más fácilmente mantenible y por tanto se consiga una mayor productividad.

El índice de proyectos de desarrollo que no alcanzan los objetivos es demasiado alto esto implica la inexistencia o mal funcionamiento de los controles en este proceso.

Para tratar la auditoría del área de desarrollo es necesario en primer lugar acotar las funciones o tareas que son responsabilidad del área:

Planificación del área y participación en función del plan director de informática o plan estratégico de informática.

Desarrollo de nuevos sistemas y mantenimiento de los existentes. Incluirá para cada uno de los sistemas, la planificación y viabilidad, análisis, diseño, construcción, implantación y mantenimiento.

Estudio y adopción de nuevos lenguajes, técnicas, metodologías, estándares, herramientas, etc. relacionadas con el desarrollo.

Establecimiento de un plan de formación para el personal adscrito al área. Establecimiento de normas y controles para todas las actividades que se realizan en el

área y comprobación de su observancia. Una vez conocidas las tareas que se realizan en el área de desarrollo y mantenimiento, se abordará la auditoría de la misma desglosándola en:

a. Auditoría de la organización y gestión del área de desarrollo y mantenimiento.

b. Auditoría de la planificación y gestión del proyecto. c. Auditoría de la fase del estudio de viabilidad. d. Auditoría de la fase de análisis. e. Auditoría de la fase de diseño. f. Auditoría de la fase de construcción. g. Auditoría de la fase de implantación. h. Auditoría de la fase de mantenimiento.

La metodología que se puede aplicar es la propuesta por la ISACA (Information Systems Audit and Control Association), que está basada en COBIT (Control Objectives tor Information and Related Technologies). COBIT en este caso analiza los riesgos de proceso de desarrollo o mantenimiento del SSII y determinan una serie de objetivos de control de alto nivel que minimicen esos riesgos. Para cada objetivo de control de alto nivel, agrupados según Métrica v3, se especifican uno o más objetivos de control que contribuyen a lograr el cumplimiento de dicho objetivo (se sigue la propuesta del autor Rodero 2001) Será la función del auditor determinar el grado de cumplimiento y madurez de cada uno de ellos. El estudio global de todas las conclusiones, pruebas y evidencias obtenidas sobre cada control permitirán al auditor obtener el nivel de satisfacción de cada objetivo de control, así como cuáles son los puntos fuertes y débiles del mismo. Con esa información, y teniendo en cuenta las particularidades de la organización en estudio, se determinarán cuáles son los riesgos no cubiertos, en qué medida los son y qué consecuencias se pueden derivar de esa situación. Estas conclusiones, junto con las recomendaciones formuladas, serán las que se plasmen en el informe de auditoría. Los auditores proporcionan una garantía razonable de que se alcanzan los objetivos de control, identifican si existen debilidades significativas en estos controles, sustanciar el riesgo que puede estar asociado a estas debilidades, y, finalmente, recomendar o asesorar a la Dirección sobre las acciones correctivas que deberían ser tomadas.



1.2 Auditoría de la organización y gestión del área de desarrollo y mantenimiento. Los proyectos de desarrollo, a pesar de que tengan entidad propia y se gestionen con cierta autonomía, necesitan apoyarse en el personal del área y los procedimientos establecidos. La importancia de estos aspectos ha motivado que sea necesario establecerse objetivos de control que faciliten la auditoria de la organización y gestión del área. Objetivo de Control 061: Procesos, organización y relaciones: El área de desarrollo debe tener definidos los procesos del área, su organización y las relaciones con el exterior. OG1-C1 Establecer de forma clara las funciones del área de desarrollo. La dirección del

área participa en el comité de dirección para determinar prioridades de proyectos, inversión TIC, seguimiento de proyectos…

O61-C2 Debe especificarse el organigrama con la relación de puestos del área, así como el personal adscrito y el puesto que ocupa cada persona, de acuerdo a las necesidades y objetivos del negocio en cada momento. Además, debe existir un procedimiento para la actualización del organigrama y para la promoción de personal.

O61-C3 Debe definirse e identificarse al personal TIC clave y minimizarse la dependencia para la realización de funciones críticas para el área en personas individuales.

O61-C4 Debe establecerse el marco de trabajo de los procesos del área de desarrollo que permita la ejecución y puesta en práctica del plan estratégico (o plan director) de las TIC. Este marco deberá incluir la estructura de los procesos y sus relaciones, propiedad, madurez y medidas de rendimiento, mejoras, conformidades, objetivos de calidad y planes para conseguirlos.

O61-C5 Las relaciones con el exterior del departamento deben de producirse de acuerdo a un procedimiento. Deben mantenerse contactos con proveedores para recibir información suficiente sobre productos que puedan ser de interés. Y debe existir un protocolo para la contratación de servicios externos (recursos humanos, hardware, software o servicios).

061-C6 Deben establecerse los roles y responsabilidades para la gestión del aseguramiento de la calidad, gestión de riesgos, seguridad y conformidad.

Objetivo de Control 062: Gestión de Recursos Humanos TIC. El área de desarrollo debe contar con unos recursos humanos adecuados para gestionar el desarrollo y mantenimiento de SI. Este proceso es crítico debido a que las personas son uno de los activos más importantes para toda organización, de manera que una buena gestión del área de desarrollo dependerá entre otros factores de la motivación, formación y aptitud de su personal adscrito. OG2-C1 Deben existir procedimientos de contratación objetivos. O62-C2 Debe existir un plan de formación que esté en consonancia con los objetivos

tecnológicos del área y alineados con los objetivos del negocio. O62-C3 Debe existir un protocolo de recepción/abandono o cambio de trabajo de las

personas que se incorporan o dejan el área o que cambian de función. OG2-C4 Debe existir una biblioteca y una hemeroteca accesibles por el personal del área

así como acceso a Internet. O61-C5 Las relaciones con el exterior del departamento deben de producirse de acuerdo

a un procedimiento. Deben mantenerse contactos con proveedores para recibir información suficiente sobre productos que puedan ser de interés. Y debe existir



un protocolo para la contratación de servicios externos (recursos humanos, hardware, software o servicios).

O61-C5 Las relaciones con el exterior del departamento deben de producirse de acuerdo a un procedimiento. Deben mantenerse contactos con proveedores para recibir información suficiente sobre productos que puedan ser de interés. Y debe existir un protocolo para la contratación de servicios externos (recursos humanos, hardware, software o servicios).

O61-C6 Deben establecerse los roles y responsabilidades para la gestión del aseguramiento de la calidad, gestión de riesgos, seguridad y conformidad.

Objetivo de Control 063: Plan estratégico de Tecnologías de la Información del área: El área de desarrollo debe participar en la definición del plan estratégico o plan director de TIC. O63-C1 El área debe tener y difundir su propio plan a corto, medio y largo plazo, que

será coherente con el plan director de TIC del departamento de informática y con el plan de sistemas, si éste existe.

Objetivo de Control 064: Dirección de la Política Tecnológica: El área de desarrollo debe participar en la dirección de la política tecnológica del departamento de informática. O64-C1 Debe de analizarse las nuevas regulaciones/reglamentaciones en materia de TIC

así como las tecnologías existentes y emergentes y determinar que política tecnológica es la apropiada para la consecución de los objetivos del área, y para el desarrollo y adquisición de nuevos sistemas o mantenimiento de los existentes compatibles con la arquitectura de los sistemas actuales o realizar un estudio de las estrategias de migración en su caso.

Objetivo de Control 065: Gestión de las Inversiones TIC: El área de desarrollo debe llevar su propio control presupuestario en lo relativo a la gestión de las inversiones en TIC.

Objetivo de Control 066: Gestión de la Calidad: El área de desarrollo debe disponer de unos procesos de desarrollo regidos por los estándares y principios de ingeniería del software ampliamente aceptados.

OGC-C1 Debe existir un registro de problemas Que se producen en los proyectos del

área, Incluyendo los fracasos de proyectos completos. OGC-C2 Debe mantenerse y comunicarse periódicamente al área las modificaciones del

plan global de calidad a fin de promover la mejora continua. OGC-C3 Debe existir un mecanismo de creación y actualización de prácticas y estándares

de calidad así como de prácticas, estándares de desarrollo y mantenimiento. OGC-C4 Debe existir un procedimiento de monitorización y medición del cumplimiento

de los estándares y prácticas de calidad así como de los de desarrollo y mantenimiento.

OGC-C5 Debe practicarse la reutilización del software. OGC-C6 Debe existir un modelo corporativo de la arquitectura de información que se

actualice regularmente y defina los sistemas apropiados que optimicen el uso de la información.

OGC-C7 Los lenguajes, compiladores, herramientas CASE, software de pruebas, software de control de versiones, etc. usados en el área deben ser previamente homologados.



1.3 Auditoría de proyectos de desarrollo y mantenimiento.

La auditoría de cada proyecto de desarrollo o mantenimiento tendrá un plan distinto dependiendo de los riesgos, complejidad del mismo y recursos disponibles para realizar la auditoría. Los controles de auditoría han sido agrupados por cada una de las fases del ciclo de vida del software identificadas como procesos en Métrica versión 3, asimismo se especifican uno o más objetivos de control de detalle o también denominadas prácticas de control, que contribuyen a lograr el cumplimiento de dicho objetivo de control de auditoría de alto nivel. La auditoría de un proyecto de desarrollo se puede hacer en dos momentos distintos: a medida que avanza el proyecto o una vez concluido el mismo. Las técnicas a utilizar y los elementos a inspeccionar, normalmente los productos y documentos generados en cada fase, serán los mismos en ambos casos. La única diferencia es que en el primer caso las conclusiones que vaya aportando el auditor pueden afectar al desarrollo del proyecto, aunque nunca participará en la toma de decisiones. Auditoría de la gestión y planificación del proyecto. Los objetivos de control que se consideran en este apartado son los siguientes. Objetivo de Control Pl: El proyecto de desarrollo debe estar aprobado, definido y planificado formalmente. Pl-C1 Debe existir una orden de aprobación del proyecto que defina claramente los

objetivos, restricciones y las unidades afectadas. Pl-C2 Debe designarse un responsable o director del proyecto. Pl-C3 El proyecto debe ser catalogado y, en función de sus características, se debe

determinar el modelo de ciclo de vida que seguirá. Pl-C4 Una vez determinado el ciclo de vida a seguir, se debe elegir el equipo técnico

que realizará el proyecto y se determinará el plan del proyecto. Objetivo de Control P2: El proyecto se debe gestionar de forma que se consigan los mejores resultados posibles teniendo en cuenta las restricciones de tiempo y recursos. Los criterios usados serán coherentes con los objetivos de las unidades afectadas. P2-C1 Los responsables de las unidades o áreas afectadas por el proyecto deben

participar en la gestión del proyecto. P2-C2 Se debe establecer un mecanismo para la resolución de los problemas que

puedan plantearse a lo largo del proyecto. P2-C3 Debe existir un control de cambios a lo largo del proyecto. P2-C4 Cuando sea necesario reajustar el plan del proyecto, normalmente en un hito al

finalizar una fase, debe hacerse de forma adecuada. P2-C5 Debe hacerse un seguimiento de los tiempos empleados tanto por tarea como a

lo largo del proyecto. P2-C6 Se debe controlar que se siguen las etapas del ciclo de vida adoptado para el

proyecto y que se generan todos los documentos asociados a la metodología usada.

P2-C7 Cuando termina el proyecto se debe cerrar toda la documentación del mismo, liberar los recursos empleados y hacer balance.



Auditoría de la fase de estudio de viabilidad. El objetivo del estudio de viabilidad del sistema es el análisis de un conjunto concreto de necesidades para proponer una solución a corto plazo, que tenga en cuenta restricciones económicas, técnicas, legales y operativas. Objetivo de Control V1: Antes de la definición del proyecto deben estudiarse los requisitos que se han de satisfacer y estudiarse, si procede, la situación actual, identificando seguidamente las alternativas de solución y seleccionando aquella que satisfaga más eficaz y eficientemente los requisitos identificados, lo cual puede derivar en la definición de uno o varios proyectos que afecten a uno o varios SI y con soluciones basadas en desarrollo a medida, adquisición de productos software del mercado o soluciones mixtas. V1-C1 Debe haberse establecido el alcance de las iniciativas requeridas para satisfacer

las necesidades planteadas por el cliente o usuario. V1-C2 Debe estudiarse la situación actual y determinarse los sistemas afectados V1-C3 Los usuarios y responsables de las unidades a las que afecta el nuevo sistema

establecerán de forma clara los requisitos del mismo. V1-C4 Se deben estudiar y valorar las distintas alternativas de solución que satisfacen

los requisitos identificados anteriormente y analizar sus ventajas e inconvenientes.

V1-C5 Debe de seleccionarse la solución que satisfaga más eficaz y eficientemente los requisitos identificados.

Auditoría de la fase de análisis. El objetivo de esta fase o proceso es la obtención de una especificación detallada del sistema de información que satisfaga las necesidades de información de los usuarios y sirva de base para el posterior diseño del sistema y de una forma independiente del entorno técnico. Objetivo de Control A1: Se debe elaborar una especificación detallada que permita describir con precisión el sistema de información. A1-C1 Debe realizarse un plan detallado de sesiones de trabajo con el grupo de

usuarios del proyecto y los responsables de las unidades afectadas para recopilar la información necesaria.

A1-C2 A partir de la información obtenida de las entrevistas se debe realizar la descripción inicial del SI y obtener el catálogo de requisitos detallado del mismo.

A1-C3 Se estructura el sistema de información en subsistemas de análisis, para facilitar la especificación de los distintos modelos y la traza de requisitos.

A1-C4 Se debe realizar el modelo del sistema que sirva de base para el diseño. En el caso de análisis estructurado, mediante la elaboración y descripción detallada del modelo de datos y de procesos, y en el caso de un análisis orientado a objetos, a través del modelo de clases y el de interacción de objetos, mediante el análisis de los casos de uso.

A1-C5 Se deben de especificar todas las interfaces entre el sistema y el usuario, tales como formatos de pantallas, diálogos, formatos de informes y formularios de entrada.



Objetivo de Control A2: Se debe garantizar la calidad de los distintos modelos generados en el proceso de análisis del SI, y asegurar que los usuarios y los analistas tienen el mismo concepto del sistema. A1-C1 Se debe de verificar la calidad técnica de cada modelo y asegurar la coherencia

entre los distintos modelos. A1-C2 Debe realizarse una validación formal de la especificación de requisitos y de los

modelos del análisis del sistema. Auditoría de la fase de diseño. El objetivo del proceso o fase de diseño del SI es la definición de la arquitectura del sistema y del entorno tecnológico que le va a dar soporte, junto con la especificación detallada de los componentes del sistema de información. Objetivo de Control 01: se debe definir una arquitectura del sistema que sea coherente con la especificación funcional que se tenga y con el entorno tecnológico. D1-C1 El particionamiento físico del sistema de información, así como su organización

en subsistemas de diseño, la especificación del entorno tecnológico, y sus requisitos de operación, administración, seguridad y control de acceso deben estar definidos de forma clara y ser conformes a los estándares y normas del departamento de informática.

D1-C2 Se debe realizar un diseño detallado de los subsistemas de soporte y del sistema de información específico.

D1-C3 Se debe diseñar la estructura de datos adaptando las especificaciones del sistema al entorno tecnológico.

D1-C4 Debe realizarse una verificación y aceptación formal de la arquitectura del sistema.

Objetivo de Control 02: Se deben de generar todas las especificaciones necesarias para la construcción del sistema de información D2-C1 Se deben de generar unas especificaciones de construcción. D2-C2 Se debe especificar el procedimiento de migración y carga inicial de datos así

como los requisitos de operación. D2-C3 Debe realizarse la especificación técnica del plan de pruebas. D2-C4 Se debe realizar una aprobación formal del diseño del sistema por el comité de

dirección. Auditoría de la fase de construcción. En esta fase se construirán los productos software que satisfagan las necesidades identificadas y cumplan con los requisitos especificados. Asimismo, se pondrán en marcha todos los procedimientos necesarios para que los usuarios puedan trabajar con el nuevo sistema. Objetivo de Control CA-1: Los componentes que se desarrollen deben desarrollarse usando técnicas de programación correctas. CA1-C1 Se debe preparar adecuadamente el entorno de desarrollo y de pruebas, así

como los procedimientos de operación y seguridad. CA1-C2 Se debe programar, probar y documentar cada uno de los componentes

identificados en el diseño del sistema. CA1-C3 Deben realizarse las pruebas de integración para verificar si los componentes o

subsistemas interactúan correctamente a través de sus interfaces, tanto internas como externas, cubren la funcionalidad establecida, y se ajustan a los



requisitos especificados en las verificaciones correspondientes.

CA1-C4 Deben realizarse las pruebas de sistema para comprobar la integración del

sistema de información globalmente. Objetivo de Control CA-2: Los proyectos de desarrollo deben definir los procedimientos y formación necesarios para que los usuarios puedan utilizar el nuevo sistema adecuadamente. CA2-C1 El desarrollo de los componentes de usuarios debe estar planificado. CA2-C2 Se deben especificar los perfiles de usuario requeridos para el nuevo sistema. CA2-C3 Se deben desarrollar todos los procedimientos de usuario con arreglo a los

estándares del área. CA2-C4 A partir de los perfiles actuales de los usuarios, se deben definir los procesos de

formación o selección de personal necesarios. CA2-C5 Se deben definir los recursos materiales necesarios para el trabajo de los

usuarios con el nuevo sistema. Auditoría de la fase de implantación y aceptación. Esta fase o proceso tiene como objetivo principal la entrega y aceptación del sistema en su totalidad, y la realización de todas las actividades necesarias para el paso a producción del mismo. Objetivo de Control IA-1: El sistema debe ser aceptado formalmente por los usuarios antes de ser puesto en explotación. IA1-C1 El plan de implantación y aceptación se debe revisar para adaptarlo a la

situación final del proyecto. IA1-C2 Se deben realizar las pruebas de implantación y aceptación del sistema que se

especificaron en fases anteriores. IA1-C3 Se debe determinar los servicios, y niveles para cada uno, que requiere el

sistema que se va a implantar, y el acuerdo que se adquiere una vez que se inicie la producción.

IA1-C4 El sistema debe ser aprobado formalmente antes de ponerse en explotación. Objetivo de Control IA-2: El sistema se pondrá en explotación formalmente y pasará a estar en mantenimiento sólo cuando haya sido aceptado y esté preparado todo el entorno el que se ejecutará. IA2-C1 Se deben instalar todos los procedimientos de explotación. IA2-C2 Si existe un sistema antiguo, el sistema nuevo se pondrá en explotación de

forma coordina con la retirada del antiguo, migrando los datos si es necesario. IA2-C3 Se debe supervisar el trabajo de los usuarios con el nuevo sistema en las

primeras semanas para evitar situaciones de abandono de uso del sistema. IA2-C4 Para terminar el proyecto se pondrá en marcha el mecanismo de

mantenimiento.



Auditoría de la fase de mantenimiento. El objetivo de esta fase es la obtención de una nueva versión de un sistema de información desarrollado a partir de las peticiones de mantenimiento que los usuarios realizan con motivo de un problema detectado en el sistema, o por la necesidad de una mejora del mismo. Objetivo de Control M-1: La gestión del proceso de mantenimiento de sistemas de información debe ser eficiente y eficaz para conseguir mantener el coste del mantenimiento de los SI del área bajo control. M1-C1 Debe de existir una estrategia y un plan para la gestión del mantenimiento de

los SI del área y de sus infraestructuras tecnológicas. M1-C2 Se deben revisar periódicamente los contratos y acuerdos de nivel de servicio y

monitorizar su grado de cumplimiento Objetivo de Control M-2: Todos los cambios, ya sean incidentes, problemas o peticiones de mantenimiento, intuido el mantenimiento correctivo de emergencia o cambios relacionados con la infraestructura tecnológica del entorno de producción, deben de ser gestionados formalmente y de una manera controlada a fin de asegurar la mitigación del riesgo debido a los impactos negativos en la estabilidad e integridad del SI en producción. M2-C1 Se debe establecer un sistema estandarizado de registro de información para las

peticiones de mantenimiento, con el fin de controlar y canalizar los cambios propuestos por un usuario o cliente, mejorando el flujo de trabajo de la organización y proporcionando una gestión efectiva del mantenimiento.

M2-C2 Se debe llevar a cabo un diagnóstico y análisis del cambio para dar respuesta a las peticiones de mantenimiento que son aceptadas.

M2-C3 Se debe de identificar de forma detallada cada uno de los elementos afectados por el cambio mediante el análisis de impacto.

M2-C4 Se realiza el seguimiento de los cambios que se están llevando a cabo en los procesos de desarrollo, de acuerdo a los puntos de control del ciclo de vida del cambio establecidos previamente.

2. Evaluación de procesos y gestión de riesgos. Los responsables y los usuarios de la tecnología de la información son conscientes de la necesidad de disponer de instrumentos tales como metodologías que ayuden a la investigación del estado de seguridad de los sistemas de información (SI) y a la selección de medidas de seguridad proporcionadas, tanto para paliar las insuficiencias de los sistemas existentes, como para aquellos otros que precisen de reforma o de nuevo desarrollo. La seguridad de los sistemas ha pasado en poco tiempo de ser una faceta más a controlar, a ser una faceta crítica que debemos controlar o esos sistemas, que son estratégicos para nuestro trabajo, se pueden convertir en una pesadilla. Pero no es posible una aplicación racional de medidas de seguridad sin antes analizar los riesgos para así implantar las medidas proporcionadas. Para responder a esta necesidad, el Consejo Superior de Administración Electrónica ha elaborado la Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información, Magerit versión 2, un método para investigar los riesgos que soportan los Sistemas de Información, y para recomendar las medidas apropiadas que deberían adoptarse para controlar estos riesgos. (Ver tema MAGERIT) La razón de ser de Magerit está directamente relacionada con la generalización del uso de los medios electrónicos, informáticos y telemáticos, que supone unos beneficios evidentes para



los ciudadanos, las empresas y la propia Administración Pública, pero que también da lugar a ciertos riesgos que deben minimizarse con medidas de seguridad que generen confianza en su utilización. Existen diversas definiciones del concepto seguridad, en Magerit se define a la seguridad como la capacidad de las redes o de los sistemas de información para resistir, con un determinado nivel de confianza, los accidentes o acciones ilícitas o malintencionadas que comprometan la disponibilidad, autenticidad, integridad y confidencialidad de los datos almacenados o transmitidos y de los servicios que dichas redes y sistemas ofrecen o hacen accesibles. Las dimensiones de la seguridad: ACID El análisis de riesgos es una piedra angular de los procesos de evaluación, certificación, auditoría y acreditación que formalizan la confianza que merece un sistema de información. En análisis de riesgos proporciona una visión singular de cómo es cada sistema, qué valor posee, a qué amenazas está expuesto y de qué salvaguardas se ha dotado. Es pues el análisis de riesgo paso obligado para poder llevar a cabo todas las tareas mencionadas. Las evaluaciones permiten medir el grado de confianza que merece o inspira un sistema de información. La evaluación puede llevar a una certificación o registro de la seguridad del sistema. En la práctica se certifican productos Y se certifican sistemas de gestión de la seguridad. Para la certificación de productos, la norma internacional ISO/lEC 15408:2005, conocida como los Criterios Comunes, es la norma internacional más extendida para este propósito. De hecho, la administración española, y otras muchas, reconocen las certificaciones de seguridad emitidas en otros países en base al "Arreglo sobre el Reconocimiento de los Certificados de Criterios Comunes en el Campo de la Tecnología de la Información". Para la certificación de sistemas de gestión de la seguridad de sistemas de información (SGSI), la norma internacional ISO/IEC 27001 es el referente, está basada en el modelo POCA (Plan-DoCheck-Act) y su utilización está ligada a los controles y objetivos de control de la norma ISO/IEC 17799:2005. Sin embargo esta norma internacional aún no ha sido adaptada al ámbito nacional, con lo Estas características de seguridad se requieren según el valor que para la Organización tenga el SI. Si por ejemplo el secreto de la información es muy importante, sólo confiaremos en un sistema que nos asegure un alto nivel de confidencialidad. Con lo que cada una de estas características serán requeridas o no dependiendo de cada caso. Cuando se requieran lo habitual es que haya que poner medios y esfuerzos para conseguirlos. A racionalizar este esfuerzo se dedican las metodologías de análisis y gestión de riesgos que comienzan con una definición:

Riesgo: estimación del grado de exposición a que una amenaza se materialice sobre uno o más activos causando daños o perjuicios a la Organización. El riesgo indica lo que le podría pasar a los activos si no se protegieran adecuadamente. Es importante saber qué características son de interés en cada activo, así como saber en qué medida estas características están en peligro, es decir, analizar el sistema:

Análisis de riesgos: proceso sistemático para estimar la magnitud de los riesgos a que está expuesta una Organización. sabiendo lo que podría pasar, hay que tomar decisiones:

Gestión de riesgos: selección e implantación de salvaguardas para conocer, prevenir, impedir, reducir o controlar los riesgos identificados.

Un riesgo técnico se podrá afrontar: evitándolo, reduciéndolo, transfiriéndolo o aceptándolo.



El problema del análisis de riesgos estriba en la complejidad de los sistemas a analizar y la incertidumbre de los datos de que disponemos. Para afrontar la complejidad disponemos de una metodología como Magerit que permite trabajar ordenadamente e instrumentarla con una herramienta como PILAR. Un tratamiento metodológico riguroso aporta sustanciales ventajas:

Se cubren muchos de los incidentes posibles, olvidando los menos posibles y en todo caso no olvidando los típicos, frecuentes, recurrentes o que ya hayan ocurrido en circunstancias similares.

Permite explicar con fundamento lo que pedimos a la dirección que decida, lo que pedimos a los técnicos que hagan y cómo le pedimos a los usuarios que actúen frente al sistema.

Proporciona información rigurosa para que la dirección tome decisiones. El resultado del análisis de riesgos son unos indicadores de impacto y riesgo que se utilizarán para tomar decisiones y monitorizar la evolución de la seguridad del sistema. El objetivo de Magerit es servir de guía para la Administración Pública Española de forma que los sistemas administrativos puedan ser objeto de un análisis de riesgos riguroso que permita gestionar los riesgos prudentemente. Magerit persigue varios objetivos:

a) Concienciar a los responsables de los SI de la existencia de riesgos y de la necesidad de atajarlos a tiempo.

b) Ofrecer un método sistemático para analizar tales riesgos.

c) Ayudar a descubrir y planificar las medidas oportunas para mantener los riesgos bajo

control.

d) Preparar a la Organización para procesos de evaluación, auditoría, certíñcación o acreditación, según corresponda en cada caso.

Tipos de informes de un proyecto de análisis y gestión de riesgos:

Modelo de valor. Caracterización del valor que representan los activos para la Organización así como de las dependencias entre los diferentes activos.

Mapa de riesgos. Relación de las amenazas a que están expuestos los activos. Evaluación de salvaguardas. Evaluación de la eficacia de las salvaguardas existentes en

relación al riesgo que afrontan. Estado de riesgo. Caracterización de los activos por su riesgo residual; es decir, por lo que

puede pasar tomando en consideración las salvaguardas desplegadas. Informe de insuficiencias. Ausencia o debilidad de las salvaguardas que aparecen como

oportunas para reducir los riesgos sobre el sistema. Plan de seguridad. Conjunto de programas de seguridad que permiten materializar las

decisiones de gestión de riesgos En cuanto a la herramienta PILAR: PILAR (acrónimo de "Procedimiento Informático-Lógico para el Análisis de Riesgos" y nombre que se utiliza dentro de la Administración Pública Española, siendo EAR su nombre comercial e internacional) es una herramienta subvencionada por el Centro Criptológico Nacional para apoyar a los responsables de seguridad analizando riesgos y cómo un plan de seguridad ayuda a mantenerlos bajo control. Una herramienta de análisis y gestión de riesgos:

Proporciona una forma sistemática de capturar la información y presentarla. Proporciona una forma sistemática de analizar los datos y derivar los indicadores

sin verse perjudicada por el volumen.



PILAR / EAR soporta todas las fases del método Magerit:

caracterización de los activos: identificación, clasificación, dependencias y valoración

caracterización de las amenazas Evaluación de las salvaguardas

La herramienta fija un catálogo homogéneo o biblioteca para centrar:

Clases o tipos de activos. Criterios (codificados) para valorar cualitativamente los activos. Amenazas estándar. Una larga lista de salvaguardas caracterizadas por el tipo de activo que

protegen, de qué amenaza le protegen y en qué dimensión (garantías de confidencialidad, de integridad, ... ).

Un catálogo es conveniente para que los análisis de riesgos se puedan compartir y sea, de alguna manera, homologable. Pero además esta biblioteca se puede extender, adaptándola a escenarios y situación concretas. Se pueden establecer:

Perfiles típicos de amenazas (frecuencia tasada de ocurrencia y degradación típica). Perfiles específicos de seguridad (tales como criterios de acreditación sectoriales,

reglamentos de protección de datos personales, que varían de país en país, etc.). Protecciones específicas de ciertos tipos de activos (orientado a proporcionar guías

de securización para operadores, por ejemplo, lo que se debe hacer para tener correo electrónico seguro o una red wifi, etc.),

La herramienta evalúa el impacto y el riesgo, acumulado y repercutido, potencial y residual, presentándolo de forma que permita el análisis de por qué se da cierto impacto o cierto riesgo. Las salvaguardas se califican por fases, permitiendo la incorporación a un mismo modelo de diferentes situaciones temporales. Típicamente se puede incorporar el resultado de los diferentes programas de seguridad a lo largo de la ejecución del plan de seguridad, monitorizando la mejora del sistema. Los resultados se presentan en varios formatos: informes RlF, gráficas y tablas para incorporar a hojas de cálculo. De esta forma es posible elaborar diferentes tipos de informes y presentaciones de los resultados.



BIBLIOGRAFÍA

METRICA v3

COBIT. Controles.

ISO/IEC 27001 Information technology -- Security techniques -- Information security management systems - requirements.

ISO/IEC 17799 Information technology - Security techniques - Code of practice for information security management.

J. A. Mañas (2007). Gestión de Riesgos de Seguridad. Gobierno de las Tecnologías y los Sistemas de Información. M. Piattini y F. Hervada. Editorial RA-MA: pp: 139-159.

F. López, M. A. Amutio, J. candau y J. A. Mañas (2005). MAGERIT - Versión 2. Metodología de Análisis y Gestión de Riesgos de Sistemas de Información -. Madrid, Ministerio de Administraciones Públicas.

Auditoría informatica I. Concepto

Documents

Transcript of Auditoría informatica I. Concepto