Auditoria de Tecnología Basada en Riesgos 160813 [ESTUDIANTES]x

AUDITORÍA DE TECNOLOGÍA BASADA EN RIESGOS Agosto, 2013

Copyright © 2013 Ing. Raúl González Carrión All rights reserved.

Auditoría de Tecnología Basada en Riesgos CONTENIDO Inicio: Conceptos básicos 1. Fundamentos de la gestión de riesgos corporativos 1.1. Antecedentes: Metodologías de Control Interno 1.2. Marcos metodológicos de gestión de riesgos 1.3. Definición, objetivos y componentes de la gestión de riesgos 1.4. Riesgo y Control

2. Gestión de riesgos de TI 2.1. Algunos conceptos de Riesgos Tecnológicos 2.2. Principales marcos para la Administración de Riesgos de TI 2.3. Riesgo Operativo 2.4. The Risk intelligence Map 2.5. Revisión marco COBIT 4.1

1

Auditoría de Tecnología Basada en Riesgos CONTENIDO 2.6. Metodología para realizar un análisis de riesgos de Confidencialidad, Integridad y Disponibilidad 2.7. Continuidad del Negocio como parte de la evaluación de riesgos 2.8. Norma PCI 2.9. Introducción a ISO ISO/IEC 38500:2008

3. Estándar internacional de auditoría 3.1. Norma ISA 315 – Identificación y evaluación del riesgo de error material a través del conocimiento y la compresión de la entidad y de su entorno 3.2. Controles Generales Relacionados con la Tecnología 3.3. Controles de Aplicación 3.4. Riesgos & Controles en Procesos de Negocios

2

Auditoría de Tecnología Basada en Riesgos CONTENIDO 4. Metodología Auditoría de Tecnologías basada en riesgos

3

Conceptos básicos • Auditoría: Es un examen objetivo, sistemático y profesional practicado con posterioridad a la ejecución de las operaciones o transacciones con el objeto de emitir un informe o diagnóstico que derive comentarios, conclusiones y recomendaciones.

• Auditoría de Tecnología: Proceso de recolección y evaluación de evidencia para determinar si los SI y los recursos relacionados: • Salvaguardan adecuadamente los activos, • Mantienen la integridad de los datos y del sistema, • Proveen información relevante y confiable, • Alcanzan efectivamente los objetivos organizacionales, • Utilizan los recursos eficientemente, y • Cuentan con controles internos que provean una seguridad razonable de que los objetivos operacionales y de control serán satisfechos y de que los eventos no deseados serán prevenidos o detectados y corregidos de manera oportuna. Fuente: ISACA.ORG 4

Conceptos básicos • Riesgo: • • • • • • • •

Es “el efecto de la incertidumbre en la consecución de los objetivos” [ISO 31000:2009] Combinación de la probabilidad (posibilidad) de un evento y su consecuencia (Risk Management: Vocabulary Guide 73 ISO) La posibilidad que algo suceda y que tenga impacto en el logro de los objetivos (Australian/New Zealand Standard - 1999) Posibilidad de que suceda algo que tendrá impacto en los objetivos. Se mide en términos de consecuencias y posibilidad de ocurrencia. (NTC 5254 Gestión del Riesgo) Combinación de la probabilidad y la(s) consecuencia(s) que ocurra un evento peligroso específico.( NTC OHSAS 18001 ) Riesgo es la posibilidad que algún evento ocurra y afecte adversamente el logro de los objetivos (COSO ERM - 2004) Posibilidad de que ocurra un evento o acto que podría tener un efecto adverso en la organización y sus sistemas de información [ISACA] Riesgo Probabilidad de que un evento o acción pueda afectar adversamente la organización o actividad auditada [IIA]

Riesgo Es la exposición potencial a situaciones que pueden afectar el logro de los objetivos de una organización, generar pérdidas o mermar potenciales utilidades.[Deloitte]

5

FUNDAMENTOS DE LA GESTIÓN DE RIESGOS CORPORATIVOS 1.1. Antecedentes: Metodologías de Control Interno

6

La actualidad • La incertidumbre implica riesgos y oportunidades. • La administración de riesgos corporativos permite a la

dirección tratar efectivamente a la incertidumbre y sus riesgos y oportunidades asociadas, mejorando así la capacidad de generar valor.

7

Contexto • En el contexto actual existen dos tendencias

sumamente acentuadas: • Globalización • Tecnología

• Si bien ambas tendencias favorecen el crecimiento

económico y las inversiones, también implican mayores riesgos, principalmente por la acción de las diferentes variables que interactúan.

8

1.1.1. Control Interno: Evaluación y Evolución • ¿Qué es el control interno?:

Es un proceso realizado por la Junta Directiva, Administradores y demás personal de la entidad, diseñado para proporcionar seguridad razonable mirando el cumplimiento de los objetivos de la organización en estas Promover la efectividad y eficiencia en las operaciones categorías: (incluyendo la salvaguarda de activos).

Soportar el cumplimiento con las leyes y regulaciones aplicables

Asegurar la razonabilidad de los reportes financieros

9

Evolución reciente del control interno

COSO 2013

10

1.1.2. Control interno efectivo: Referentes internacionales COSO I

IIA

COSO II (ERM)

SOX

Basilea

Cobit

11

1.1.3. Generación del Control Interno • Un esquema comprensivo que nos genera: –

Una definición común de “Controles internos”

–

Discusión de responsabilidades

–

Estándares para evaluar el sistema de control interno

–

Un modelo general de control interno

* Internal Control – Integrated Framework, Committee of Sponsoring Organizations (COSO) of the Treadway Commission

12

1.1.3. Generación del Control Interno • El control interno ayuda a una entidad a llegar a donde quiere llegar, evitar

trampas y sorpresas que pueden ocurrir en el transcurso.

Proceso continuo. Es un medio no un fin en sí mismo.

Proporciona seguridad razonable. Ejecutado por personas. No son solo políticas y manuales.

13

Control Interno • El control interno no es un evento o una circunstancia, es Proceso

una serie de acciones. • Constituye un medio para un fin, es administrado mediante la planeación, ejecución y monitoreo. • Está entrelazado con las actividades de operación de una entidad y ES PARTE DE LA ESENCIA DE UNA COMPAÑÍA.

• Es Personal

ejecutado por la Junta Directiva, Administradores, y demás personal de la entidad. • La gente debe conocer sus responsabilidades y sus límites de autoridad.

14

Control Interno Seguridad Razonable

Existen limitaciones inherentes a todos los sistemas de control interno (juicios humanos en toma de decisiones, fallas humanas-errores y equivocaciones, colusión de dos o más personas, entre otros).

Objetivos

Misión, objetivos y estrategias de la Compañía para alcanzarlos

15

1.1.4. Responsabilidades frente al sistema de control interno Riesgos Sistema de Control Interno Organización

Presidencia Vicepresidencias Gerencias Áreas de Soporte Dueños de Proceso Todo el personal de la organización

Asamblea de Accionistas

Junta Directiva

Comité de Auditoría

Auditoría Interna

Revisoría Fiscal

Responsables del sistema de control interno

16

Responsabilidad de monitorear el sistema de control interno 16

Control Interno Resumiendo:

Es un proceso que hace parte de los demás sistemas y procesos de la empresa

Proporciona una seguridad razonable, más que absoluta, de que se lograrán los objetivos definidos.

Es concebido y ejecutado por personas de todos los niveles de la organización a través de sus acciones y palabras.

Orientado a objetivos es un medio, no un fin en sí mismo. 17

1.1.5. Evaluación del Control Interno: Método COSO • Commitee of Sponsoring Organizations of the Treadway Commission en 1992

estableció el COSO I (The Internal Control Integrated Framework) • Asociación Contable Estadounidense • Instituto Estadounidense de CPA • Instituto de Ejecutivos Financieros • Instituto de Auditores Internos • Instituto de Contadores Gerenciales

COSO •C comitte (comité) •O of (de) •S sponsorig (auspiciantes) •O organizations (organizaciones) 18

1.1.6. COSO I– Referente para otras metodologías de Implementación y evaluación de CI. Otros organismos profesionales de los países industrializados han definido su enfoque sobre el control interno, basados en los criterios definidos en el Informe COSO, como los siguientes: • Criteria of Control (COCO), del Instituto Canadiense de Contadores Certificados

(CICA de las siglas del inglés); • Cadbury del Instituto de Contadores del Reino Unido; • King del Instituto de Contadores de Australia; • Vienot de Francia; Entre los más difundidos. Adicionalmente existen regionalmente estos documentos: • MICIL – Marco Integrado de Control Interno para Latinoamérica (síntesis y adaptación de COSO I). • CORRE – Control de los Recursos y los Riesgos en Ecuador (síntesis de: COSO I, COSO II (ERM), MICIL). 19

1.1.7. COSO I – Definición de Control Interno • El control interno se define como un proceso, efectuado por el

consejo de administración, la dirección y el resto de personal de una entidad (todos), 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: • El control interno consta de cinco componentes interrelacionados,

que se derivan de como la administración maneja el ente, y están integrados a los procesos administrativos. • El control interno, no consiste en un proceso secuencia. Es un

proceso multidireccional repetitivo y permanente. • El control interno difiere por ente y tamaño y por sus culturas y

filosofías de administración. 20

1.1.8. COSO I – Marco Integrado de Control (Framework)

Actividades de Control

Actividad 1

Proceso 1

Información & Comunicación

Unidad B

Monitoreo

Unidad A

Cinco Componentes

Tres categorías de objetivos

Evaluación de Riesgos

Ambiente de Control

NIVELES DE LA ORGANIZACIÓN Unidades-Actividades-Procesos

21

COSO I: Ambiente de Control


Actividad 1

Proceso 1


Unidad B

Integridad y Valores Éticos. Estructura Organizativa Autoridad Asignada y Responsabilidad Asumida. Administración de los Recursos Humanos. Competencia Profesional y Evaluación del Desempeño Individual. Filosofía y Estilo de la Dirección. Consejo de Administración y Comités. Rendición de Cuentas y Transparencia.

Monitoreo

Unidad A

El Ambiente de Control da el tono de una organización influenciando la conciencia de control de sus empleados, proporcionando disciplina y estructura. Es el fundamento de los demás componentes del control interno.


Ambiente de Control

22

COSO I: Evaluación de Riesgos


Actividad 1

Proceso 1


Unidad B

Monitoreo

Unidad A

La Valoración de Riesgos es la identificación y el análisis de los riesgos relevantes que puedan afectar la consecución de los objetivos. Los continuos cambios de la economía, la industria, las regulaciones y las condiciones de operación, requieren mecanismos para identificar, tratar y administrar los riesgos asociados al negocio.


Ambiente de Control

23

COSO I: Actividades de Control


Actividad 1

Proceso 1


Unidad B

Monitoreo

Unidad A

Las Actividades de Control ayudan a asegurar que se están llevando a cabo las directrices administrativas y tomando las acciones necesarias para manejar los riesgos hacia la consecución de los objetivos de la Entidad. Las actividades de control se dan a todo lo largo y ancho de la Entidad, en todos los niveles y en todas la funciones.


Ambiente de Control

24

COSO I: Información & Comunicación


Actividad 1

Proceso 1


Unidad B

Monitoreo

Unidad A

Los sistemas de Información producen reportes, contienen información operacional, financiera y relacionada con el cumplimiento, que hace posible operar y controlar el negocio, adicionalmente soportar la toma de decisiones. La Comunicación efectiva debe fluir en un sentido amplio, hacia abajo, a lo largo y hacia arriba de la organización, igualmente con las partes externas como clientes, proveedores, reguladores y accionistas, entre otros.


Ambiente de Control

25

COSO I: Monitoreo


Actividad 1

Proceso 1


Unidad B

Monitoreo

Unidad A

El Monitoreo ongoing (ocurre en el curso de las operaciones), las evaluaciones separadas (supervisión o ejecución de trabajos de Auditoría) o combinaciones de ambas, deben efectuarse sobre el sistema de control interno, puesto que el monitoreo es un proceso que valora la calidad del desempeño del sistema de control interno en el tiempo.


Ambiente de Control

26

COSO I

27

COSO – Una frase para recordar

Un buen control interno NO garantiza el éxito ... PERO ... Un mal control interno SI garantiza el fracaso.

28

FUNDAMENTOS DE LA GESTIÓN DE RIESGOS CORPORATIVOS 1.2. Marcos metodológicos de gestión de riesgos

29 29

1.2.1. Marcos metodológicos de Gestión de Riesgos A continuación se lista los principales marcos metodológicos sobre gestión de riesgos: Gestión de riesgos corporativos. • • • • • • •

Estándar AS NZS 4360:1999 de Gestión de Riesgos (Australiano Neozelandés – 1999) Estándar AS NZS 4360:2004 de Gestión de Riesgos (Australiano Neozelandés – 2004) COSO – ERM /Enterprise Risk Management (2004) Basilea II – Gestión de Riesgos en Entidades Financieras (2004) ISO 31000:2009 Gestión de Riesgos – Principios y Directrices (2009) ISO 73:2009, el vocabulario de gestión de riesgos ISO/IEC 31010:2009 Risk management -- Risk assessment techniques

Gestión de riesgos de Tecnología de la Información TI. • • • • • • •

COBIT – Control Objectives for Information and related Technology (ISACA) IT Risk (ISACA) ISO 27005 Gestión del Riesgo en la Seguridad de la Información MAGERIT - Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información (Gobierno de España) OCTAVE - Operational Critical Threat, Asset and Vulnerability Evaluation - Evaluación de Amenazas y Vulnerabilidades de Recursos Críticos Operacionales (Carnegie Mellon University) NIST – National Institute of Standards and Technology; Risk Management Guide for Information Technology Systems.

30

1.2.2. COSO II - ERM A raíz de los grandes problemas en varias organizaciones empresariales se establecieron nuevas metodologías para lograr mayor compromiso de parte de toda la organización desde su junta directiva, administración y demás personal. [Gobierno Corporativo] Se cambiaron las reglas de planeación y evaluaciones de controles internos por la necesidad primaria de lograr una administración de riesgos habiéndose completado el COSO I por el ahora llamado COSO II (ERM) El COSO II (ERM), es reconocido como el estándar para cumplir con la sección 404 de la ley Sarbanes-Oxley. Sección 404: Exige al CEO y CFO, anualmente, declarar su responsabilidad de establecer, mantener y evaluar la estructura de control interno (modelo tipo COSO) y procedimientos de reporte financiero. Exige al Auditor Externo probar la validez de la declaración de la Gerencia.

31

1.2.2.1 COSO II – ERM : Fecha de publicación • En septiembre de 2004 se publicó la versión en inglés del COSO – ERM (Enterprise

Risk Management – Integrated Framework. • La traducción al español del COSO – ERM fue realizada por la firma auditora

PricewaterhouseCoopers PWC y la Federación Latinoamericana de Auditores Internos FLAI, y fue publicada en diciembre de 2005

32

1.2.2.2 COSO II – ERM : Antecedentes ¿CÓMO SE INICIÓ ERM? ERM comenzó en las empresas de servicios financieros, seguros, servicios públicos, petróleo, gas, e industrias manufactureras químicas ¿Por qué ahí? • En estas industrias los riesgos están bien documentados y medidos. • Comúnmente se utilizan sofisticados modelos estadísticos. • Existe entendimiento y supervisión sobre la sensibilidad del mercado y riesgos

33

FUNDAMENTOS DE LA GESTIÓN DE RIESGOS CORPORATIVOS 1.3. Definición, objetivos y componentes de la gestión de riesgos

34 34

1.3.1. COSO ERM – Definición • “La Gestión de Riesgos Corporativos es un proceso efectuado por la Junta

Directiva, administración y demás personal, aplicable a la definición de estrategias en toda la empresa y diseñado para identificar eventos potenciales que puedan afectar a la organización, administrar sus riesgos dentro del riesgo aceptado y proporcionar una seguridad razonable sobre el logro de los objetivos. “ 1. 2. 3. 4.

ESTRATEGICO (esta categoría no incluía COSO I). Eficiencia y efectividad de las Operaciones (OPERACIONES). Confiabilidad de la Información (REPORTES). Cumplimiento (CUMPLIMIENTO).

35

1.3.2. COSO ERM – Conceptos Fundamentales Conceptos fundamentales:

Un proceso, es un medio para un fin, no un fin en si mismo.

Efectuado por gente – no es solamente política, estudio y forma, sino que involucra gente en cada nivel de una organización.

Aplicado en la definición de la estrategia

Aplicado a través de la administración en cada nivel y unidad (incluye asumir el punto de vista de portafolio de los riesgos a nivel de la entidad)

Diseñado para identificar los eventos que potencialmente afectan la entidad y para administrar los riesgos dentro del apetito por los riesgos.

Provee seguridad razonable para la administración y para la junta de una entidad

Orientado al logro de los objetivos en una o más categorías separadas pero al mismo tiempo se sobreponen unas con otras. 36

1.3.3. COSO ERM – Componentes El COSO - ERM está integrado por ocho componentes: 1. Ambiente Interno. 2. Establecimiento de Objetivos. 3. Identificación de Eventos. 4. Evaluación de Riesgos. 5. Respuesta al Riesgo. 6. Actividades de Control. 7. Información y Comunicación. 8. Supervisión (Monitoreo).

37

1.3.4. COSO I vs COSO II (ERM) COSO (Internal Control ) Framework

Vs

COSO ERM (Enterprise Risk Management) Framework


Actividad 1

Proceso 1

Unidad B


Unidad A

Monitoreo


Ambiente de Control

Se pasó de tener 5 a tener 8 componentes 38

1.3.4. COSO I vs COSO II (ERM) Control Interno COSO Control interno es un proceso ejecutado por el consejo directo, la administración y otro personal de una entidad, designado para proporcionada seguridad razonable referente al logro de objetivos en las categorías:

2. 3.

Efectividad y eficacia de operaciones Confiabilidad en reportes financieros Cumplimiento con las leyes y reglamentos aplicables Monitoreo Información & Comunicación Actividades de Control

La administración de riesgos empresariales un proceso, ejecutado por el consejo directivo, la administración y otro personal de una entidad, aplicado en el establecimiento de estrategias en toda la empresa, designado para identificar eventos potenciales que pudieran afectar a la entidad, y administrar los riesgos para mantenerlos dentro de su apetito de riesgo, proporcionar seguridad razonable referente al logro de objetivos.

Unidad A Unidad B Proceso 1 Actividad 1

1.

Administración de Riesgos Empresariales ERM


Ambiente de Control

39

1.3.5. COSO II – ERM : Componentes Estableciendo el Tono de la organización, para influenciar la conciencia de control de su gente Factores que afectan el ambiente interno:

AMBIENTE INTERNO

Asignación de autoridad y responsabilidad

Integridad y valores éticos

Estructura Organizacional

Junta Directiva – Comité de Auditoría

Políticas y prácticas de recurso humano

Estilo y filosofía de la administración

Compromiso hacia la competencia (habilidades y conocimientos)

40

1.3.5. COSO II – ERM : Componentes Principales consideraciones con relación a TI: AMBIENTE INTERNO

• TI se ve como una organización separada y por ende tiene un ambiente de control diferente • La complejidad de TI también afecta el control interno – Mayor énfasis • La Tecnología puede introducir nuevos riesgos o aumentar algunos lo cual puede requerir nuevas actividades de control • Se requiere conocimiento especializado. • Confianza en proveedores críticos • La propiedad de los Controles de TI puede no ser clara

41

1.3.5. COSO II – ERM : Componentes Corresponde a un proceso para definir objetivos y que estos apoyen y estén de acuerdo con la misión de la entidad y sean consistentes con su interés por los riesgos. FORMULACION DE OBJETIVOS

•Objetivos estratégicos •Objetivos relacionados •Objetivos seleccionados •Riesgo aceptado •Tolerancia al riesgo El establecimiento de objetivos es un requisito previo para el control interno Efectivo.

42

1.3.5. COSO II – ERM : Componentes Eventos con impacto negativo tanto internos como externos que afectan el logro de los objetivos, distinguiendo entre riesgos y oportunidades:

•Factores de influencia estrategia y objetivos IDENTIFICACION DE EVENTOS

•Metodologías y técnicas •Acontecimientos independientes •Categorías de acontecimientos •Riesgos y Oportunidades Se tienen eventos a nivel : 1. A nivel de la entidad 2. A nivel de actividad

Evento: Incidente o suceso generado por una fuente interna o externa, que afecta a la aplicación de una estrategia o el alcance de cualquier objetivo. 43

1.3.5. COSO II – ERM : Componentes Incluye todas las actividades desarrolladas por la administración relacionadas con la evaluación y aseguramiento de los procesos y riesgos financieros. Administrando los riesgos de la organización:

•

Establecimiento de metas y objetivos - Factores críticos de éxito - Plan estratégico

EVALUACION DEL RIESGO

- Análisis de competitividad

•

Identificación y análisis de riesgos - Nivel entidad: Penetrantes - Nivel de actividad (proceso) - Análisis y cuantificación de riesgos

44

1.3.5. COSO II – ERM : Componentes Corresponde a la selección más apropiada para cubrir los riesgos desarrollando un conjunto de acciones para alinear los riesgos con las tolerancias de riesgos de la entidad y el interés o apetito por los mismos

• Evaluación de posibles respuestas (mitigar, transferir, aceptar, evitar) RESPUESTA AL RIESGO • Selección de respuesta • Manejo del cambio

45

1.3.5. COSO II – ERM : Componentes

RESPUESTA AL RIESGO

Mitigar

Transferir

•Implementar controles (mitigar/reducir)

•Compartir, asociación con alguien.

•Por ejemplo. Definir, implementar controles apropiados para reducir la probabilidad o el impacto del riesgo

•Por ejemplo, compartir el riesgo con socios o transferirlo mediante cobertura de seguro, acuerdo contractual u otros medios.

Aceptar

Evitar

•Monitorear

•Eliminar

•Reconocer formalmente la existencia del riesgo y monitorearlo.

•Por ejemplo, donde sea factible, escoger no implementar ciertas actividades o procesos que generen un riesgo (es decir, eliminar el riesgo al eliminar la causa)

46

1.3.5. COSO II – ERM : Componentes

RESPUESTA AL RIESGO

Alta I M P A C T O Baja

Riesgo (Alto)

Riesgo (medio)

Transferir

Evitar

Bajo (Riesgo)

Aceptar

Riesgo (Medio)

Mitigar

PROBABILIDAD

Alta 47

1.3.5. COSO II – ERM : Componentes Principales consideraciones con relación a TI: • Los riesgos de TI son penetrantes a toda la organización, cuentas y procesos. A nivel de entidad: RESPUESTA AL RIESGO

• Un sub-comité de planeación de TI el cual debería responder por el plan de implementación de controles de TI, su seguimiento e integración con el plan global de la organización. • Evaluación de los riesgos de TI A nivel de actividades : • Evaluación de riesgos como parte de metodologías de desarrollo, y control de cambios en Infraestructura y operaciones. 48

1.3.5. COSO II – ERM : Componentes •

Las Actividades de Control son las políticas y los procedimientos que ayudan a asegurar que se están llevando a cabo las directivas administrativas necesarias para manejar los riesgos.

•

Las actividades de control deben estar incorporadas en las operaciones del negocio.

•

Las actividades de control están ligadas a la evaluación de riesgos, ya que éstas sirven como medio para que el riesgo sea administrado apropiadamente.

•

Enfocadas a corrección.

ACTIVIDADES DE CONTROL la

prevención,

detección

y

49

1.3.5. COSO II – ERM : Componentes ACTIVIDADES DE CONTROL

Principales consideraciones con relación a TI: • La información confiable es la base de la generación de Estados Financieros • Existen dos grandes grupos de actividades de control:

Controles generales relacionados con la tecnología

Controles de Aplicación

• Aplican a la mayoría o todas las aplicaciones de sistemas y ayudan a asegurar su continuidad y operación adecuada.

• Incluyen pasos computarizados con la aplicación de software y manuales de procedimientos relacionados para controlar el procesamiento de varios tipos de transacciones.

50

Controles generales relacionados con la tecnología Marco de referencia COBIT 1. 2. 3. 4.

CobiT

Seguimiento de los procesos Evaluar lo adecuado del control Interno Obtener aseguramiento independiente Proveer una auditoría independiente

Seguimiento

1.Definición del nivel de servicio 2.Admistración del servicio de terceros 3.Adm. de la capacidad y el desempeño 4.Asegurar el servicio continuo 5.Garantizar la seguridad del sistema 6.Identificación y asignación de costos 7.Capacitación de usuarios 8.Soporte a los clientes de TI 9.Admistración de la configuración 10.Administración de problemas e incidentes 11.Administración de datos 12.Administración de Instalaciones 13.Administración de Operaciones

Req. Información Efectividad, Eficiencia, Confidencialidad, Integridad, Disponibilidad, Cumplimiento, Confiabilidad

Recursos de TI Datos, Aplicaciones Tecnología, Instalaciones, Recurso Humano

Prestación de Servicio y Soporte Tomar en consideración que ahora se tiene COBIT 5

Planeación y Organización

1. Definir un plan estratégico de TI 2. Definir la arquitectura de información 3. Determinar la dirección tecnológica 4. Definir la organización y relaciones de TI 5. Manejo de la inversión en TI 6. Comunicación de la directrices Gerenciales 7. Administración del Recurso Humano 8. Asegurar el cumplir requerimientos externos 9. Evaluación de Riesgos 10. Administración de Proyectos 11. Administración de Calidad

Adquisición e Implementación

1. Identificación de soluciones 2. Adquisición y mantenimiento de SW aplicativo 3. Adquisición y mantenimiento arquitectura TI 4. Desarrollo y mantenimiento de Procedimientos de TI 5. Instalación y Acreditación de sistemas 6. Administración de Cambios 51

Controles de aplicación •

Son los controles embebidos en los programas para prevenir o detectar transacciones no autorizadas.

•

Combinadas con controles manuales contribuyen al aseguramiento de la integridad, validez y registro adecuado de la información.

Algunos Ejemplos: • Balanceo de transacciones (reconciliaciones detectando errores en la entrada de datos) • Dígitos de chequeo • Listas predefinidas (Precios, Materiales, Proveedores) • Limites de rangos o de valores.

52

Relación : Controles Generales Relacionados con la Tecnología y Controles de aplicación La relación entre los controles de aplicación y los controles generales relacionados con la tecnología es tal que los Controles Generales son normalmente necesarios para soportar el funcionamiento de los controles de aplicación, y ambos son normalmente necesarios para asegurar el procesamiento completo y preciso de información.

• Cambios en los programas.

• Centro de datos y operaciones de red.

• Seguridad de accesos. • Adquisición, desarrollo y mantenimiento de programas (sistemas)

• Adquisición, cambios y mantenimiento de aplicaciones.

53

1.3.5. COSO II – ERM : Componentes Información y Comunicación representa el proceso por medio del cual se asegura que la información relevante es identificada y comunicada de manera adecuada y oportuna a todo el personal de la entidad.

INFORMACION Y COMUNICACION

54

1.3.5. COSO II – ERM : Componentes El Monitoreo es el proceso que evalúa la calidad del desarrollo del Control Interno en el tiempo, mediante una evaluación continua de los controles, tomando las acciones correctivas necesarias. •

Monitoreo Ongoing – Actividades regulares de la administración – Corroboración de información (interna vs externa) – Estructura organizacional apropiada – Actividades de supervisión de las funciones de control – Verificación de información – Información de auditores (externos e internos) – Reuniones periódicas – Auto control

•

Evaluaciones Separadas – Efectividad del Sistema de Control Interno – Efectividad de los procedimientos ongoing

•

Información de deficiencias

MONITOREO

Ongoing: término técnico que significa estar actualmente en proceso, en continuo movimiento, hacia delante

55

Beneficios COSO ERM •

Permite a la Dirección de la empresa poseer una visión global del riesgo y accionar los planes para su correcta gestión.

•

Posibilita la priorización de los objetivos, riesgos clave del negocio, y de los controles implantados, lo que permite su adecuada gestión. Toma de decisiones más segura, facilitando la asignación del capital.

•

Alinea los objetivos del Grupo con los objetivos de las diferentes unidades de negocio, así como los riesgos asumidos y los controles puestos en acción.

•

Permite dar soporte a las actividades de planificación estratégica y control interno.

•

Permite cumplir con los nuevos marcos regulatorios y demanda de nuevas prácticas de Gobierno Corporativo.

•

Fomenta que la gestión de riesgos pase a formar parte de la cultura del Grupo.

56

Beneficios COSO ERM •

Reducir sorpresas y pérdidas operativas

•

Proveer respuestas integradas a riesgos múltiples.

•

Aprovechar las oportunidades

•

La gestión de riesgos proporciona rigor para identificar los riesgos y seleccionar entre las posibles alternativas de respuestas a ellos: mitigar, transferir, aceptar o evitar.

57

Limitaciones de COSO ERM •

COSO ERM no garantiza que la entidad será exitosa y logrará todos sus objetivos

•

Limitaciones: •

Cambios en políticas o programas del Gobierno

•

Competencia

•

Condiciones económicas

•

Malas decisiones

•

Errores y equivocaciones

•

Gerentes incompetentes

•

Omisión o debilitamiento de control interno, colusión, ignorar el ERM

•

ERM no refleja una adecuada relación costo-beneficio.

•

Transgregación Gerencial: Un gerente puede eludir intencionalmente las prácticas establecidas debido a fines inadecuados (inobservancia gerencial a las políticas o procedimientos prescritos).

•

Colusión: Dos o más personas pueden colaborar para quebrar controles (confabulación). 58

Mitos sobre COSO ERM •

Es un cúralo-todo con el que se pueden tomar decisiones basados en información 100% confiable y basada en información sin margen de error.

•

Sólo sirve para catalogar o tomar un inventario de todos los riesgos que afectan a una organización.

•

Con él, las auditorías serán infalibles.

•

ERS es sobre seguros

•

Es un proceso independiente y aislado del resto de la organización

•

Cuesta demasiado implementarlo

59

1.3.6. Nuevo marco de Control Interno COSO 2013 •

El paso 14 de mayo del 2013, se publicó la actualización de COSO I.

•

No ha sido una labor breve, El Committe ha efectuado las siguientes etapas:

•

•

2010. Evaluación y encuestas a las partes interesadas.

•

2011. Diseño y estructura marco actualizado

•

2012. Exposición pública, evaluación y mejoras

•

2013. Finalización.

De los 5 componentes de Control Interno no varían con respecto al Marco Original publicado en el 1992, sin embargo, los principios y puntos de enfoque han sufridos cambios claves en cada uno de los componentes, esto a fin de mejorar y facilitar la implantación y mantenimiento. A continuación se detallan los cambios: •

Se aplica un enfoque basado en 17 principios

•

Aclara la necesidad de establecer los objetivos estratégicos como condición previa a la fijación de los objetivos de Control Interno.

•

Refleja la relevancia incrementada de la Tecnología de Información.

•

Fortalece los conceptos de Gobierno Corporativo.

•

Amplía el objetivo de reporte financiero, pasando a ser reporte en general.

•

Fortalece la consideración de las expectativas contra el fraude

•

Considera los diferentes modelos de negocio y estructuras organizacionales. 60 Raúl González Carrión CISA , IA ISO27001 , ABCP , COBIT , MASIE


A continuación se detalla los 17 principios con los que se implementa un adecuado Control Interno, relacionándolos con sus correspondientes elementos:

•

Entorno de Control 1.

La Organización ha de demostrar su compromiso con la integridad y los valores éticos.

2.

El Consejo de Administración debe demostrar independencia en la gestión y ejercer la supervisión del desarrollo y ejecución del control interno.

3.

La alta dirección debe establecer, con la supervisión del Consejo de Administración: la estructura, líneas de reporting, autoridad y responsabilidad en la consecución de objetivos.

4.

En sinfonía con los objetivos, la Organización debe demostrar su compromiso para atraer, desarrollar, y retener personas competentes.

5.

En la consecución de los objetivos, la Organización debe disponer de personas responsables para atender sus responsabilidades de Control Interno.

61 Raúl González Carrión CISA , IA ISO27001 , ABCP , COBIT , MASIE


•

Evaluación de Riesgos 6.

La Organización ha de especificar los objetivos con suficiente claridad para permitir la identificación y evaluación de riesgos relacionados.

7.

La Organización debe identificar y evaluar sus riesgos.

8.

La Organización gestionará el riesgo de fraude.

9.

La Organización debe identificar y evaluar los cambios importantes que podrían impactar en el Sistema de Control Interno.

Actividades de Control 10.

La Organización ha de seleccionar y desarrollar actividades de control que contribuyan a la mitigación de los riesgos para el logro de sus objetivos.

11.

La Organización seleccionará y desarrollará Controles Generales sobre la Tecnología de la Información.

12.

La Organización implementa sus actividades de control a través de políticas y procedimientos adecuados.



Información y Comunicación 13. La Organización ha de generar la información relevante para respaldar el funcionamiento de los otros

componentes del Control Interno. 14. La Organización compartirá internamente la información, incluyendo los objetivos y responsabilidades

para el control interno, necesaria para respaldar el funcionamiento de los otros componentes del Control Interno. 15. La Organización comunicará externamente las materias que afecten al funcionamiento de los otros

componentes de Control Interno.

•

Actividad de Monitoreo 15.

La Organización llevará a cabo evaluaciones continuas e individuales, con el fin de comprobar si los componentes del control interno están presentes y están funcionando.

16.

La Organización evalúa y comunica las deficiencias del control interno.



Se destaca que para la evaluación de riesgos se ha incluido los conceptos de: velocidad y persistencia de los riesgos como criterios para evaluar la criticidad de los mismos: •

Velocidad del riesgo: rapidez con la que impacta un riesgo en la organización una vez se ha materializado , es decir, hace referencia al ritmo con el que se espera que la entidad experimente el impacto.

•

Persistencia de un riesgo: duración del impacto después de que el riesgo se ha materializado.

•

Modificación de Roles y Responsabilidades de los participantes del proceso (CEO , CFO, tipos de Comités por Campos de Acción, Otros participantes a parte de los Auditores Externos – Medio Ambiente, Comercio Justo, Seguridad Laboral, Proveedores Externos).

•

El nuevo COSO no nos obligará a introducir cambios inesperados en los procedimientos de Control Interno aplicables en las Organizaciones, pues lo que esta nueva edición representa la materialización formal de los cambios que evolutivamente se habían observado necesarios introducir para hacer eficientes el Control Interno de nuestras empresas, sin olvidar la inter-relación que existe entre el denominado COSO II (ERM) y el COSO I, que ahora se ve explícitamente reconocida. 64 Raúl González Carrión CISA , IA ISO27001 , ABCP , COBIT , MASIE

FUNDAMENTOS DE LA GESTIÓN DE RIESGOS CORPORATIVOS 1.4. Riesgo y Control

65

1.4.1. Riesgo

“Cualquier asunto que podría evitar alcanzar los objetivos”

66

1.4.1. Riesgo (cont) En el sentido más amplio significa: • Exposición a la adversidad • frente a un resultado esperado o deseado

67

1.4.1. Riesgo (cont) Según Glosario: Riesgo – Es la posibilidad de que ocurra un acontecimiento que tenga un impacto en el alcance de los objetivos. El riesgo se mide en términos de consecuencias y probabilidad. Riesgo Residual – Son los riesgos que permanecen después de que la Dirección haya realizado sus acciones para reducir el impacto y la probabilidad de un acontecimiento adverso, incluyendo las actividades de control en respuesta de un riesgo. Interpretación académica Es una medida de incertidumbre que involucra el logro de los objetivos institucionales, lo que incluye las consecuencias y probabilidad de que un evento negativo ocurra.

68

1.4.1. Riesgo (cont) Según diccionario. Es la posibilidad o proximidad de un peligro o contratiempo // cada uno de los hechos desafortunados que puede cubrir un seguro // conjunto de circunstancias que pueden disminuir el beneficio empresarial…// estar expuesto a que se frustre el resultado deseado o a padecer alguna desgracia.

El riesgo es por si mismo una condición de la existencia, es inherente a cualquier recurso o actividad; por ello el riesgo no se crea ni se destruye; solo se transforma

69

1.4.1. Riesgo (cont) El problema como contingencia del riesgo La gama de riesgos que se enfrentan en una entidad depende, entre otros, de los siguientes factores: • El volumen de los recursos. • La complejidad de las actividades. • Estructura organizativa. • Magnitud de recursos y productos. • Giro de la empresa. • Nivel de tecnificación alcanzado. • Lapso y momento evolutivo de la entidad. • Marco competitivo nacional e internacional. • La velocidad con que se desenvuelve la entidad.

70

1.4.1. Riesgo (cont) DIFERENCIAS ENTRE PROBLEMAS Y RIESGOS Características Problema Riesgos Latencia en el tiempo Temporal Permanente Controles insuficientemente aplicados Detectivos y correctivos Preventivos Posibilidad de medición Existencia Elemento generador

Más cuantificable Real Agentes externos e internos

Menos cuantificable Posible Por naturaleza

Asignación de prioridad a su estudio y De acuerdo a tratamiento emergencia

Según experiencia e intuición

Posibilidad de análisis para identificación de causas y repercusiones

Mayor

Menor

Evidencia Momento de aparición

Existente Presente

Inexistente Futuro 71

1.4.1. Riesgo (cont) RIESGOS AGRUPADOS POR NIVEL JERÁRQUICO Hechos / Causas

Riesgos / Efectos Directivo

Indecisión Desconocimiento del entorno Desconocimiento de la entidad Imprecisión organizativa

Estancamiento de la entidad Sanciones legales Inaplicabilidad de directrices Conflicto interfuncional Gerencial

Descoordinación Desvaloración Irresponsabilidad Desinformación económica Desactualización Desestandarización Descalificación Desorientación Incompetencia Desacato Desconocimiento Deshosnetidad Desinterés Desobligación

Ineficiencia Desmotivación Fuga de recursos Incosteabilidad Especialista Inaplicabilidad Discontinuidad Inoperabilidad Incompatibilidad Incosteabilidad Operativo Conflicto operativo Errores Fraude Merma Accidentes

72

1.4.2. Riesgo – Algunos conceptos • APETITO DE RIESGO: nivel de riesgo que una organización está

preparada para aceptar, tolerar o soportar en un momento determinado de tiempo (cuantitativo o cualitativo).

• EVALUACIÓN DE RIESGOS: actividades para determinar el nivel

de exposición de un proceso frente a sus riesgos. Esto con el propósito de desarrollar estrategias de mitigación, a través de la instauración y fortalecimiento de controles. Los riesgos pueden ser operacionales, estratégicos, de reporte, regulatorios o cumplimiento y de gobierno.

73

1.4.2. Riesgo – Algunos conceptos • ADMINISTRACIÓN

DEL RIESGO: La cultura, procesos y estructuras para administrar efectivamente eventos potencialmente negativos. (Como no es posible eliminarlos totalmente, el objetivo es reducirlos a un nivel aceptable).

74

1.4.3. Riesgo – Tipos • RIESGO INHERENTE: nivel de riesgo propio de la actividad,

sin tener en cuenta el efecto de los controles. Fallas

Efecto en los recursos

Riesgo Inherente

75

1.4.3. Riesgo – Tipos • RIESGO RESIDUAL: nivel resultante del riesgo después de

aplicar los controles. Riesgo Inherente

Controles

Riesgo Residual

76

1.4.4. Control • CONTROL: mecanismo que permite atenuar el riesgo

inherente, con el fin de disminuir la probabilidad de ocurrencia y/o el impacto en caso de que dicho riesgo se materialice. Características de los controles:

• Están embebidos en las operaciones del negocio. • Están enfocadas en prevención, detección o corrección. • Pueden ser manuales o automáticos. Ejemplos: backups, mecanismos de seguridad, planes de evacuación.

77

1.4.5. Control - Tipos Se diseñan para cumplir varias funciones: Preventivos: Anticipan eventos no deseados antes de que sucedan. Detectivos: Identifican los eventos en el momento en que se presentan. Correctivos: Aseguran que las acciones correctivas sean tomadas para revertir un evento no deseado.

78

1.4.5.1 Control - Preventivo Son más rentables Deben quedar incorporados en los sistemas Evitan costos de corrección o reproceso

79

1.4.5.2 Control - Detectivo Son más costosos que los preventivos Miden la efectividad de los preventivos Algunos errores no pueden ser evitados en la etapa preventiva Incluyen revisiones y comparaciones (registro de desempeño) Conciliaciones, confirmaciones, conteos físicos de inventarios, análisis de variaciones, técnicas automatizadas, Límites de transacciones, passwords, edición de reportes y auditoría interna. 80

1.4.5.3 Control - Correctivo Acciones y procedimientos de corrección (la recurrencia) Documentación y reportes que informan a la Gerencia, supervisando los asuntos hasta que son corregidos o solucionados

81

1.4.6. Control: Manual | Automático • Manuales: Controles que son efectuados fuera de

cualquier aplicativo de TI (ej.: Control manual de acceso al centro de cómputo) • Automáticos: Controles automáticos encontrados en

todos los tipos de ambientes, sin tener en cuenta la plataforma tecnológica, el aplicativo o sistema que está siendo usado (ej.: validaciones, cálculo, interfaz entre aplicaciones, reportes, accesos).

82

1.4.7. Riesgo y Control – Visión del Riesgo Pasado • El monitoreo de riesgo es un función

exclusiva de los auditores internos. • El riesgo es un factor negativo a ser

controlado • Los riesgos son administrador en forma

aislada.

Presente y futuro • El monitoreo de riesgo es responsabilidad

de todos. • El riesgo puede considerarse también como

una oportunidad. • Los riesgos son administrados a través de

un proceso integrado.

• La medición de riesgos es subjetiva

• El riesgo es casi siempre cuantificado.

• Las funciones de administración de riesgos

• La administración de riesgos es

no están estructuradas y son divergentes.

• La revisión de riesgos se realiza

periódicamente por auditoría interna.

implementada dentro de una estructura integrada. • La revisión de riesgos acontece a través de

auto evaluación constante. 83

1.4.8. Riesgo y Control – Metodología de Gestión de Riesgos

Fuente: COSO ERM

84

1.4.9. Derivados del Proceso de Administración de Riesgos 1.

Mapa de Procesos (vinculado con los objetivos corporativos)

2.

Inventario de Riesgos (general y detallado por procesos).

3.

Análisis sobre Impacto – Probabilidad (votación).

4.

Mapa de Riesgos.

5.

Matriz de Administración de Riesgos (controles a implementarse para: evitar, reducir, compartir o aceptar el riesgo)

85

1.4.10. Mapa de Procesos – Ejemplo de una compañía que lleva una red de pagos

Fuente: Deloitte.

86

1.4.11. Mapa de Procesos – Ejemplo de una compañía comercial

Fuente: Deloitte.

87

1.4.12. Mapa de Procesos – Ejemplo de una compañía minera Procesos estrategico Procesos CORE

Procesos de gerenciami ento y soporte

Planeación estrategica -

Adquisición de Productos y Servicios

Producción y explotación de minas

Administración de inventarios y control de producción

Logística y fletes

Ventas y facturación

Recursos humanos Contabilidad y reportes financieros Tesorería Tecnología Jurídica fiscal y tributaria Medio ambiente salud y seguridad industrial Activos fijos e inversiones Fuente: Deloitte.

88

1.4.13. Mapa de Procesos – Ejemplo de una empresa de microfinanzas

89

1.4.14. Inventario de Riesgos – Ejemplo de una compañía que lleva una red de pagos

Fuente: Deloitte.

90

1.4.15. Inventario de Riesgos – Ejemplo de una empresa de microfinanzas

91

1.4.16. Modelo de Riesgos: Fuente Protiviti.

92

1.4.17. Modelo de Riesgos: The Risk Map Deloitte & Touche

Fuente: Deloitte.

93

1.4.18. Categorías de Riesgos del IIA.

Fuente: IIA

94

1.4.18. Categorías de Riesgos del IIA.

Fuente: IIA

95

1.4.19. Categorías de Riesgos: Fuente Deloitte & Touche

Fuente: Deloitte.

96

1.4.20. Procesos de votación - Probabilidad Ejemplo de criterios para definir la PROBABILIDAD de ocurrencia Criterio 5. Esperado 4. Muy Probable

3. Probable

Descripción En la ausencia de cualquier control puede ocurrir desfalco o errores severos en el año o periodo. En la ausencia de cualquier control, es muy probable que ocurra desfalco o errores por lo menos una vez al año o periodo. En la ausencia de cualquier control, es probable que ocurra desfalco o errores por lo menos una vez al año o periodo

2. No Probable

En la ausencia de cualquier control, es baja la probabilidad de que el desfalco o errores ocurran por lo menos una vez al año o periodo.

1. Leve

En la ausencia de cualquier control, no se espera el desfalco o los errores en los próximos 1-2 años o periodo.

Fuente: Deloitte.

97

1.4.21. Procesos de votación - Impacto Ejemplo de criterios para determinar el IMPACTO Criterio 5. Crítico

Duración Impacto potencialmente irreparable

4. Significativo Recuperable a largo plazo

3. Alto

Recuperable a corto plazo

2. Moderado Temporal

1. Bajo

Regulaciones y requerimientos estatutarios

Fraude

Inhabilitado para cumplir con las El fraude a nivel ejecutivo tiene un impacto material regulaciones y requisitos estatutarios. directo a la organización y también al declive del Pérdida de concesión y/o pérdida del precio accionario, el deterioro de la reputación, el negocio. impacto legal y regulatorio, etc. Significativos esfuerzos son El fraude por lo empleados, agentes, vendedores u necesarios para cumplir con otras personas tiene un impacto directo a la regulaciones y requisitos estatutarios. organización o a las unidades comerciales Las multas son materiales y acarrean deteriorando la reputación, impacto legal y regulatorio, el deterioro de la reputación. etc. Muchos recursos son necesarios para cumplir regulaciones y requisitos No es potencialmente susceptible al fraude estatutarios. Gran distracción para la organización. Algunos recursos son necesarios para cumplir regulaciones y requisitos No es potencialmente susceptible al fraude estatutarios. Gran distracción para la organización.

Impacto limitado

No es potencialmente susceptible al fraude

Fuente: Deloitte.

98

1.4.22. Procesos de votación - Evaluación Evaluación

A B C D E

Probabilidad de ocurrencia Esperado 5 Muy Probable 4 Probable 3 No Probable 2 Leve 1

BxF AxH CxI Dx J DxF CxF

Actividad 1 2 3 4 5 6

Impacto F G H I J

Crítico Significativo Alto Moderado Bajo

5 4 3 2 1

Calificación 20 15 6 2 10 15 http://www.sivagroup.co/ 99

1.4.22. Procesos de votación - Evaluación 1. Tormenta de ideas sobre riesgos y oportunidades 2. Identificar de raíz las causas y las correlaciones 3. La mejor forma es tener sesiones de facilitación 4. Calcular el impacto del riesgo usando la misma medida de los objetivos 5. Calcular los escenarios mínimo, máximo y probable 6. Preparar un programa de riesgo 7. Priorizar riesgos y oportunidades basados en su valor ponderado 8. Identificar los riesgos clave que requieren atención estratégica

Tormenta de ideas

Peso/Cálculo

Priorizar

Fuente: Deloitte.

100

1.4.23. Mapa de riesgos Alta

I M P A C T O

Alto impacto

Alto impacto Baja probabilidad

Alta probabilidad

Bajo (Riesgo)

Bajo impacto Baja probabilidad

Baja

Riesgo (Alto)

Riesgo (medio)

Riesgo (Medio)

Bajo impacto Alta probabilidad

PROBABILIDAD

Alta

101

1.4.23. Mapa de riesgos Posibilidad de que la magnitud del Riesgo afecte el cumplimiento de los objetivos o la eficacia de las estrategias de la compañía

5 Riesgos clave

Impacto

4 3

Nivel de exposición para que un riesgo se materialice, considerando la estructura de control actual de la compañía

2 1 1

2

3

4

5

Riesgos no aceptables

Probabilidad 102

1.4.24. Matriz de riesgos – Ejemplo de una empresa de microfinanzas

103

1.4.25. Matriz de riesgos – Ejemplo de una empresa de comercial

Fuente: Deloitte.

104

1.4.26. Matriz de riesgos – Ejemplo de una compañía que lleva una red de pagos

Fuente: Deloitte.

105

1.4.27. Mapa de riesgos – Ejemplo de un mapa de riesgos IIA

Fuente: IIA 106

1.4.27. Mapa de riesgos – Ejemplo de un mapa de riesgos IIA

Fuente: IIA 107

1.4.27. Mapa de riesgos – Ejemplo de un mapa de riesgos de seguridad de la información

Fuente: Deloitte.

108

1.4.27. Mapa de riesgos – Ejemplo de un mapa de riesgos corporativos

Fuente: Deloitte.

109

1.4.27. Mapa de riesgos – Ejemplo de un mapa de riesgos de continuidad

Fuente: Deloitte.

110

2. GESTIÓN DE RIESGOS DE TI 2.1. Algunos conceptos de Riesgos Tecnológicos

111

2.1.1. Riesgos Tecnológicos - Antecedentes Riesgo tecnológico: Su medición como prioridad para el aseguramiento del negocio • El empleo de la tecnología es una de las decisiones más comunes en la elección de

estrategias, incrementando la dependencia al uso de información electrónica dentro de las organizaciones. • La tecnología deja de ser un miembro pasivo y se convierte en un elemento

importante para la operación de los negocios.

112

2.1.2 Relación de la tecnología con los procesos de negocio • Para tener mayor claridad la relación

del riesgo tecnológico con el negocio, se observa el flujo existente en la figura, en la que se detallan los vínculos directos entre los componentes de la tecnología, los procesos, el logro de objetivos, el cumplimiento de metas y hasta la satisfacción de los stakeholders.

Fuente: Gustavo A. Solís Montes, (CobiT User Convention-CobiT y la 113 administración de riesgos).

2.1.3. Riesgos Tecnológicos • La tecnología se vuelve parte de la operación y su funcionamiento no puede

aislarse de los demás elementos del proceso. • Todos los integrantes en conjunto tienen un solo objetivo. • Sin embargo, como en todo proceso, existe el factor llamado “riesgo” • El riesgo está presente en la tecnología y como se puede observar en la siguiente

figura 2, está inmerso dentro de la operación del negocio.

114

2.1.4. Distribución de los riesgos – Riesgo Tecnológicos


2.1.5. Riesgo tecnológico – Definición Riesgo tecnológico: es aquella posibilidad de que ocurra un evento relacionado con la tecnología y que afecte adversamente el logro de los objetivos del negocio.

Existen algunas guías o bases que se pueden utilizar sobre los riesgos tecnológicos, como la que proporciona el ITGI (Information Technology Governance Institute). Aunque:

• • •

Depende de las características de cada una de las compañías, El tipo de tecnología que esté utilizando. Procesos a los que ésta esté relacionada dentro de la operación.

(sin ser éstos los únicos existentes, ya que dependen de la operación de cada empresa y de la constante innovación tecnológica que existe).

116

2.1.6. Afectación de la tecnología con el ambiente de control

Controles automáticos

Controles Generales Relacionados con la Tecnología

Fuente: Deloitte & Touche 117

2.1.8 Tipo de eventos de riesgos con los aspectos de tecnología relacionados (ejemplos) Tipo de evento

Aspecto de TI

Fraude Interno

Manipulación deliberada de los programas Uso no autorizado de funciones para modificación de programas. Manipulación deliberada de las instrucciones del sistema Manipulación deliberada del hardware Cambios deliberados a los sistemas y aplicaciones por medio de accesos internos no autorizados. Uso indebido de software no autorizado o sin licencia Evasión interna de los privilegios de acceso

118


Aspecto de TI

Fraude externo

Cambios deliberados a los sistemas y aplicaciones mediante accesos externos no autorizados Obtención de acceso por parte de intrusos hacia documentos físicos o electrónicos Evasión externa de los privilegios de acceso Intercepción de los canales de comunicación Contraseñas comprometidas Virus

Contratación y lugar de trabajo

Divulgación de información sensitiva hacia terceros por parte de los empleados Administración de proveedores 119


Aspecto de TI

Daño a activos físicos

Daños intencionales o accidentales a la infraestructura física de tecnología de información

Interrupción del negocio y fallas en los sistemas

Mal funcionamiento de hardware o software Fallas en las comunicaciones Sabotaje de los empleados Pérdida de personal clave de tecnología Destrucción de archivos de datos o software Robo de software o información sensitiva Virus computacionales Fallas en los respaldos de información Ataques para denegar el servicio Errores en la configuración 120


Aspecto de TI

Administración de procesos, ejecución y entrega

Errores en la manipulación de datos electrónicos Estaciones de trabajo sin atención Errores al realizar cambios Entradas de datos incompletas a las transacciones del sistema Errores de entrada o salida de datos Errores de programación o de pruebas Errores de operación Errores de procesamiento manual

Fuente: ISACA, The IT Dimension of Basel II

121

2.1.9. Administración de riesgos La decisión de incorporar tecnología en los procesos del negocio, trae consigo la decisión de administrar el riesgo tecnológico correspondiente

“quien no arriesga, no gana”

122

2.1.9. Administración de riesgos • Existen dos factores que no deben pasarse por alto al hablar de riesgo: • impacto (efectos que pueda tener para el negocio); y, • probabilidad (posibilidad de que ocurra el evento);

• La combinación de estos factores proporcionarán un panorama sobre las

consecuencias que pudiera llegar a sufrir el negocio. Análisis de riesgos. Es la etapa en la que se recopila la información acerca de la exposición de la operación al riesgo tecnológico, con el fin de tomar decisiones y administrar los riesgos de forma apropiada.

123

2.1.10. Proceso de administración de riesgo


2.1.11. Tratamiento de riesgo

125

2.1.12. Efecto esperado de las acciones de tratamiento


2.1.13. Medición de un riesgo tecnológico • Para medir un riesgo tecnológico es importante: • Cualitativo: magnitud de las consecuencias relacionadas con el riesgo • Cuantitativo: cantidad de ocurrencias relacionadas con el riesgo • Con cada una se puede hacer la medición y determinar los valores que

proporcionen la severidad del impacto y la probabilidad de ocurrencia. • Con la administración del riesgo se podrá dar un tratamiento a cada uno de los

casos que se presenten, con base en su impacto y probabilidad. Sin embargo, hay que preguntar: • ¿quién va a medir los riesgos tecnológicos? Y ¿de quién es la responsabilidad?

127

2.1.13. Medición de un riesgo tecnológico ¿La participación de los stakeholders dentro de la medición del riesgo tecnológico debe ser una prioridad para el negocio? Quizá la respuesta sería, si se trata de riesgos de tecnología, que la responsabilidad es de las áreas de Tecnologías de Información (TI); aunque, surge otra pregunta ¿cómo va a determinar el personal de TI la magnitud del impacto al proceso de negocio y a los objetivos de la empresa?, porque a pesar de formar parte de la operación, no conforma todo el proceso. • Por eso la participación de los stakeholders dentro de la medición del riesgo

tecnológico debe ser una prioridad para el negocio, con la finalidad de identificar con claridad los riesgos, las consecuencias, las actividades requeridas para su administración, así como medir y determinar la pérdida (en números), en caso de que se materialice el riesgo.

128

2.1.13. Medición de un riesgo tecnológico Importancia de la participación de los stakeholders: • Encuesta realizada por el ITGI a 200 profesionales de TI, en 14 países

(incluyendo el continente americano), de la totalidad de encuestados:

Sólo en 37% de las compañías, los stakeholders de las unidades de negocio participan en el proceso de administración de riesgos tecnológicos.

129

2. GESTIÓN DE RIESGOS DE TI 2.2. Principales marcos para la Administración de Riesgos de TI

130

2.2. Principales marcos para la Administración de Riesgos de TI • COBIT – Control Objectives for Information and related Technology (ISACA). • ISO 27005 Gestión del Riesgo en la Seguridad de la Información. • AS/NZS 4360 [Australia/Estándares Nueva Zelanda] • IT Risk (ISACA). • MAGERIT - Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información

(Gobierno de España). • OCTAVE - Operational Critical Threat, Asset and Vulnerability Evaluation - Evaluación de

Amenazasy Vulnerabilidades de Recursos Críticos Operacionales (Carnegie Mellon University). • NIST– National Institute of Standards and Technology; Risk Management Guide for Information

Technology Systems. 131

2. GESTIÓN DE RIESGOS DE TI 2.3. Riesgo Operativo

132

2.3. Riesgo Operativo ¿Qué es? •El riesgo operativo es la posibilidad de ocurrencia de pérdidas financieras

por eventos derivados de fallas o insuficiencias en los procesos, personas, tecnología de información y por eventos externos. •El riesgo operativo incluye el riesgo legal en los términos establecidos en la

norma. (fallas o deficiencias en el cumplimiento de las disposiciones legales) •El riesgo operativo no trata sobre la posibilidad de pérdidas originadas en

cambios inesperados en el entorno político, económico y social.

133

Resolución No JB-2005-834 de 20 de octubre del 2005

2.3. Riesgo Operativo Factores del Riesgo Operativo •Con el propósito de que se minimice la probabilidad de incurrir en pérdidas

financieras atribuibles al riesgo operativo, deben ser adecuadamente administrados los siguientes aspectos, los cuales se interrelacionan entre sí:

Factores de Riesgo Definir criterios

Procesos

Identificar riesgos

Analizar riesgos

Evaluar riesgos

Monitorear y Revisar

Eventos Externos

Comunicar y Consultar

Tecnología de Información

Personas

Etapas de la Administración del Riesgo Operativo

Mitigar riesgos

134


2.3. Riesgo Operativo Factores del Riesgo Operativo [Procesos] •Con el objeto de garantizar la optimización de los recursos y la estandarización de

las actividades, las instituciones controladas deben contar con procesos definidos de conformidad con la estrategia y las políticas adoptadas, que deberán ser agrupados de la siguiente manera: •Procesos gobernantes o estratégicos. •Procesos productivos, fundamentales u operativos. •Procesos habilitantes, de soporte o apoyo.

135


2.3. Riesgo Operativo Factores del Riesgo Operativo [Procesos] Ejemplo de una compañía comercial

136


2.3. Riesgo Operativo Factores del Riesgo Operativo [Procesos] Ejemplo de una compañía comercial

137


2.3. Riesgo Operativo Factores del Riesgo Operativo [Procesos] Ejemplo de una compañía minera Procesos estrategico Procesos CORE

Procesos de gerencia miento y soporte

Planeación estrategica -

Adquisición de Productos y Servicios

Producción y explotación de minas

Administración de inventarios y control de producción

Logística y fletes

Ventas y facturación

Recursos humanos Contabilidad y reportes financieros Tesorería Tecnología Jurídica fiscal y tributaria Medio ambiente salud y seguridad industrial Activos fijos e inversiones

138


2.3. Riesgo Operativo Factores del Riesgo Operativo [Procesos] •

Las políticas deben referirse por lo menos a:

información: • tipo de proceso (gobernante, productivo y de

1. diseño claro de los procesos. 2. descripción en secuencia lógica y ordenada

•

de las actividades, tareas, y controles; 3. determinación de los responsables de los procesos. 4. difusión y comunicación de los procesos. 5. actualización y mejora continua.

• • • • • •

•

apoyo), nombre del proceso, responsable, productos y servicios que genera el proceso, clientes internos y externos, fecha de aprobación, fecha de actualización, además de señalar si se trata de un proceso crítico.

Las instituciones controladas deberán mantener inventarios actualizados de los procesos existentes, que cuenten, como mínimo con la siguiente 139


2.3. Riesgo Operativo Factores del Riesgo Operativo [Personas] •Identificar apropiadamente las fallas o insuficiencias asociadas al factor “personas”,

tales como: •falta de personal adecuado, •negligencia, •error humano, •nepotismo de conformidad con las disposiciones legales vigentes, •inapropiadas relaciones interpersonales y ambiente laboral desfavorable, •falta de especificaciones claras en los términos de contratación del personal, •entre otros.

•Se deberá definir formalmente políticas, procesos y procedimientos que contemplen: •Procesos de incorporación •Procesos de permanencia •Procesos de desvinculación

140


2.3. Riesgo Operativo Factores del Riesgo Operativo [Tecnología de Información] •Contar con la tecnología de información que garantice la captura, procesamiento,

almacenamiento y transmisión de la información de manera oportuna y confiable; •Evitar interrupciones del negocio; y, •Lograr que la información, inclusive aquella bajo la modalidad de servicios provistos

por terceros, sea íntegra, confidencial y esté disponible para una apropiada toma de decisiones.

141


2.3. Riesgo Operativo Factores del Riesgo Operativo [Tecnología de Información] •Se debe definir formalmente políticas, procesos y procedimientos que aseguren la

adecuada planificación y administración de la tecnología de información, se debe considerar al menos lo siguiente: •Soporte adecuadamente los requerimientos de operación actuales y futuros de la entidad. •Satisfagan los requerimientos de la entidad. •Que el sistema de administración de seguridad satisfaga las necesidades de la entidad para salvaguardar

la información contra el uso, revelación y modificación no autorizados, así como daños y pérdidas. •Garantizar la continuidad de las operaciones. •Garantizar que el proceso de adquisición, desarrollo, implementación y mantenimiento de las aplicaciones satisfagan los objetivos del negocio. •Garantizar que la infraestructura tecnológica que soporta las operaciones, sea administrada, monitoreada y documentada de forma adecuada. •Seguridad en canales electrónicos •Cajeros automáticos •Puntos de venta •Banca electrónica •Banca móvil •Sistemas de audito respuestas •Corresponsales no bancarios 142


2.3. Riesgo Operativo Factores del Riesgo Operativo [Eventos Externos] •En la administración del riesgo operativo, las instituciones controladas deben

considerar la posibilidad de pérdidas derivadas de la ocurrencia de eventos ajenos a su control, tales como: •fallas en los servicios públicos, •ocurrencia de desastres naturales, •atentados y •otros actos delictivos,

Los cuales pudieran alterar el desarrollo normal de sus actividades. Para el efecto, deben contar con planes de contingencia y de continuidad del negocio.

143


2.3. Riesgo Operativo Factores del Riesgo Operativo [Resumen] Internos

Eventos Externos

•Inversión en Tecnología •Desarrollo de sistemas

•Proveedores

•Seguridad en los sistemas •Capacidad/Fallas

•Desastres naturales •Atentados

Procesos

Tecnología de información

•Tasas o plazos

•Procesamiento de transacciones

•Documentación •Fraude de empleados

•Leyes laborales •Falta de personal clave

Personas 144


2.3. Riesgo Operativo Administración del riesgo operativo •El diseño del proceso de administración de riesgo operativo deberá permitir

Identificar

Medir

Controlar

Monitorear

Exposiciones

145


2. GESTIÓN DE RIESGOS DE TI 2.4. The Risk intelligence Map

146

2.4. The Risk intelligence Map

El Risk Intelligence Map es una recopilación de situaciones (QUE) que pueden existir en una organización, pueden existir más. La estructura del Risk intelligence Map se deriva de COSO ERM.

Fuente: Deloitte. 147





2. GESTIÓN DE RIESGOS DE TI 2.5. Revisión marco COBIT 4.1

150

Evolución

Fuente: ISACA.ORG

151

Relación entre marcos y normas

Fuente: ISACA.ORG

152

¿Dónde encaja COBIT?

Fuente: ISACA.ORG

153

Procesos de Tecnología de la Información COBIT • COBIT establece los procesos de gestión de la Tecnología de la Información. • Estos procesos permiten realizar todas las actividades necesarias para lograr

efectividad y eficiencia en las operaciones de Tecnología de la Información. • Adicionalmente, provee un modelo de madurez para identificar la situación de la

Gestión de Tecnología de la Información.

154

Marco de Trabajo COBIT • El Marco de Trabajo COBIT fue creado con las siguientes características

principales: • Enfocado al Negocio • Orientado a Procesos • Basado en Controles • Dirigido por Mediciones COBIT es el acrónimo de Control Objectives for Information and related Technology.

155

COBIT: Premisa • El marco de trabajo COBIT está basado en la premisa que la tecnología de la

información debe entregar la información que la empresa requiera, para alcanzar sus objetivos.

• El Marco de Trabajo COBIT ayuda a alinear la tecnología de la información con el

negocio, enfocándose en los requerimientos de información del negocio y organizando los recursos de TI. COBIT provee el marco de referencia y la guía para implementar el gobierno de TI

Fuente: ISACA.ORG

156

COBIT: Principio • El Principio del Marco de Trabajo COBIT; es unir las expectativas que la alta

dirección tiene de tecnología con las responsabilidades administrativas. El objetivo, es facilitar el Gobierno de TI para entregar valor mientras se administran sus riesgos tecnológicos.

Fuente: ISACA.ORG

157

Marco de Trabajo COBIT 4.1 • Como Marco de referencia de control y gobierno para TI, COBIT se enfoca en dos

áreas claves: • Proveyendo la información requerida para soportar los objetivos y requerimientos de la organización. • Tratando la información como resultado de la aplicación combinada de recursos relacionados con TI que necesitan ser administrados por procesos De TI. Criterios de información Efectividad Eficiencia Procesos de TI

Confidencialidad Integridad

Requerimientos de la organización

Disponibilidad

Enfoque de control

Confiabilidad

Conformidad

Consideraciones

Fuente: ISACA.ORG

158

Cubo COBIT 4.1 • COBIT describe el ciclo de vida de TI con la ayuda de cuatro dominios: • Planear y Organizar • Adquirir e Implementar • Entrega y Soporte • Monitorear y Evaluar • Procesos son series de actividades con límites de control naturales. Existen 34

procesos a través de cuatro dominios. Estos procesos especifican lo que el negocio necesita para cumplir sus objetivos. La entrega de información es controlada por los 34 procesos de TI. • Actividades son acciones que son requeridas para alcanzar resultados medibles. Incluso, las actividades tienen ciclos de vida e incluyen muchas tareas discretas.

Fuente: ISACA.ORG

159

COBIT 4.1

Fuente: ISACA.ORG

160

Cubo COBIT 4.1: Dominios de TI Planear y Organizar(PO) • Objetivos: • Formular estrategias y tácticas • Identificar como la TI puede contribuir a alcanzar los objetivos de la organización. • Planear, comunicar y administrar la realización de la visión estratégica. • Implementar la infraestructura organizacional y tecnológica. • Enfoque: • Están la TI y la organización estratégicamente alineados? • ¿Está logrando la organización un óptimo uso de sus recursos? • ¿Todo mundo en la organización entiende los objetivos de TI? • ¿Los riesgos de TI están siendo entendidos y administrados? • ¿ La calidad de los sistemas de TI es apropiada para las necesidades de la organización? 161

Cubo COBIT 4.1: Dominios de TI Adquirir e Implementar (AI) • Objetivos: • Identificar, desarrollar o adquirir, implementar e integrar las soluciones de

TI. • Cambios y mantenimiento de los sistemas existentes.

• Enfoque: • ¿Los nuevos proyectos entregarán soluciones que satisfagan las necesidades de negocio? • ¿Los nuevos proyectos se entregarán a tiempo y dentro del presupuesto? • ¿Funcionarán los nuevos sistemas apropiadamente cuando se implementen? • ¿Los cambios serán hechos sin afectar las actuales operaciones de negocios? 162

Cubo COBIT 4.1: Dominios de TI Entrega y Soporte (DS) • Objetivos: • El proceso de entrega de los servicios requeridos. • La administración de la Seguridad, continuidad, datos e instalaciones

operativas. • Servicio de soporte para usuarios.

• Enfoque: • ¿Los servicios de TI son entregados de acuerdo a las prioridades institucionales? • ¿Los costos de TI están optimizados? • ¿La fuerza laboral es capaz de utilizar los sistemas TI de forma productiva y segura? • ¿Son adecuadas la confidencialidad, integridad y disponibilidad de los sistemas? 163

Cubo COBIT 4.1: Dominios de TI Monitorear and Evaluar (ME) • Objetivos: • Administración del Desempeño • Monitoreo del Control Interno • Garantizar el cumplimiento regulatorio • Proveer gobierno de TI

• Enfoque: • ¿El desempeño de TI es medido para detectar problemas antes que sea demasiado tarde? • ¿La administración asegura que los controles sean efectivos y eficientes? • ¿Puede vincularse el desempeño de TI a las metas de negocio? • ¿Los riesgos, controles, incumplimientos y desempeño son medidos y reportados? 164

Modelo de Madurez de COBIT

Nivel de Efectividad y Cumplimiento

Grado de Supervisión de la Gerencia Nivel de Confianza en los Controles Sofisticación de las Actividades de Monitoreo Estado empresarial actual Estándar internacional Mejor práctica en la industria Estrategia empresarial

• • •

Nivel de Documentación y Concientización

• • •

0 – El proceso no es realizado. 1 – El proceso es realizado sin planificación. 2 – El proceso se realiza siguiendo un patrón regular. 3 – El proceso está documentado y comunicado. 4 – El proceso es monitoreado y medido. 5 – Las prácticas líderes son seguidas y automatizadas. 165

COBIT 5

Fuente: ISACA.ORG

166

Principales diferencias entre COBIT 4.1 y COBIT 5 Existe un nuevo Dominio (ahora son 5), que se enfoca en aspectos de Gobierno de TI, denominado “EDM – Evaluar, Dirigir & Monitorear” y que cubre el antiguo proceso ME4 de COBIT 4. La cantidad de procesos se ha incrementado de 34 a 37 Si bien los objetivos de control que corresponden a cada proceso de COBIT 4, se mantienen mayoritariamente dentro del mismo Dominio, existen excepciones como las siguientes: • PO10 – Administrar los proyectos, pasó al Dominio BAI. • AI5 – Procurar recursos de IT, pasó al Dominio APO. • DS1 – Definir y Administrar los niveles de servicio, pasó al Dominio APO. • DS2 – Administrar los servicios de Terceros, pasó al Dominio APO. • DS3 – Administrar el desempeño y la capacidad, pasó al Dominio BAI. • DS6 – Identificar y asignar costos, pasó al Dominio APO. • DS7 – Educar y Entrenar a los usuarios, pasó al Dominio APO. En el dominio APO – Administrar, Planear y Organizar, se observa mayor reorganización interna de los objetivos de control, es decir que un antiguo proceso de COBIT 4, ahora puede estar distribuido como parte de hasta 5 procesos del mismo dominio en COBIT 5. El proceso DS12 – Administrar el Ambiente Físico ahora forma parte del DSS5 – Gestionar los Servicios de Seguridad Existen nuevos procesos cuyo contenido es en su mayoría producto de COBIT 5, como mencionamos • EDM1 – Definir el Framework para el Gobierno • APO1 – Definir el Framework para el Administración • APO4 – Gestionar Innovación • APO13 – Gestionar Seguridad (también hay un Proceso DSS05 Gestionar los Servicios de Seguridad)

•

BAI8 – Gestión del Conocimiento Fuente: ISACA.ORG

167

COBIT 5: Principios •

•

COBIT 5 permite que la información y la tecnología relacionada pueda ser gobernada y administrada de manera integral para toda la empresa, teniendo en cuenta los intereses relacionados con TI de las partes interesadas internas y externas. Los 5 principios de COBIT y los facilitadores son de carácter genérico y útil para las empresas de todos los tamaños, ya sea comercial, sin fines de lucro o en el sector público.

Fuente: ISACA.ORG

168

2. GESTIÓN DE RIESGOS DE TI 2.6. Metodología para realizar un análisis de riesgos de Confidencialidad, Integridad y Disponibilidad

169

Objetivos Brindar los conceptos básicos relacionados con el análisis de riesgos de los activos de información electrónica Presentar la Metodología de Análisis de Riesgos

170

La seguridad informática no es un esfuerzo de una sola vez IT Governance Institute, 2005

171

2.6.1. Conceptos básicos • Activo de información : en medio electrónico, magnético, óptico, papel u otro que

almacena o procesa información

172

2.6.1. Conceptos básicos Inventario de activos de información electrónica: • Existen diferentes enfoques para obtener un inventario de activos de información • Específicamente nos interesa un inventario que permita relacionar: • Proceso de la compañía • Activo de la información • Tipo de activo • Dueño • Nivel de impacto por pérdida de:

• Confidencialidad • Integridad • Disponibilidad

173

2.6.2. Metodología de Análisis de Riesgos Enfoque normativo Las actividades a realizar se han definido con base en el estándar ISO27001:2005 ¿Porqué basarse en este estándar? •

Conocer el nivel de seguridad existente en la información de la compañía

•

Tener suficientes elementos para abordar inversiones futuras siguiendo no sólo criterios de capacidad sino también de seguridad.

•

Provee un modelo para establecer y administrar un sistema de gestión de la seguridad de la información (ISMS) efectivo

174

2.6.2. Metodología de Análisis de Riesgos Enfoque normativo

PHVA PDCA 175

2.6.2. Metodología de Análisis de Riesgos Enfoque normativo PLAN: Establecer el ISMS: – Definir el alcance del ISMS – Definir una política de ISMS – Definir un enfoque de análisis de riesgos – Identificar los riesgos – Analizar y evaluar los riesgos – Identificar y evaluar las opciones de tratamiento de riesgos – Seleccionar los objetivos de control y los controles para el tratamiento de riesgos – Obtener la aprobación del riesgo residual – Autorizar la implementación y operación del ISMS – Preparar una declaración de aplicabilidad

Actividades de Análisis de Riesgos que permiten identificar los requerimientos de seguridad de la información del negocio

ISMS: Information Security Management System

176

2.6.2. Metodología de Análisis de Riesgos La metodología • La metodología de evaluación de riesgos es la siguiente:

FASE III: FASE I: Identificar y calificar los activos de información

FASE II: Identificar y evaluar los riesgos

Identificar y seleccionar alternativas de tratamiento de los riesgos

Fuente: Deloitte.

177

2.6.2. Metodología de Análisis de Riesgos FASE I: Identificar y calificar activos de información Esta fase se realiza por procesos de negocio de la compañía. Mediante la realización de entrevistas con los dueños de la información se ejecutan las siguientes actividades: • Obtener entendimiento de los procesos • Identificar la información necesaria para el desarrollo de los procesos y la información generada por las actividades que componen los procesos. • Identificar los activos de información que almacenan o procesan la información identificada. • Determinar el nivel cualitativo (o cuantitativo) de impacto asociado a la Confidencialidad, Integridad y Disponibilidad para cada activo.

178

2.6.2. Metodología de Análisis de Riesgos FASE I: Identificar y calificar activos de información • Se califica el nivel de impacto por pérdida de confidencialidad, integridad y

disponibilidad para cada uno de los criterios:

Financiero pérdidas económicas para la compañía.

Eficiencia del proceso Reejecución o ejecución lenta de los procesos de negocio.

Servicio al cliente Afectación de la imagen o de la calidad del servicio a los clientes de la compañía.

179

2.6.2. Metodología de Análisis de Riesgos FASE I: Identificar y calificar activos de información • Los dueños de la información califican el nivel de impacto en una escala de 1 a 5,

siendo: • 5 la calificación más alta (mayor impacto) • 1 la calificación más baja (menor impacto) • Las calificaciones se promedian y se obtiene una calificación única por activo Nivel de Impacto (1-5) Activo

Confidencialidad promedio

Integridad promedio

Disponibilidad Calificación promedio promedio

Activo 1

4.33

1.33

3

2.89

Activo 2

2.33

4

4

3.11

…

…

…

…

3.33

5

3.67

4.00

… Activo n

180

2.6.2. Metodología de Análisis de Riesgos FASE I: Identificar y calificar activos de información

Fuente: Deloitte.

181

2.6.2. Metodología de Análisis de Riesgos FASE I: Identificar y calificar activos de información La calificación numérica se convierte a una escala de Alto, Medio y Bajo Las calificaciones de los activos de información electrónica puede asimilarse como un fenómeno que sigue un modelo normal de distribución de probabilidad.

182

2.6.2. Metodología de Análisis de Riesgos FASE I: Identificar y calificar activos de información Con base en este hecho se clasifican los activos:

Clasificación

Calificación de impacto

Alto

Mayor o igual a µ + σ

Medio

Mayor a µ – σ Menor a µ + σ

Bajo

Menor o igual a µ - σ

µ: Media σ: Desviación estándar Para cada uno de los activos que obtienen una clasificación de impacto “Alto” se ejecutan las Fases II y III de la metodología que se definen en láminas siguientes.

183

2.6.2. Metodología de Análisis de Riesgos FASE I: Identificar y calificar activos de información Cuestionario identificación de activos

Fuente: Deloitte.

184


Fuente: Deloitte.

185


Fuente: Deloitte.

186


Fuente: Deloitte.

187

2.6.2. Metodología de Análisis de Riesgos FASE I: Identificar y calificar activos de información • Formulario 1 - Inventario de Activos de información por proceso con clasificación

188

2.6.2. Metodología de Análisis de Riesgos La metodología • La siguiente fase es Identificar y evaluar los riesgos:

FASE III: FASE I: Identificar y calificar los activos de información

FASE II: Identificar y evaluar los riesgos


189

2.6.2. Metodología de Análisis de Riesgos FASE II: Identificar y evaluar los riesgos •

El primer objetivo de esta etapa es la identificación de vulnerabilidades que pueden ser explotadas por una fuente de amenaza para cada uno de los activos de información.

•

Para la identificación de vulnerabilidades del sistema se define y aplica de una lista de chequeo de requerimientos de seguridad.

•

El tipo de vulnerabilidad varia dependiendo de la naturaleza del activo.

190

2.6.2. Metodología de Análisis de Riesgos FASE II: Identificar y evaluar los riesgos Lista de Chequeo de Controles: Contiene los estándares básicos de seguridad y se utiliza para evaluar e identificar sistemáticamente las vulnerabilidades asociadas a los activos. Son controles relacionados con: – Seguridad administrativa – Seguridad operativa – Seguridad técnica

Es esencial mantener actualizadas las listas de chequeo para reflejar cambios en el ambiente de control de una organización.

191

2.6.2. Metodología de Análisis de Riesgos FASE II: Identificar y evaluar los riesgos • La valoración del impacto de una vulnerabilidad se realiza utilizando la siguiente

clasificación: Nivel

Definición

Alto

La explotación de la vulnerabilidad (1) puede causar una pérdida, de alto costo, de importantes activos y/o recursos tangibles (2) puede violar, dañar o impedir significativamente la misión, la reputación o los intereses de la organización (3) puede causar muerte de personas o lesiones severas.

Medio

(1) puede causar la pérdida costosa de los activos y/o recursos tangibles (2) puede violar, dañar o impedir la misión, su reputación o los intereses de la organización (3) puede causar lesiones en personas.

Bajo

(1) puede causar la pérdida costosa de algunos activos y/o recursos tangibles (2) puede afectar perceptiblemente la misión, su reputación o los intereses de la organización. 192


Se deben identificar las amenazas y sus fuentes

•

Una amenaza es una posible acción que se ejecute para explotar exitosamente una vulnerabilidad de un activo.

•

Dicha acción puede ser ejecutada de forma accidental o intencional por un ente denominado “fuente de amenaza”

•

Se debe considerar toda amenaza que en determinado momento podría causar daño a la información electrónica y a su ambiente de procesamiento

193

2.6.2. Metodología de Análisis de Riesgos FASE II: Identificar y evaluar los riesgos • Amenazas y fuentes de amenazas humanas comunes: Fuente

Motivación

Amenaza

Hacker, cracker

Reto, ego, rebelión

Hacking, ingeniería social, intrusión de sistemas.

Criminales de la computadora

Destrucción de información, interés monetario, alteración no autorizada de datos.

Crimen informático, acción fraudulenta, soborno, spoofing.

Terroristas

Blackmail, destrucción, explotación, venganza.

Bomba, guerra industrial, ataque a los sistemas, penetración del sistema.

Espionaje industrial

Ventaja competitiva, espionaje económico

Robo de información, ingeniería social, intrusión de la privacidad personal.

Infiltrados (empleados deshonestos o despedidos)

Curiosidad, ego, inteligencia, interés monetario, venganza.

Abuso de computadoras, fraude, robo, ingreso de información falsificada, código dañino, venta de información. 194


Para establecer la probabilidad de amenaza que indique el nivel de aprovechamiento de una vulnerabilidad se consideran los siguientes aspectos: – Motivación y capacidad de la fuente de amenaza. – Existencia y efectividad de los controles existentes. – Naturaleza de la vulnerabilidad a explotar.

195

2.6.2. Metodología de Análisis de Riesgos FASE II: Identificar y evaluar los riesgos Existencia de controles Área de Seguridad

Criterios de Seguridad

Seguridad Administrativa

•Segregación de funciones •Continuidad •Capacidad de respuesta a incidentes •Investigaciones del personal y sus referencias •Evaluación de Riesgos •Capacitación técnica y de seguridad •Asignación de funciones •Plan de seguridad de aplicación o sistema

Seguridad Operativa

•Control de contaminantes aerotransportados •Controles de suministro eléctrico •Acceso y disponibilidad de los medios de datos •Distribución y etiquetado externos de los datos •Protección de instalaciones •Controles ambientales •Estaciones de trabajo, portátiles y computadores personales

Seguridad Técnica

•Comunicaciones •Criptografía •Control de acceso discrecional •Identificación y autenticación •Detección de intrusos •Reutilización de Objetos •Auditoría de Sistemas

196

2.6.2. Metodología de Análisis de Riesgos FASE II: Identificar y evaluar los riesgos • La clasificación de la probabilidad de la amenaza se realiza de acuerdo con la

siguiente clasificación:

Nivel Alta

Condiciones La fuente de amenaza está altamente motivada y es suficientemente capaz Los controles para prevenir que la vulnerabilidad sea explotada son inefectivos.

Media La fuente de amenaza está motivada y tiene la capacidad Los controles son adecuados y pueden impedir el éxito en la explotación de la vulnerabilidad. Baja

La fuente de amenaza tiene una escasa motivación y capacidad Los controles son adecuados para prevenir, o al menos impedir significativamente, que la vulnerabilidad sea explotada

197


El riesgo se puede expresar en función de: – La magnitud de impacto producido si una fuente de amenaza explota con éxito la vulnerabilidad – La probabilidad de que una fuente de amenaza procure aprovechar una vulnerabilidad identificada

•

La aceptabilidad del riesgo consiste en establecer los riesgos para los que deben ejecutarse acciones de tratamiento.

•

Para cada uno de los riesgos que obtienen una clasificación “Inaceptable” se ejecuta la fase final de la metodología

198

2.6.2. Metodología de Análisis de Riesgos FASE II: Identificar y evaluar los riesgos • La clasificación de los niveles de riesgo se realiza de acuerdo con la siguiente

clasificación:

Impacto Probabilidad

Bajo 10

Medio 50

Alto 100

Alta 1.0

Bajo 10

Medio 50

Alto 100

Media 0.5

Bajo 5

Medio 25

Medio 50

Baja 0.1

Bajo 1

Bajo 5

Bajo 10

Bajo: 1 a 10

Medio: 11 a 50

Alto: 51 a 100 Fuente: Deloitte.

199

2.6.2. Metodología de Análisis de Riesgos FASE II: Identificar y evaluar los riesgos • La ejecución de acciones de tratamiento y su oportunidad dependen del nivel de

riesgo:

Nivel

Acciones Necesarias

Alto

Hay una necesidad fuerte de tomar acciones de tratamiento. Se debe ejecutar un plan de acción a corto plazo. Medio Las acciones de tratamiento son necesarias y se debe desarrollar un plan para incorporar estas acciones dentro de un período de tiempo razonable Bajo Debe determinarse si las acciones de tratamiento son requeridas o se acepta el riesgo.

Fuente: Deloitte.

200

2.6.2. Metodología de Análisis de Riesgos FASE II: Identificar y evaluar los riesgos • La aceptabilidad de un riesgo se define en función del nivel de riesgo también.

Aceptabilidad

Criterio

Acción

Riesgo no aceptable

Nivel de riesgo mayor a 50 (Riesgo Alto)

Se deben aplicar opciones de tratamiento del riesgo

Riesgo aceptable

Nivel de riesgo menor o igual a 50 (Riesgo Medio o Bajo)

No se deben aplicar opciones de tratamiento del riesgo

Fuente: Deloitte.

201

2.6.2. Metodología de Análisis de Riesgos FASE II: Identificar y evaluar los riesgos • Formulario 2 - Matriz de Amenazas - Vulnerabilidades - Riesgo

Fuente: Deloitte.

202

2.6.2. Metodología de Análisis de Riesgos La metodología • La fase final es identificar y seleccionar alternativas de tratamiento de los riesgos:

Identificar y calificar los activos de información

Identificar y evaluar los riesgos


203

2.6.2. Metodología de Análisis de Riesgos FASE III: Selección de opciones de tratamiento de riesgos •

Identificación de opciones de tratamiento de riesgos para cada uno de los riesgos considerados como inaceptables.

•

Se analizan la viabilidad y la eficacia de las opciones de tratamiento de riesgo a aplicar

•

Seleccionar la opción más apropiada para la reducción del riesgo a un nivel tolerable.

204

2.6.2. Metodología de Análisis de Riesgos FASE III: Selección de opciones de tratamiento de riesgos •

Opciones de mitigación del riesgo

Mitigar

Transferir

• Implementar controles (mitigar/reducir)

• Compartir, asociación con alguien.

• Por ejemplo. Definir, implementar controles apropiados para reducir la probabilidad o el impacto del riesgo

• Por ejemplo, compartir el riesgo con socios o transferirlo mediante cobertura de seguro, acuerdo contractual u otros medios.

Aceptar

Evitar

• Monitorear

• Eliminar

• Reconocer formalmente la existencia del riesgo y monitorearlo.

• Por ejemplo, donde sea factible, escoger no implementar ciertas actividades o procesos que generen un riesgo (es decir, eliminar el riesgo al eliminar la causa) 205

2.6.2. Metodología de Análisis de Riesgos FASE III: Selección de opciones de tratamiento de riesgos • Identificación y selección de controles • Definir los controles a implementar que podrían mitigar los

riesgos identificados como inaceptables. • Consultar en la norma ISO27001 el inventario de los

posibles controles a implementar. • Seleccionar los controles a implementar en conjunto con los

dueños de la información de la compañía.

206

2.6.2. Metodología de Análisis de Riesgos FASE III: Selección de opciones de tratamiento de riesgos • Factores a considerar al seleccionar los controles

207

2.6.2. Metodología de Análisis de Riesgos FASE III: Selección de opciones de tratamiento de riesgos • El inventario de los posibles controles a implementar se

encuentra definido en la norma ISO27001. • La actividad de selección de los controles requiere la

participación activa de los dueños de la información de la compañía. • Se seleccionan controles: • Preventivos y detectivos • Técnicos y Operacionales • Siguiente paso: priorizar e implementar los controles

seleccionados

208

2.6.2. Metodología de Análisis de Riesgos FASE III: Selección de opciones de tratamiento de riesgos • Formulario 3 - Tratamiento de riesgos de nivel inaceptable

Fuente: Deloitte.

209

2.7. Continuidad del Negocio como parte de la evaluación de riesgos Plan de recuperación ante desastres – PRD (DRP - Disaster Recovery Planning): Es un plan enfocado a TI diseñado para restablecer la operabilidad de un sistema objetivo, aplicación o facilidades de cómputo en un sitio alterno después de una emergencia. Aplica a eventos mayores, usualmente catastróficos que evitan el acceso a las instalaciones principales por un periodo extendido de tiempo. Fuente: Contingency Planning Guide for Information Technology System National Institute of Standards and Technology (NIST) Planeación de la continuidad del negocio (PCN – BCP) (I) Tiene como objetivo proteger personas, activos y operaciones del negocio. (II) Busca garantizar la supervivencia de las actividades críticas de la compañía ante un escenario de desastre.

PROCESO

Fuente: Disaster Recovery Institute International - DRII Fuente: Deloitte.

210

2.7. Continuidad del Negocio como parte de la evaluación de riesgos Continuidad de negocio es más que tecnología La no disponibilidad de un proceso de negocio se genera por la pérdida total o parcial de uno o más de los siguientes elementos:

Personas

PROCESO Servicios Terceros

Tecnología

Información Física Infraestructura

Fuente: Deloitte.

211

2.7. Continuidad del Negocio como parte de la evaluación de riesgos Escenarios que pueden afectar un proceso Dependencia de personal clave para el desarrollo del proceso

No acceso a las aplicaciones / sistemas de información centrales que son clave para desarrollar el proceso. No disponibilidad de plataforma tecnológica local crítica para el desarrollo del proceso.

Personas

PROCESO No disponibilidad de proveedores críticos para el proceso No disponibilidad de clientes críticos para temas de tecnología

Servicios Terceros

Información Física Pérdida o destrucción de información física relevante para la ejecución del proceso.

Tecnología

Infraestructura

Pérdida y destrucc ión de las instalaciones donde se lleva a cabo el proceso No ac ceso a las instalaciones principales donde se ejec uta el proc eso.

Fuente: Deloitte.

212

2.7. Continuidad del Negocio como parte de la evaluación de riesgos • Aunque continuidad hace parte de la evaluación de riesgo operativo, es necesario

identificar el riego operativos y el riesgo de continuidad:

Evento

Riesgo de Continuidad

Interrupción de las comunicaciones de la oficina

√

Imposibilidad de acceder a las instalaciones físicas del banco

√

Virus masivo en el personal (pandemia)

√

Caída del autorizador central

√

Destrucción del centro de cómputo

√

Riesgo Operativo

Error en el Registro de operaciones en el sistema

√

Fraude

√

Operaciones inusuales o sospechosas

√

Sanciones legales o de regulación

√

Fuente: Deloitte.

213

2.7. Continuidad del Negocio como parte de la evaluación de Período riesgos en Contingencia Operación Normal del Negocio 10 : 01....

7:30 - 10:00

Desarrollo del PCN

Pruebas

Interrupción de la Operación De sistemas

PRTI y PRPs

Ultimo backup

Operación Movilización / Restauración funciones y sistemas críticos

Punto objetivo de Recuperación (RPO)

Restablecimiento de la Operación De Sistemas y Funciones del Negocio

Tiempo objetivo de Recuperación (RTO)

Fuente: Deloitte.

214

Manejo de Crisis

Recuperación de TI Administración Conocimiento Administración de la Calidad Salvaguarda y Salud Administración de Suministros

Fuente: Deloitte.

2.7. Continuidad del Negocio como parte de la evaluación de riesgos

Respuesta a la Emergencia

Gestión de la Continuidad del Negocio

Recuperación de procesos

Visión integral de la Gestión de la Continuidad del Negocio:

Administración de Riesgos

215

2.7. Continuidad del Negocio como parte de la evaluación de riesgos Ciclo de vida de la GCN, según el BCI:

La Guía de Buenas Prácticas GBP2010 todavía abarca las seis fases del ciclo de vida de la GCN pero ahora los interrelaciona más directamente a lo que se ha definido como Prácticas Profesionales (PP). Las seis PPs están subdivididas en dos Prácticas de Gestión y cuatro Prácticas Técnicas: Prácticas de Gestión • Política y Gestión del Programa • Integración de la GCN en la Cultura Organizacional Prácticas Técnicas • Entendimiento de la organización • Determinación de la Estrategia GCN • Desarrollo e Implementación de la Respuesta GCN • Ejercicios, Mantenimiento y Revisión

Fuente: Guía de Buenas Prácticas. BCI 216

2.7. Continuidad del Negocio como parte de la evaluación de riesgos ISO 22301:2012

• •

Es el nuevo estándar internacional para sistemas de gestión de continuidad de negocio (BCMS) BS 25999 se creó para establecer un punto de referencia uniforme en buenas prácticas, satisfacción de las necesidades de los clientes, gobierno, reguladores y otras partes interesadas. BS 25999 ha sido aceptada en todo el mundo y ha sido la base de muchos otras normas, y ha sido el material de partida para la creación de la ISO 22301.

ISO 22301 especifica los requisitos para planificar, establecer, implementar, operar, supervisar, revisar, mantener y mejorar continuamente un sistema de gestión documentado para prepararse, responder y recuperarse de los eventos no esperados que puedan surgir. ISO 22301 establece lo siguiente: • Mayor énfasis en la definición de objetivos, seguimiento, rendimiento y métricas; • Expectativas claras sobre la gestión de continuidad; • Cuidadosa planificación y preparación de los recursos necesarios para garantizar la continuidad del negocio;

217

2.7. Continuidad del Negocio como parte de la evaluación de riesgos Norma de referencia – Continuidad del Negocio:

218

2.8. Norma PCI – Introducción Payment Card Industry (PCI) •

Tras una serie de violaciones de seguridad de alto perfil al utilizar tarjetas de pago por los consumidores, estos se encuentran cada vez más preocupados por la seguridad de sus datos personales y financieros, y por ende del riesgo de fraude.

•

Impulsado por la necesidad de tranquilizar a los titulares de tarjetas, la industria ha desarrollado la norma de seguridad de datos (PCI DSS), como una norma mínima para todas las organizaciones que procesan, almacenan o transmiten datos de las tarjetas.

•

En el mercado se ofrecen un conjunto completo de servicios para brindar la seguridad necesaria y los procesos de gestión de fraude necesarios para su cumplimiento, así como cubrir las necesidades actuales que pueden limitar el impacto de la aplicación versus los requisitos de la norma.

219

2.8. Norma PCI - ¿Por qué? •

Demostrar a los clientes que la administración está tomando seriamente la seguridad de la información, se tienen controles implementados y efectivos en la transacciones que se generan por tarjetas de crédito y débito.

•

Reflejar confianza para atraer futuros clientes, brindando una imagen robusta y competitiva a nivel corporativo.

•

Demostrar que los controles operativos son correctamente controlados.

•

Ofrecer exención de penalidades, tarifas o multas que puedan surgir luego de un incidente de seguridad, proveyendo los controles adecuados donde corresponda y las acciones apropiadas consecuentes.

•

Incrementar la conciencia de seguridad dentro de las organizaciones.

•

Aumentar la eficiencia y el ahorro en los potenciales costos de TI debido a los requerimientos del DSS (ej. a través del incremento de refuerzos administrativos, controles de anti-virus, administración de seguridad de usuario,etc.)

220

2.8. Norma PCI – Haciendo una realidad •

www.pcisecuritystandards.org

•

Visa proporciona las siguientes guías:

•

–

Guías para miembros, locatarios y proveedores de servicios

–

Procedimientos de Auditoría de Seguridad

–

Glosarios

–

Cuestionarios de Auto evaluaciones

–

Procedimientos de escaneos de seguridad

Visa recomienda un enfoque que: –

Realice un análisis de flujo de datos

–

Realice un extensivo análisis de brechas

–

Defina a detalle un plan de remediación

¿Como se relaciona el PCI?

Análisis de Flujo de datos

Gap Analysis

Plan de Remediación

Implementación

Validación de cumplimiento 221

2.8. Norma PCI – Cómo cumplir •

PCI DSS es un estándar de seguridad que comprende doce requisitos de alto nivel y se divide en las siguientes categorías: Crear y mantener una red segura Proteger la información del titular de la tarjeta Mantener un programa de administración de la vulnerabilidades Implementar medidas robustas de control de acceso Supervisar periódicamente y realizar pruebas en las redes donde viaja la información Mantener una política de seguridad de la información

•

PCI DSS demanda a través de una variedad de áreas y como cualquier programa de remediación refiere: personas, procesos, tecnología y controles de gobierno.

222

2.8. Norma PCI – Enfoque Metodológico Definición de alcance Validar requerimientos

Analizar flujo de información

Seleccionar QSA & evaluar proveedores

Análisis de Cumplimiento

Programa de remedicación

Auditoría

Evaluar controles existentes

Realizar el programa

Escanear la red

Realizar el análisis de nivel de cumplimiento

Implementar mejoras de seguridad

Completar la Auditoría de Pre-certificación

Definir un programa para cumplir con lo que falte

Validar mejoras

Apoyar en la ejeución de la Auditoría

Administración del programa y Control de Calidad

Fuente: Deloitte.

223

2.8. Norma PCI – Enfoque Metodológico •

Los objetivos y requerimientos de control se basan en las Mejores Prácticas de seguridad de la información - pero son de amplio alcance: Seguridad en Redes

Protección de datos de tarjetas

Administración Control de de Acceso vulnerabilidades

Monitoreo de la red

Políticas de seguridad

Gente:

Concientización y entrenamiento de seguridad, uso de políticas aceptables, seguridad física, etc.

Procesos:

Admon del cambio, admon de cuentas de usuarios, desarollo aplicativo seguro, admon de incidentes, admon de llaves. etc.

Tecnología:

Firewalls, encripción de dase de datos, IDS, parches de S.O. configuración de servidores, etc.

Gobierno:

políticas y estándares, cumplimiento de terceras partes, monitoreo de vulnerabilidades, etc.

•

El patrocinio no siempre es fácil, dada la variedad de actores involucrados

•

Algunas habilidades pueden ser necesarios para definir el programa de trabajo la traducción de las deficiencias de control en los proyectos prioridad a los proyectos

•

Realizar el programa puede exigir un participación activa de todos los involucrados

Fuente: Deloitte.

224

2.8. Norma PCI – Barreras habituales en la implementación del programa 1.

Inadecuado o insuficiente patrocinio ejecutivo

2.

Gobierno “pobre” / falta de rendición de cuentas

3.

Alcances no logrables

4.

Falta de interés de los interesados

5.

Centrados en la TI con vistas hacia las personas / elementos del proceso

6.

Débil administración de dependencias de programas internos y externos

7.

Inadecuada planeación y diseño

8.

Insuficiente habilidades del equipo

9.

Competencia por los recursos

10.

Falta de gestión de riesgo

11.

Mantenerse al día en los cambios de PCI DSS

12.

Cambios dinámicos en el uso de la TI en la Institución

13.

Interpretación de requerimientos

14.

Subestimar la remediación requerida / plazos no realísticos Fuente: Deloitte.

225

2.9. Introducción a ISO ISO/IEC 38500:2008 La norma ISO/IEC 38500:2008 se publicó en junio de 2008, basándose en la norma australiana AS8015:2005. Es la primera de una serie sobre el Gobierno de TI. Su objetivo es proporcionar un marco de principios para que la dirección de las organizaciones los utilicen al evaluar, dirigir y monitorear el uso de las tecnologías de la información (TI's).

226

2.9. Introducción a ISO ISO/IEC 38500:2008 Alcance, aplicación y objetivos • La norma se aplica al gobierno de los procesos de gestión de la TI en todo tipo de organizaciones que utilicen tecnología de información, facilitando unas bases para la evaluación objetiva del gobierno de TI. Dentro de los beneficios de un buen gobierno de TI estaría la conformidad de la organización con: • los estándares de seguridad • legislación de privacidad • legislación sobre el spam • legislación sobre prácticas comerciales • derechos de propiedad intelectual, incluyendo acuerdos de licencia de software • regulación medioambiental • normativa de seguridad y salud laboral • legislación sobre accesibilidad • estándares de responsabilidad social 227

2.9. Introducción a ISO ISO/IEC 38500:2008 También la búsqueda de un buen rendimiento de la TI mediante: • apropiada implementación y operación de los activos de TI • clarificación de las responsabilidades y rendición de cuentas en lograr los objetivos • • • • • • •

de la organización continuidad y sostenibilidad del negocio alineamiento de las TI's con las necesidades del negocio asignación eficiente de los recursos innovación en servicios, mercados y negocios buenas prácticas en las relaciones con los interesados (stakeholders) reducción de costes materialización efectiva de los beneficios esperados de cada inversión en TI

228

2.9. Introducción a ISO ISO/IEC 38500:2008 Principios La norma define seis principios de un buen gobierno corporativo de TI: • Responsabilidad • Todo el mundo debe comprender y aceptar sus responsabilidades en la oferta o demanda de TI. • Estrategia • La estrategia de negocio de la organización tiene en cuenta las capacidades actuales y futuras de la TI.

•

•

•

•

Los planes estratégicos de TI satisfacen las necesidades actuales y previstas derivadas de la estrategia de negocio. Adquisición • Las adquisiciones de TI se hacen por razones válidas, basándose en un análisis apropiado y continuo, con decisiones claras y transparentes. Hay un equilibrio adecuado entre beneficios, oportunidades, costes y riesgos tanto a corto como a largo plazo. Rendimiento • La TI está dimensionada para dar soporte a la organización, proporcionando los servicios con la calidad adecuada para cumplir con las necesidades actuales y futuras. Conformidad • La función de TI cumple todas las legislaciones y normas aplicables. Las políticas y prácticas al respecto están claramente definidas, implementadas y exigidas. Conducta humana • Las políticas de TI, prácticas y decisiones demuestran respecto por la conducta humana, incluyendo las necesidades actuales y emergentes de toda la gente involucrada. 229

2.9. Introducción a ISO ISO/IEC 38500:2008 Modelo La dirección debe gobernar la TI mediante tres tareas principales: • Evaluar • Examinar y juzgar el uso actual y futuro de la TI, incluyendo estrategias, propuestas y acuerdos de aprovisionamiento (internos y externos). • Dirigir • Dirigir la preparación y ejecución de los planes y políticas, asignando las responsabilidades al efecto. • Asegurar la transición correcta de los proyectos a la producción, considerando los impactos en la operación, el negocio y la infraestructura. Impulsar una cultura de buen gobierno de IT en la organización. • Monitorizar • Mediante sistemas de medición, vigilar el rendimiento de la TI, asegurando que se ajusta a lo planificado.

230

2.9. Introducción a ISO ISO/IEC 38500:2008 Objetivos de la implantación de la ISO 38500: •

Garantizar la excelencia en los procesos de negocio y/o servicio como factor esencial del desarrollo de la actividad empresarial, mediante el empleo de administradores y trabajadores Idóneos y debidamente calificados.

•

Garantizar la elaboración y puesta en práctica de las políticas de gobernabilidad de la empresa.

•

Diagnosticar los cambios organizativos y estructurales que se requieran en la empresa y contribuir a perfeccionar los métodos y estilos de administración en función de propiciar una mayor participación, compromiso, espíritu creativo e innovador y motivación de todos los dirigentes y trabajadores para la formación de una cultura organizativa propia de la empresa.

•

Preparar a la empresa para que sea capaz de reaccionar con rapidez y eficiencia ante los cambios del entorno y las demandas cuantitativas y cualitativas.

•

Cumplir con las leyes y regulaciones de la actividad en que se desempeñe.

•

Gestionar los riesgos de forma eficiente.

231

3. ESTÁNDAR INTERNACIONAL DE AUDITORÍA 3.1. Norma ISA 315 – Identificación y evaluación del riesgo de error material a través del conocimiento y la compresión de la entidad y de su entorno

232

Norma ISA 315 • Norma ISA 315 ó NIA 315– Identificación y evaluación del

riesgo de error material a través del conocimiento y la compresión de la entidad y de su entorno

Qué Podría Salir Mal?

233

Norma ISA 315 (revisión de la norma) OBJETIVO A LOGRAR

•

Qué debe entender (evaluar) el Auditor?

•

La Entidad y su Entorno:

• • • • •

•

Factores relevantes Naturaleza de la Entidad Selección y Aplicación Políticas Objetivos y Estrategias y los Riesgos de Negocios Relacionados Medición y Revisión del Desempeño Financiero

Control Interno (Componentes)

234

Norma ISA 315 (revisión de la norma) REQUERIMIENTOS: A. Procedimientos de evaluación de riesgos. • El propósito es proveer una adecuada base (evidencia) para la identificación y evaluación de riesgos. (Se deben de enmarcar dentro del resto de procedimientos de auditoría). •

Los procedimientos para la evaluación de riesgos son: • Preguntas a la Dirección y a otro personal de la entidad (efectividad del control interno, proceso de transacciones, políticas contables, litigios, garantías, estrategias, etc.) orientadas a identificar riesgos. • Procedimientos de revisión analítica (a nivel de compañía, de más detalle o de ratios). • Observación e inspección (lecturas de informes, visitas o centros, trazar transacciones, inspeccionar registros, etc).

• Los procedimientos se llevan a cabo mientras se obtiene el conocimiento del negocio. Otros procedimientos

también pueden ser útiles: preguntas a asesores legales y expertos y obtención de información externa (informes analistas, prensa, reguladores, etc.) • El auditor debe considerar la información obtenida en el proceso de aceptación o continuidad del cliente, o

en el desarrollo de servicios anteriores. • La información obtenida de años anteriores debe ser verificada para determinar posibles cambios. 235

Norma ISA 315 (revisión de la norma) B. El conocimiento de la entidad y su entorno, incluido su control interno. ■ El conocimiento de la entidad y su entorno consiste en los aspectos siguientes: a) b) c) d) e)

Sector o industria, regulación y otros factores incluido el plan de contabilidad aplicable. Naturaleza de la entidad (dirección, propietarios, planes, estructura financiera, etc.) La selección y aplicación de políticas contables, incluyendo las razones en sus cambios e idoneidad y consistencia. Objetivos, estrategias y riesgos relacionados con el negocio. Medida y revisión de la actuación de la entidad, ya sean internas (control presupuestario) o externas (analistas).

■ Con respecto al conocimiento del control interno la norma establece: a) b) c) d)

El auditor debe obtener conocimiento del CI relevante a su auditoría. Los controles relevantes son lo que solos o en combinación pueden prevenir, detectar o corregir errores que afecten a las compañías. El conocimiento requerido del CI abarca su diseño y grado de implantación. Para ello no es suficiente con preguntas sino que hemos de hacer procedimientos para ver que los controles relevantes estén implantados (se usan). El auditor debe obtener un conocimiento de los componentes del CI: del ambiente de control, procesos de identificación y evaluación de riesgos, del sistema de información y de comunicación, de las actividades de control y de supervisión.

236

Norma ISA 315 (revisión de la norma) C. Identificación y evaluación del riesgo de manifestaciones erróneas significativas • La identificación y evaluación de riesgos ha de ser a nivel de estados financieros (riesgos inherentes) y a

nivel de manifestación (transacciones, saldos de cuentas y revelaciones). Es necesario considerar tanto la magnitud del riesgo como la probabilidad de provocar un efecto en las compañías. • Identificación: Conocimiento del negocio (incluido control interno) y su entorno, de los controles relacionados

a los riesgos y considerando las clases de transacciones, saldos de cuentas y revelaciones en las compañías. • Si el auditor no ha identificado riesgos no significa que no existen (significa que están mitigados por la

seguridad de la entidad). En estos casos hay que responde igualmente al riesgo de auditoría.

237

Norma ISA 315 (revisión de la norma) Riesgos que requieren consideración especial: a)

El auditor como parte de su evaluación debe determinar, según su juicio, que riesgos requieren especial consideración (se llaman significativos)

b)

Transacciones rutinarias o poco complejas son menos probables de causar un riesgo significativo ya que tienen menor riesgo inherente. Por otro lado los riesgos del negocio son más probables de causar un riesgo significativo

c)

El auditor ha de considerar: fraude, riesgos económicos, de legislación, complejidad de transacciones, partes relacionadas, subjetividad en estimaciones o incertidumbres, transacciones inusuales o fuera de su normal actividad.

d)

El auditor debe evaluar el control interno relacionado con los riesgos especiales y ver si los controles implantados están operando

“El auditor debe responder a los riesgos de carácter especial”

238

Norma ISA 315 (revisión de la norma) • Hay riesgos para los cuales los procedimientos substantivos no proporcionan una base suficiente de

evidencia (principalmente en procesos muy informatizados de compras, ventas, cobros y pagos, o en compañías que ofrecen servicios o productos vía internet). “Para estos casos el auditor debe evaluar el diseño y grado de implantación y efectividad de los controles de la entidad” • La evaluación de riesgos ha de revisarse durante todo el transcurso de la auditoría (ej. desarrollando

pruebas sobre los controles puede detectarse que no operan efectivamente, también en pruebas substantivas podemos detectar más errores que los previstos en nuestra evaluación inicial). En estos casos se debe modificar la estrategia de auditoría. D. Comunicación • El auditor debe comunicar a la Dirección los riesgos significativos identificados para los cuales no hay controles o estos son inadecuados y las debilidades de control interno.

239

Norma ISA 315 (revisión de la norma) E. Documentación El auditor debe documentar: a) Las conversaciones con el equipo de auditoría relativas a la identificación y evaluación de riesgos. b)

El conocimiento del negocio obtenido para evaluar los riesgos, las fuentes de información utilizadas y los procedimientos de evaluación aplicados.

c)

Los resultados de la identificación y evaluación.

d)

Los riesgos identificables, los controles relacionados a riesgos especiales o donde los procedimientos sustantivos no son suficientes para la obtención de la evidencia requerida.

240

Norma ISA 315 (revisión de la norma) FACTORES INDICATIVOS DE RIESGO SIGNIFICATIVO • • • • • • • • • • • • • • • • • • • •

Operaciones en regiones económicamente inestables. Operaciones expuestas a mercados volátiles. Alto grado de regulación compleja. Problemas de liquidez, incluyendo pérdidas de clientes importantes. Problemas en la disponibilidad de capital y crédito. Cambios en la industria o en la cadena de suministros. Expansión en nuevas localidades o en nuevas líneas de negocio. Cambios en la entidad por reorganizaciones o adquisiciones. Entidades o segmentos de negocio que probablemente se venderán. Alianzas complejas y joint ventures. Transacciones fuera de balance, propuestas especiales y otros complejos contratos financieros. Transacciones significativas con partes relacionadas. Carencia de personal cualificado. Cambios en personal clave incluyendo personal ejecutivo. Debilidades en el control interno, especialmente directivos. Instalación de nuevos sistemas de información. Investigaciones en las operaciones de la entidad por los reguladores. Historia de errores y de ajustes de finales de periodo. Gran número de transacciones no rutinarias (intercompañías) y grandes ingresos a final de año. Procedimientos de medición complejos, con estimaciones e incertidumbres. 241

Norma ISA 315 (revisión de la norma) Generalmente, TI beneficia el Control Interno de la Entidad al habilitar a una Entidad para: Aplicar consistentemente reglas de negocios predefinidas y realizar cálculos complejos en el procesamiento de grandes volúmenes de transacciones o datos. Mejorar la oportunidad, disponibilidad, y exactitud de la información. Facilitar el análisis adicional de la información. Mejorar la habilidad de monitorear el desempeño de las actividades de la Entidad y sus políticas y procedimientos. Reducir el riesgo de violación de los Controles. Mejorar la habilidad de lograr una segregación de funciones eficaz al implementar controles de seguridad en las aplicaciones, bases de datos, y sistemas operativos [ISA 315.A55] 242

Norma ISA 315 (revisión de la norma) La tecnología de información plantea también riesgos específicos para el Control Interno de la entidad, por ejemplo: • Otorgar confianza a sistemas o programas que procesan erróneamente datos o procesan datos incorrectos, o ambas cosas. • Acceder a los datos sin que se esté autorizado para ello, lo que puede provocar la destrucción de información o hacer movimientos en la información que no sean apropiados o no están autorizados, incluyendo la incorporación de información de transacciones no autorizadas o inexistentes. Existe un riesgo en particular, y que puede ser de trascendencia, cuando varios usuarios pueden acceder a una base de datos común. • Contar con privilegios de acceso más allá de los necesarios para realizar las funciones que tengan asignadas el personal de tecnología de información, con el riesgo de afectar la segregación de funciones. • Cambiar los datos almacenados en archivos maestros, sin que se cuente con la autorización correspondiente. • Hacer cambios no autorizados a los sistemas o a los programas. • Generar fallas por no hacer los cambios necesarios en los sistemas o programas. • Intervenir manualmente, de manera inapropiada, los sistemas. • Perder, potencialmente, información o no poder acceder a los datos. [ISA 315.A56] 243

Norma ISA 315 - International Standards onAuditing Los elementos manuales en el Control Interno pueden ser más adecuados cuando se requiere juicio y discreción como en las siguientes circunstancias: Transacciones grandes, inusuales o no recurrentes Circunstancias donde los Errores son difíciles de definir, anticipar o pronosticar En circunstancias cambiantes que requieren una respuesta de control fuera del alcance de un Control automatizado existente Al monitorear la efectividad de los Controles automatizados. [ISA 315.A57]

244

Norma ISA 315 - International Standards onAuditing Los elementos manuales en el Control Interno pueden ser menos confiables que los elementos automatizados porque pueden ser violados o ignorados, y también son más propensos a Errores y equivocaciones simples. Por lo tanto, no puede asumirse la consistencia de aplicación de un elemento de Control manual. Los elementos de Control manual pueden ser menos adecuados para las circunstancias siguientes: Transacciones de alto volumen o recurrentes o en situaciones donde los Errores que pueden anticiparse o pronosticarse pueden prevenirse, o detectarse y corregirse, por los parámetros de Control que son automatizados Actividades de Control donde pueden diseñarse y automatizarse adecuadamente las maneras específicas de realizar el Control. [ISA 315.A58]

245

Norma ISA 315 - International Standards onAuditing El alcance y naturaleza de los riesgos para el Control Interno varían dependiendo de la naturaleza y características del sistema de información de la Entidad. La Entidad responde a los riesgos que surgen del uso de TI o del uso de elementos manuales en el Control Interno al establecer Controles eficaces a la luz de las características del sistema de información* de la Entidad. [ISA 315.A59]

* Un sistema de información tiene una infraestructura (componentes físicos y equipos informáticos), programas informáticos, personal, procedimientos y datos. Muchos sistemas de información hacen uso extenso de la tecnología de información.

246

Norma ISA 315 (revisión de la norma) Controles Generales Relacionados con la Tecnología y Controles de Aplicación Los dos grupos amplios de las Actividades de Control de los sistemas de información son: Los Controles Generales Relacionados con la Tecnología, los cuales son políticas y procedimientos que se relacionan con muchas aplicaciones y sustenten el funcionamiento eficaz de los Controles de Aplicación ayudando a asegurar la operación correcta continuada de los sistemas de información, los CG que mantienen la integridad de la información y seguridad de la misma comúnmente incluyen controles sobre lo siguiente: • Centro de datos y operaciones de red • Adquisición, cambio y mantenimiento del software de sistemas • Cambio en el programa • Seguridad de acceso • Adquisición, desarrollo y mantenimiento del sistema de aplicación. Los Controles de Aplicación, los cuales se aplican al procesamiento de las aplicaciones individuales, generalmente operan a nivel de un proceso de negocios Estos Controles ayudan a asegurar que las transacciones ocurrieron, se autorizaron se registraron y procesaron de manera completa y exacta.

[ISA 315.A96] [ISA 315.A97]

247

La relación entre los controles de aplicación y los controles generales relacionados con la tecnología es tal que los Controles Generales de la Tecnología son normalmente necesarios para soportar el funcionamiento de los controles de aplicación, y ambos son normalmente necesarios para asegurar el procesamiento completo y preciso de información.

• Cambios en los programas.

• Centro de datos y operaciones de red.

• Seguridad de accesos. • Adquisición, desarrollo y mantenimiento de programas (sistemas)

• Adquisición, cambios y mantenimiento de aplicaciones.

248

Participación de los Especialistas de TI en una auditoría enfocada en riesgos • Las áreas donde un especialista en Tecnología de Información puede ser

involucrado incluyen las siguientes: • • • • • • •

Obtener una comprensión del sistema de información, incluyendo evaluar el diseño de los Controles y determinar si se han implementado. Identificar y evaluar los riesgos, incluyendo aquellos relacionados con el procesamiento computarizado. Diseñar el plan para las Pruebas de Controles. Diseñar las Pruebas de Controles. Realizar las Pruebas de Controles. Diseñar, desarrollar y usar el Análisis Exploratorio de Datos. Otros aspectos técnicos de la computadora del Compromiso de Auditoría.

Fuente: Deloitte.

249

3. ESTÁNDAR INTERNACIONAL DE AUDITORÍA 3.2. Controles Generales Relacionados con la Tecnología

250

Controles Generales Relacionados con la Tecnología • Los Controles Generales Relacionados con la Tecnología se definen como las políticas y

procedimientos que se relacionan con muchas aplicaciones y soportan el funcionamiento efectivo de los controles de aplicación ayudando a asegurar la operación apropiada continua de los sistemas de información. • Los Controles Generales Relacionados con la Tecnología comúnmente incluyen los controles

sobre: • Centro de datos y operaciones de red; • Adquisición, cambio y mantenimiento del software de sistemas; • Cambio en el programa; • Seguridad de acceso; y, • Adquisición, desarrollo y mantenimiento del sistema de aplicación.

251

Controles Generales Relacionados con la Tecnología • Centro de datos y operaciones de red: Consideraciones: • ¿Actualizan los trabajos por lotes (batch jobs) la información producida por la entidad usando TI utilizada dentro de los controles relevantes? • ¿Hay aplicaciones web / con interfase web en las que los usuarios tienen acceso para actualizar las transacciones financieras relacionadas con cuentas/revelaciones materiales? • Si una persona tiene acceso físico a la consola, ¿pueden circunscribirse controles de acceso lógico para obtener acceso? Factores de revisión: • Planeamiento de ejecución de procesos (incluido los respaldos) • Ejecución y control de procesos (día a día). • Hardware y Software utilizados (schedulers, consolas de monitoreo, medios de almacenamiento, etc.) • Recursos que se encuentran en el centro de cómputos. • Respaldos de Información. • Control de acceso físico. • Controles ambientales (detección y eliminación de humo/fuego, fuentes alternas de poder , etc.).

252

Controles Generales Relacionados con la Tecnología • Adquisición, cambio y mantenimiento del software de sistemas: Consideraciones: • ¿Qué tan frecuentes son las actualizaciones de seguridad liberadas por el proveedor? • ¿Hay aplicaciones relevantes administradas por el usuario (por ejemplo, Excel) almacenadas en los servidores? Factores de revisión: • Planificación, instalación, prueba y monitoreo de todos los cambios realizados sobre la plataforma (hardware y software de base) • Instalación de Parches • Mantenimiento y Soporte • Monitoreo y evaluación de performance, disponibilidad y fiabilidad de la plataforma

253

Controles Generales Relacionados con la Tecnología • Cambio en el programa y adquisición, desarrollo y mantenimiento del

sistema de aplicación: Consideraciones: • ¿Tiene la entidad la habilidad para modificar el código de la aplicación, incluyendo el código que genera los informes? • ¿Está planeando la entidad alguna liberación significativa antes del cierre del año fiscal? • ¿Usa la entidad alguna forma de software de administración de bibliotecas/librerías? Factores de revisión: Cambios en el programa • Metodología de cambios en las aplicaciones • Control de ambientes de pruebas y producción • Disponibilidad de documentación técnica y de usuario.

Adquisición, desarrollo y mantenimiento del sistema de aplicación • Implementación de aplicaciones adquiridas • Cambios en aplicaciones adquiridas • Disponibilidad de la documentación técnica

254

Controles Generales Relacionados con la Tecnología • Seguridad de acceso: Consideraciones: • ¿Se autentican los usuarios y administradores directamente en la aplicación? • ¿Tienen la capacidad los usuarios de acceder directamente a la base de datos fuera de la aplicación? Factores de revisión: • Normas, Políticas y Procedimientos de seguridad (Red, SO, Aplicaciones y BD) • Seguridad Lógica • Control de acceso a plataformas tecnológicas • Administración de usuarios • Respuestas ante incidentes de seguridad (virus, hacking)

255

Controles Generales Relacionados con la Tecnología Área de los Controles Generales Relacionados con la Tecnología

Seguridad de Acceso

Problemas / Riesgos que Surgen de TI

Elementos de Tecnología (sólo

Ejemplo de Controles

para fines ilustrativos)

Los usuarios inapropiadamente crean, eliminan o modifican las transacciones o datos financieros dando como resultado información producida por la entidad inválida, incompleta o incorrecta usando TI.

Aplicación

La administración aprueba la naturaleza y alcance de los privilegios de acceso de los usuarios para los accesos de los usuarios nuevos y modificados. Y/O La administración aprueba los cambios a los privilegios de acceso asignados a los perfiles/funciones estándar de aplicación. Y/O Los usuarios con acceso para ejecutar y aprobar las transacciones críticas de información financiera tienen autorización y son apropiados. Y/O Se realiza un examen de accesos para detectar y corregir los conflictos de Segregación de Funciones.

256


Seguridad de Acceso





Los usuarios hacen modificaciones inapropiadas a las configuraciones, algoritmos y programas del sistema afectando la confiabilidad de la información producida por la entidad usando TI y/o de los controles automatizados.

Aplicación, Base de Datos, Sistema de Operación, y Red

El acceso es autenticado a través de IDs y passwords únicos de los usuarios u otros métodos como un mecanismo para validar que los usuarios tengan la autorización para obtener acceso al sistema. Los parámetros de los passwords cumplen con las políticas y estándares profesionales y/o de la compañía (por ejemplo, longitud y complejidad mínima del password, caducidad y bloqueo de la cuenta). Y/O El acceso de nivel privilegiado (por ejemplo, administradores del sistema, administradores de la seguridad, acceso de emergencia, súper usuarios) está autorizado y restringido de manera apropiada. Y/O El acceso para los usuarios despedidos se elimina de manera oportuna de acuerdo con la política documentada de la compañía. Revisión de perfiles, implementación de atributos y aprobación, cambio de usuarios con revisión y aprobación.

257






Seguridad de Acceso

La administración no detecta las modificaciones inapropiadas a los programas, algoritmos, configuraciones, transacciones financieras y los datos que subyacen la información producida por la entidad usando TI y/o los controles automatizados.


El registro (logeo) está dentro del sistema y los registros (logs) son monitoreados o auditados regularmente para detectar actividades no autorizadas o inapropiadas.

Seguridad de Acceso

Los usuarios obtienen acceso no autorizado directamente a los datos a través de la base de datos o el sistema operativo para cambiar intencionalmente, o sin intención, los datos o informes que subyacen la información producida por la entidad usando TI y/o los controles automatizados.

Base de Datos, Sistema de Operación, y Red

El acceso a los objetos/tablas/datos de la base de datos y a los archivos/directorios sensibles del sistema operativo está limitado al personal autorizado, con base en sus responsabilidades del trabajo / función asignada, y es aprobado por la administración. Y/O El acceso de nivel privilegiado (por ejemplo, administradores del sistema, administradores de la seguridad, acceso de emergencia, súper usuarios) está autorizado y restringido de manera apropiada.

258





Seguridad de Acceso

Los mecanismos de seguridad son inadecuados, inefectivos o inconsistentes debido a la falta de políticas y estándares de seguridad establecidos. Esto incrementa el riesgo de acceso no autorizado afectando los datos que subyacen la información producida por la entidad usando TI y/o los controles automatizados.

Seguridad de Acceso

El personal (interno y externo) obtiene Red acceso no autorizado a la aplicación o a los datos a través de la red e intencionalmente, o sin intención, cambia los datos, programas o informes que subyacen la información producida por la entidad usando TI y/o los controles automatizados.

Centro de Datos y Operaciones de Red



Las políticas y estándares de seguridad de la información están documentadas, se revisan y actualizan de manera periódica y contienen los requerimientos apropiados de acuerdo con las normas profesionales.

La red está configurada para segmentar las redes internas y externas y para limitar el acceso a las aplicaciones de internet. Y/O El servidor de las aplicaciones web está configurado para validar de manera segura las sesiones de los usuarios.

259


Adquisición, Desarrollo y Mantenimiento del Sistema de Aplicación

Cambio en el Programa

Adquisición, Desarrollo y Mantenimiento del Sistema de Aplicación

Cambio en el Programa





Los cambios en la aplicación y en la base de datos no están debidamente autorizados y probados, y la implementación de dichos cambios impacta en la confiabilidad de los controles automatizados y/o en la confiabilidad de los datos usados para emitir la información producida por la entidad usando TI.

Aplicación y Base de Datos

Los cambios en la aplicación (incluyendo la interface y la base de datos) son aprobados y probados de manera apropiada antes de que se muevan al ambiente de producción.

Los programadores u otros usuarios promueven cambios inválidos o inapropiados en el ambiente de producción sin el conocimiento de la administración. Esto da como resultado modificaciones inapropiadas en los programas, aplicaciones, algoritmos, configuraciones del sistema y los datos que subyacen la información producida por la entidad usando TI y/o los controles automatizados.

Aplicación y Base de Datos

El acceso para implementar los cambios (incluyendo los cambios en la interface y en la base de datos) en el ambiente de producción de la aplicación está apropiadamente restringido y segregado del ambiente de desarrollo. Y/O La administración genera un reporte del sistema sobre los cambios en la producción y revisa los cambios regularmente para averiguar que sean apropiados y aprobados por la administración.

260

3. ESTÁNDAR INTERNACIONAL DE AUDITORÍA 3.3. Controles de aplicación

261

3.3.1. Ejemplos de controles de aplicación Se aplican al procesamiento de las aplicaciones individuales, generalmente operan a nivel de un proceso de negocios. Estos Controles ayudan a asegurar que las transacciones ocurrieron, se autorizaron se registraron y procesaron de manera completa y exacta. • Lista de datos predefinida: el usuario solo puede seleccionar de una lista de

datos aceptables. Por ejemplo: lista de códigos de producto con inventario disponible. • Pruebas de lógica: control basado en rangos de datos o en pruebas

alfanuméricas. Por ejemplo: edades negativas o muy altas, cantidad de dígitos de la tarjeta de crédito.

262

3.3.1. Ejemplos de controles de aplicación • Cálculos: una rutina del sistema realiza procesamiento matemático de los datos

con base en una configuración. Por ejemplo, cálculo de depreciación, cálculo de intereses. • Controles manuales basados en tecnología(CGI): controles híbridos donde la

tecnología provee parte del control y el control se completa con una actividad manual, tales como los reportes generados por el sistema de información que deben ser revisados manualmente por un usuario para identificar excepciones o desviaciones de razonabilidad. Por ejemplo: reporte de la edad de la cartera, reporte de ventas por regional y por agente comercial.

263

3.3.1. Ejemplos de controles de aplicación Controles automáticos en la aplicación • Restricciones de acceso lógico (a través de identificación y password)

• Validaciones de campos (de consistencia, que se impida ingresar números

negativos, validaciones contra campos predefinidos –p.ej. que se completan automáticamente sin intervención del usuario, campos de opción múltiple –p.ej. limitación a determinados tipos de documento- o contra archivos maestros –p.ej. Clientes válidos, proveedores válidos, etc.-)

264

3.3.1. Ejemplos de controles de aplicación Controles automáticos en la aplicación • Validaciones (balanceos de totales o entre debe y haber, integridad en el

completamiento de la información – que no se omitan campos clave)

• Requerimientos de aprobación de un tercero y no poder avanzar en el proceso sin

dicha aprobación, requerimientos de aprobación complejos según condiciones como monto o a través de sistemas de workflow o estrategias de liberación.

265

3.3.1. Ejemplos de controles de aplicación Controles automáticos en la aplicación • Validaciones y cálculos contra otros archivos (p.ej. No permitir el procesamiento de

un pedido de ventas si el monto del mismo supera el límite de crédito asignado a dicho cliente)

266

3.3.2. Procesos del Negocio Secuencia de actividades desarrolladas por una organización para procesar o tramitar transacciones que permiten la ejecución de una función propia del negocio.

Proceso 1 Insumos

Processamento

Produto

Proceso 2 Insumos

Processamento

Produto

267

3.3.2. Procesos del Negocio • Agrupar las actividades semejantes

• Los procesos no se limita a un área o departamento. Un proceso puede

pasar por mas de un área

Área A

Área B

Área C

Área D

PROCESO

268

3.3.2. Procesos del Negocio • Los procesos de negocio es un conjunto

de: • Transacciones • Controles • Una serie de pasos, acciones o tareas a seguir para lograr un cierto objetivo del negocio. • Una secuencia de actividades realizadas por una entidad para procesar las clases de transacciones relacionadas entre sí.

Contabilidad Financiera

Ingresos (RE) Gastos (EX) Inventario (IM) Activo Fijo (FA) Nómina y Personal (PR) Tesorería (TR)

269

3.3.3. Pruebas en los procesos del negocio • Nuestro entendimiento de los procesos de negocio de cada uno de los

procesos debe incluir: • • • • •

•

Políticas y procedimientos Aplicaciones y controles significativos Entradas, procesos y salidas Procedimientos para manejar excepciones Controles organizacionales y sistemáticos para asegurar un nivel apropiado de segregación de funciones Reportes usados o creados durante el proceso

270

3.3.4. ¿Cómo identificar controles? • En la mayoría de las ocasiones tenemos que ir más allá de la simple definición

del control, y no perder de vista cuales son los riesgos que queremos minimizar. • Tenemos que entender qué hay detrás de ese control, puede ser un control

de accesos, un control que está programado en el sistema (puede estar ligado a políticas de la empresa) y por lo tanto tiene una dependencia directa al control de cambios de dicho sistema. Además se podrían tener controles manuales como aprobaciones y demás

271

3.3.5. Documentar pruebas de control Al DOCUMENTAR una prueba de Procesos de Negocio • No se trata de acumular “impresiones de pantalla” (print screen) de las aplicaciones de los clientes. • Sólo hay que obtener soporte de aquella documentación que realmente nos corrobora la existencia de un control. • En la mayoría de los casos, deberá de describirse el proceso y control que ha sido probado, indicando: • Lo que se revisó • Cómo y con quién se revisó • Los resultados de la revisión • La documentación soporte • Conclusión de la prueba de control

272

3.3.6. Enfoque de arriba hacia abajo Enfoque de Arriba Hacia Abajo (“top-down”) : Un enfoque eficiente para identificar los Controles Relevantes. Primero, buscamos los Controles de Alto Nivel que utiliza la alta Administración, después los Controles Detallados utilizados por los niveles más bajos de la Administración y por otros, según sea apropiado.

Beneficios del Enfoque de Arriba Hacia Abajo (“top-down”) : Se identifican los controles de más alto nivel, que creemos serán eficientes para proporcionar Seguridad Razonable y lograr uno o más Objetivos de Control. Normalmente reduce el número de Controles a identificarse, evaluarse y probarse. Se realizan indagaciones con los niveles ejecutivos de la administración. Si los Controles de Alto Nivel no son eficaces para los propósitos de la auditoría, se identifican los controles del siguiente nivel de la Administración en los cuales ellos confían. 273

3.3.6. Enfoque de arriba hacia abajo Número de Objetivos de Control cubiertos

Controles Más datos, menos detalles

- Alto Nivel

- Supervisión

- Operativos

Conjunto distinto de datos, mayor detalle

Controles detallados transacciones especificas

3.3.7. Controles relevantes Son aquellos controles identificados, para los Objetivos de Control relevantes, en los cuales pretendemos confiar, si estamos planeando: 1. Obtener Seguridad de Control o 2. Probar la eficacia operativa de los Controles.

275

3. ESTÁNDAR INTERNACIONAL DE AUDITORÍA 3.4. Riesgos & Controles en Procesos de Negocios

276

Proceso de Negocio : Ingresos Administración de Maestro de clientes

Calculo de precio de las ordenes de venta Requerimiento del cliente

Administración de crédito de clientes

Desarrollo de la solución para el cliente

Procesamiento de ordenes y Contratos

Entrega del bien o servicio

Recolección, empaque y despacho de ordenes

Maestro de clientes

Generación de la orden de venta

Maestro de bienes o serv

Desarrollo de la solución para el cliente

Entrega del bien o servicio

Facturación

Maestro de precios

Riesgos clave 1

Información inválida e incompleta.

2

Personal no autorizado con acceso a actividades en el proceso.

3

Registros duplicados en el sistema.

4

Inadecuada segregación de funciones.

5

Recaudo y cartera

Verificación que lo vendido, sea lo entregado y lo que se factura y recauda.

Consideraciones de controles automáticos clave 1

Segregación de funciones y personas autorizadas a cada una de las actividades del proceso

2

Administración de maestros claves del ciclo: clientes, bienes o servicios, precios

2

Valdiación de entrada en campos mandatorios en el registro de las ordenes de venta, en la remisión de despacho y en la factura.

Facturación

Proceso de recibo del pago

Administración del recaudo

277

Ingresos

Procesamiento de la Cobranza

Cliente

Administración del Inventario

Administración y Procesamiento de Pedidos

Facturación, Devoluciones sobre Ventas y Ajustes

Mayor General

Mantenimiento Archivo Maestro de Clientes

278

Ingresos

Pruebas principales Validar los usuarios con acceso a las opciones críticas de ingresos. Verificación a través de logs de auditoría que sólo los usuarios autorizados lo han realizado en el tiempo. Validar los controles automáticos establecidos en el flujo de transacciones de ingresos, tales como: • Validar los controles de retención de pedidos debido a morosidad o límite en el cupo de crédito. • Verificar los controles en la liberación de las órdenes de venta retenidas. • Verificar los controles sobre la modificación de las listas de precios. • Verificar que los precios son cargados a la factura automáticamente. • Verificar que no es posible ingresar precios manualmente en los pedidos. • Validar los controles en la asignación de porcentajes de descuento. • Validar que las facturas son alimentadas con la información del pedido. • Validar que el valor de los descuentos es calculado automáticamente. • Verificar que la información de precios no pueda ser modificada directamente en la factura. • Verificar controles en devoluciones. • Verificar controles en la emisión de notas crédito y débito. • Validar que el sistema calcula automáticamente el valor de la factura. • Validar los controles en la contabilización de facturas. • Verificar que al ingresar el pago al sistema se actualiza automáticamente la cartera del cliente. • Validar los controles de la interfaz de ingresos. Cruzar los pedidos con las entregas y las facturas de venta, con el fin de identificar discrepancias entre estos. Validar la integridad de datos en la maestra de clientes. 279

Ingresos

Pruebas principales Verificar si existen saltos o duplicados en los documentos que intervienen en el flujo de transacciones de ingresos. Realizar el re cálculo del reporte de cartera por edades.

280

Proceso de Negocio : Gastos Requerimiento de la persona en la cía.

Administración de los proveedores

Pago Generación de la orden de compra

Creación y Mantenimiento de ordenes

Verificación / registro de La factura

Pago

Registro de la factura del proveedor

Compra de materiales y servicios

Recepción del material o servicio

Recepción del bien o servicio

Maestro de proveedores

Maestro de materiales

Transferencia electrónica de fondos

Riesgos clave

Consideraciones de controles automáticos clave

1


2


1



2

Administración de maestros claves del ciclo: proveedores y materiales

3 4 5

Inadecuada segregación de funciones. Inexistencia aprobación/libreración de orden de compra, de la entrada al almacen, de la factura para pago y del pago

3

Valdiación de entrada en campos mandatorios en el registro de las ordenes de compra, entrada del bien o servicio, factura del proveedor

Pagos sin que el bien se haya recibido.

4

Autorizadores en la banca electrónica

4

Libreación de ordenes de compra, entrada a almacen, recepción del servicio, facutra para pago y pago

6

281

Gastos

Mayor General

Proveedor

Mantenimiento Archivo Maestro de Proveedores

Compras

Activos Fijos


Processing Procesamiento Accounts de Cuentas Payable por Pagar

Procesamiento de Gastos

Tesorería

282

Gastos

Pruebas principales Validar los usuarios con acceso a las opciones críticas de gastos. Verificación a través de logs de auditoría que sólo los usuarios autorizados lo han realizado en el tiempo. Verificar los controles automáticos establecidos en el flujo de transacciones de gastos, tales como: • Validar que no es posible realizar ordenes de compra a proveedores inactivos. • Revisión de controles presupuestales que impidan compras que superen el presupuesto establecido. • Validar que la orden de compra se genera a partir de una requisición aprobada. • Validar la existencia de flujos de aprobación de ordenes de compra a través del sistema. • Validación de controles sobre la modificación de órdenes de compra ya aprobadas. • Verificación de los controles para el recibo de mercancías y órdenes de compra como tolerancias en cantidades, concordancia en el proveedor, entre otros. • Validar que no es posible modificar campos críticos desde la orden de compra autorizadas hasta la generación de la cuenta por pagar. • Validar que no es posible radicar dos veces la misma factura. • Validar que no es posible borrar una factura ya pagada. • Verificar si automáticamente el sistema al cierre realiza una provisión de las órdenes de compra sin recibo y sin factura. • Validar que una vez se realiza el pago la factura queda cancelada en el sistema. • Verificar que no es posible realizar el pago de una misma factura más de una vez. • Validar los controles de la interfaz de gastos. • Verificar los controles en el proceso de transferencia electrónica de fondos.

283

Gastos

Pruebas principales Cruzar las órdenes de compra cumplidas con las entradas de almacén y las cuentas por pagar generadas, con el fin de identificar posibles diferencias. Verificar si existen saltos o duplicados en los documentos que intervienen en el flujo de transacciones de gastos. Validar si los proveedores que no han sido utilizados por un periodo de tiempo se revisan e inactivan. Verificar la integridad de datos de la maestra de proveedores.

284

Proceso de Negocio – Activos Fijos General ledger

Aprobación del Capex (presupuesto) Adquisición del activo

Creación de la orden interna Activo en construccion, o proyecto

1


2


3

Proceso de depreciación

Mejoras del activo, adiciones, dada de baja

Maestro de Activos fijos

Riesgos clave

Depreciación de activo fijo

Disposición del activo fijo

Adquisición del activo

Registro del activo fijo


4


5

Proceso de depreciación configurado pero no se revisan sus resultados


1


2

Administración de maestro de activos fijos

3

Configuración de variables para el proceso de depreciación

6

Activos dados de baja administrativamente pero no registrado este hecho en el sistema

285

Activos Fijos

Proveedor

Depreciación de Activos Fijos

Bajas de Activos Fijos

Comprador

Tesorería

Adquisición de Activos Fijos

Mantenimiento del Registro de Activos Fijos

Mayor General

Administración de Activos Fijos

286

Activos Fijos

Pruebas principales Validar el cálculo de la depreciación para una muestra de activos. Verificar la parametrización de las vidas útiles de los activos. Verificar que los activos totalmente depreciados o paralizados no se siguen depreciando. Validar los usuarios con acceso a las opciones críticas de activos fijos. Verificación a través de logs de auditoría que sólo los usuarios autorizados lo han realizado en el tiempo. Validar los controles de la interfaz de activos.

287

Proceso de Negocio – Inventarios Mantenimiento del Maestro de materiales

Maestro de materiales

Planeación de la producción

Administración del inventario (salidas, entradas, dadas de baja, Desperdicios)

Empaque y entrega

Planeación de la producción

Riesgos clave

Administración del inventario

Empaque y entrega

1


2


3


4


1


2

Administración de maestro de materiales


288


Proveedor

Recepción y Almacenamiento de Materias Primas Gastos

Requisición de Materiales

Mantenimiento Archivo Maestro del Inventarioz


Produción del Inventario

Manejo de Productos Terminados

Mayor General

Cliente

Embarque de Productos Terminados

Ingresos

289


Pruebas principales Validar los usuarios con acceso a las opciones críticas de inventarios. Verificación a través de logs de auditoría que sólo los usuarios autorizados lo han realizado en el tiempo. Validar los controles automáticos establecidos en el flujo de transacciones de inventarios, tales como: • Validar la existencia de monitoreo sobre los niveles mínimos de inventario. • Verificar los controles que impidan los cambios en cantidades y/o precios después de recibida la mercancía y registrada en el aplicativo. • Validar que la orden de compra se genera a partir de una requisición aprobada. • Verificar el control que exija que toda entrada de almacén tenga asociada una orden de compra. • Validar los controles entre la recepción de mercancías y la orden de compra. • Validar el adecuado uso de las tolerancias. • Validar los controles en la creación de productos (cantidad de materias primas utilizadas, cantidad de horas de mano de obra, cantidad de horas máquina). • Revisar la contabilización de la orden de producción y la adecuada parametrización de las cuentas contables que afecta. • Validar los controles en el registro de devoluciones de producto. • Verificar los controles en el registro de productos terminados. • Validar los controles establecido para la salida de mercancía de las bodegas de producto terminado. • Validar los controles automáticos en el proceso de ordenes de venta y embarque. • Validar los controles existentes en la interfaz de inventarios. • Validar como registran donaciones o muestras (costo cero) y como afecta el inventario y el costo promedio del inventario. • Validar que todas las salidas de almacén tengan asociada una requisición.

290


Pruebas principales Verificar si existen saltos o duplicados en los documentos que intervienen en el flujo de transacciones de inventarios. Verificar la correspondencia entre las ordenes de trabajo y las ordenes de producción. Obtener los informes de ventas e informes de embarques con el fin de verificar si podría existir pérdida por embarques no facturados. Identificar los cambios realizados en el maestro de inventarios, identificando: usuario, código o número del cambio. • Validar los controles de la interfaz de inventarios.

291

Proceso de Negocio – Nómina

Maestro de empleados

Reclutamiento

Liquidacion de la nómina

Registro de novedades

Retiro

Reclutamiento

Maestro de empleados

Riesgos clave

Registro de Novedades

Liquidación de la nómina

1


2


3


4


1


2

Administración de maestro de empleados

23

Configuración parámetros para procesamiento de la nómina


Retiro

292

Nóminas y Personal

Contratación de Personal

Empleado

Terminación de Contratos del Personal

Mantenimiento Archivo Maestro de la Nómina

Registro de Tiempos

Cálculo de la Nómina

Desembolsos de la Nómina

Mayor General

293

Nóminas y Personal

Pruebas principales Validar los usuarios con acceso a las opciones críticas al aplicativo de nómina y personal. Verificación a través de logs de auditoría que sólo los usuarios autorizados lo han realizado en el tiempo. Validar los controles automáticos establecidos en el flujo de transacciones de nómina y personal, tales como: • Validar que la liquidación definitiva de un empleado se calcula automáticamente en el sistema y que se tengan en cuenta todas las novedades pendientes por liquidar del empleado. • Validar si al momento de realizar la liquidación definitiva del empleado, su estado cambia de activo a inactivo. • Verificar que no sea posible reactivar un empleado retirado, si es posible verificar que el sistema cuenta con un historial que permita evidenciar las reactivaciones. • Verificar los controles del sistema sobre los topes de anticipos a empleados. • Validar los controles en el ingreso de novedades de empleados. • Verificar los controles en el proceso de liquidación de la nómina y aportes de seguridad social. • Validar la interfaz de nómina. •Verificar los controles en el proceso de pago de nómina por transferencia electrónica de fondos.

Obtención y verificación de los parámetros del sistema con los cuales se realiza automáticamente la liquidación de la nómina y la seguridad social. Validación de la integridad de los datos en la maestra de empleados.

294

Proceso de Negocio – Tesorería Administración de efectivo

Adminsitración de inversiones

Administración de créditos/ Obligaciones financieros

Adminsitración de Efectivo Administración de inversiones

Administració n de créditos / obligaciones fras.

Maestro de Maestros de bancos Proveedores y clientes

Riesgos clave 1


2


3


4


1


2

Administración de maestros de bancos, proveedores, clientes

23

Configuración parámetros para procesamiento de la valoración de inversions

4

Acceso a la banca electrónica


295

Tesorería

Préstamos, Arrendamientos Financieros Y Compras a Plazos

Administración Del Efectivo E Inversiones

Mayor General

Derivados

296

Tesorería

Pruebas principales Validar los usuarios con acceso a las opciones críticas de tesorería. Verificación a través de logs de auditoría que sólo los usuarios autorizados lo han realizado en el tiempo. Verificar que los intereses de los préstamos se calculan correctamente por el sistema teniendo en cuenta el plazo y la tasa de interés parametrizada.

297

Proceso de Negocio – Financiero Contable Administración De transacciones

Maestro de Cuentas contables Registros por las Transacciones de ciclos de negocios

Administrar El GL / plan de cuentas

Realización de cierre

Registros directos a finanzas como reversiones, ajustes, JE.

Emisión de reportes Procesamiento de cierre y consolidación

Consolidación

Riesgos clave Emisión de reportes

1


2


3


4


1


2

Administración de maestro de cuentas contables

3

Configuración de variables para el proceso de consolidación y cierre (secuencia de pasos)


298

Financiero Contable

Pruebas principales Validar los usuarios con acceso a las opciones críticas de contabilidad financiera. Verificación a través de logs de auditoría que sólo los usuarios autorizados lo han realizado en el tiempo. Verificar que no se permitan ingresar asientos de diario en periodos cerrados. Validar las interfaces con el módulo de contabilidad (nómina, gastos, activo fijos, ingresos, inventarios) Validar que no se permita el ingreso de asientos de diario descuadrados. Corroborar los medios de aprobaciones para los asientos de diarios. Validar que no se permita eliminar asientos de diario

299

Contratación de Personal

Empleado

Terminación de Contratos del Personal

Registro de Tiempos

Desembolsos de la Nómina

Mantenimiento Archivo Maestro de la Nómina

Cálculo de la Nómina

Recepción y Almacenamiento de Materias Primas

Proveedor

Gastos

Préstamos, Arrendamientos Financieros Y Compras a Plazos

Requisición de Materiales

Mayor General

Produción del Inventario


Administración Del Efectivo E Inversiones

Mantenimiento Archivo Maestro del Inventarioz Manejo de Productos Terminados

Mantenimiento Archivo Maestro de Proveedores

Administración del Inventario Tesorería

Processing Procesamiento Accounts de Cuentas Payable por Pagar

Compras

Activos Fijos

Cliente

Procesamiento de Gastos

Embarque de Productos Terminados

Proveedor

Ingresos

Derivados

4. METODOLOGÍA PARA AUDITORÍA DE TECNOLOGÍA BASADA EN RIESGOS Metodología Deloitte & Touche

301

Metodología •

La Metodología de Deloitte denominada Information & Technology (IT) Risk Management Framework and Diagnostic – ITRM Framework, está construida usando diferentes disciplinas, las mismas que combinadas proveen las bases de una metodología robusta.

Fuente: Deloitte

Metodología •

La Metodología ITRM se basa en el Método de Auditoría Interna el cual incorpora Normas para la Práctica Profesional que son emitidos por el Instituto de Auditores Internos (el "Estandar IIA").

La metodología ITRM adopta los conceptos de la Administración de Riesgos Empresariales (ERM) con el objetivo de desarrollar un plan de auditoría interna basado en los riesgos de TI. De igual forma, la metodología crea un vínculo de creación de valor, alcanzando los objetivos de consultoría y aseguramiento de la función de Auditoría Interna.

Fuente: Deloitte

Metodología Fase 1 Obtener el conocimiento y realizar entrevistas

Fase 2 Definir Universo de Auditoría

Fase 3 Desarrollar y aplicar el modelo de riesgo

Fase 4 Priorizar el Universo de Auditoría

Fase 5 Desarrollar plan de auditoria con enfoque basado en riesgos

Los beneficios clave del enfoque de Deloitte son: • Asegurar una comprensión clara desde el principio, incluyendo los objetivos del proyecto y los

resultados previstos • Integración con la evaluación de riesgos del negocio • Creación de un cronograma y etapas para facilitar la gestión de proyectos • Flexibilidad para adaptarse a las preocupaciones y requisitos de la compañía

Fuente: Deloitte

Fase 1 – Obtener Entendimiento / Entrevistas Fase 1 Obtener un entendimiento y realizar entrevistas

Fase 2 Definir Universo de Auditoría


Fase 4 Priorizar el Universo de la Auditoría

Fase 5 Desarrollar un plan de auditoria con un enfoque basado en riesgos

Principales actividades y entregables • Requerimientos y entrevistas: - Planes estratégicos y anuales; presupuestos, planes operativos, etc. - Políticas y procedimientos; organigramas - Lista de proyectos - Lista de aplicación y sistemas de documentación, diagramas de redes, etc. - Informes de Auditoría Interna, - Resultados Anteriores de la evaluación de riesgos - Identificar al personal a ser entrevistado • Obtener una comprensión de las actuales estrategias de negocio, los objetivos, retos y preocupaciones • Realizar comunicación del proyecto inicial y ejecutar las entrevistas

Fuente: Deloitte

Fase 2 – Definir Universo de Auditoría Fase 1

Fase 2

Obtener un entendimiento y realizar entrevistas

• • •

Definir Universo de Auditoría




Principales actividades y entregables Desarrollar el universo de auditoría Dividir los procesos de TI en fases. Se podría utilizar los procesos de COBIT ® como su universo de auditoría: - Planificación y Organización - Adquisición e Implementación - Entrega y Soporte - Seguimiento

Fuente: Deloitte

Fase 3 – Desarrollar y aplicar el modelo de riesgo Fase 1

Fase 2



• • • •

Fase 3

Desarrollar y aplicar el modelo de riesgo

Fase 4

Priorizar el Universo de la Auditoría


Principales actividades y entregables Desarrollar el modelo de riesgo - Determinar los factores de riesgo - Peso de los factores de riesgo Aplicar el modelo de riesgo al universo de auditoría Identificar las áreas de auditoría recomendadas

Fuente: Deloitte

Fase 3 – Desarrollar y aplicar el modelo de riesgo Desarrollar el modelo de riesgo Existen dos dimensiones clave para determinar los riesgos, el impacto potencial y la probabilidad de ocurrencia - deben tenerse en cuenta al desarrollar y clasificar el modelo de riesgo. El modelo de riesgo es una herramienta para ayudarle a evaluar y cuantificar el riesgo y por lo general incluyen los factores de riesgo, el peso de cada factor, la puntuación de riesgo global, y una determinación de la categoría de riesgo (es decir, alta, media, baja).

Alto

Riesgo Alto

Impacto de

Riesgo

Ocurrencia “I”

Medio

Riesgo Bajo

Bajo

Alto Probabilidad de ocurrencia “L”

Fuente: Deloitte

Fase 3 – Desarrollar y aplicar el modelo de riesgo Desarrollar el modelo de riesgo

Evaluaciones de riesgos de TI se llevan a cabo para identificar las áreas de mayor riesgo relativo a TI de una organización. La evaluación del riesgo se realiza basado en factores de riesgo, que pueden incluir: Factores de riesgo organizacionales:

Factores de riesgo COBIT®:

Consideraciones sobre el Ambiente de Control

Eficacia

Importancia estratégica; Materialidad

Eficiencia

Importancias de organización, de procesos de negocio o cambios en los sistemas de información

Confidencialidad

Complejidad y Madurez de Procesos y Sistemas

Disponibilidad

Calidad y Rendimiento del personal, rotación

Complejidad de la tecnología

Contabilidad financiera y presentación de informes

Cumplimiento

Rendimiento histórico

Fiabilidad de la información

Integridad

El uso de las tecnologías emergentes Ambiente regulatorio y legal Ambiente externo del negocio, impacto en el cliente

Fuente: Deloitte

Fase 4 – Priorizar el Universo de la Auditoría Fase 1

Fase 2



• • • • •



Fase 5 Desarrollar un plan de auditoria con un enfoque basado en

Principales actividades y entregables Finalizar el universo de auditoría de TI Analizar clasificación y las puntuaciones de los riesgos Identificar las áreas de auditoría recomendadas Proponer el plan de auditoría interna de TI (1 año, 3 años)

Fuente: Deloitte

Fase 4 – Priorizar el Universo de la Auditoría Segmento auditable

Impacto

Probabilidad

Riesgo

100

100

Bajo

170

160

Medio

250

260

Alto

Seguridad de la empresa

250

240

Alto

Recuperación de desastres

130

160

Medio

Infraestructura

70

60

Bajo

Recursos de Información Gobierno TI Estrategia y Planeación TI Programa de Gestión Arquitectura Operaciones Aplicaciones Soporte

Fuente: Deloitte

Fase 4 – Priorizar el Universo de la Auditoría Análisis de riesgos Enterprise Security

300

Applications

Impacto

Program Management

Gobierno TI

Disaster Recovery

Programa de Gestión

150

Aplicaciones

Infrastructure

Seguridad de la empresa Recuperación de desastres 0

Infraestructura 0

150

300

Probabilidad

Fuente: Deloitte

Fase 5 – Desarrollar plan de auditoría Fase 1

Fase 2



• •

• • •




Principales actividades y entregables Creación de un plan de auditoría basado en los resultados: - Dar prioridad a los recursos - Integrar el plan de auditoría con el financiero o en el plan de auditoría operacional - Realizar la determinación del alcance y la planificación a nivel de tarea - Presentar el Plan de Auditoría Interna al comité de Auditoría Ejecutar el plan de auditoría Elaborar un Informe Detallado con las principales hallazgos identificados y sus riesgos asociados Elaborar un Informe Ejecutivo con el resumen de los principales hallazgos

Fuente: Deloitte

MUCHAS GRACIAS

Copyright © 2013 Ing. Raúl González Carrión All rights reserved.

Auditoria de Tecnología Basada en Riesgos 160813 [ESTUDIANTES]x

Recommend Documents