AUDITORÍA DE SISTEMAS
Gonzalo Martin Valdivia Benites
Auditoría de sistemas. Manual Autoformativo Gonzalo Martin Valdivia Benites
Primera edición Huancayo, mayo de 2016 De esta edición © Universidad Continental, Modalidad Virtual Av. San Carlos 1980, Huancayo-Perú Teléfono: (51 64) 481-430 anexo 7361 Correo:
[email protected] http://virtual.ucontinental.edu.pe/ Dirección: Emma Barrios Ipenza Edición: Eliana Gallardo Echenique Asistente de edición: Andrid Poma Acevedo Asesoría didáctica: Karine Bernal Corrección de estilo: Corina Delgado Morales Diseño y diagramación: Francisco Rosales Guerra Todos los derechos reservados. Cada autor es responsable del contenido de su propio texto. Este manual autoformativo no puede ser reproducido, total ni parcialmente, ni registrado en o transmitido por un sistema de recuperación de información, en ninguna forma ni por ningún medio sea mecánico, fotoquímico, electrónico, magnético, electro-óptico, por fotocopia, o cualquier otro medio, sin el permiso previo de la Universidad Continental.
ÍNDICE INTRODUCCIÓN
7
COMPETENCIA DE LA ASIGNATURA
8
UNIDADES DIDACTICAS
8
TIEMPO MINIMO DE ESTUDIO
8
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
9
DIAGRAMA DE PRESENTACIÓN DE LA UNIDAD I
9
ORGANIZACIÓN DE LOS APRENDIZAJES
9
TEMA N.° 1: VISIÓN DE LA AUDITORIA DE SISTEMAS
11
INTRODUCCIÓN
11
1
Visión de la Auditoria
11
2 Estándares de ISACA
13
El3 riesgo como elemento clave de la Auditoria de Sistemas
15
TEMA N.° 2: EL PROCESO DE LA AUDITORIA DE SISTEMAS
17
INTRODUCCIÓN
17
Planeamiento1 de la Auditoria
17
2 Programa de Auditoria.
18
INTRODUCCIÓN
23
1 Formulación de los Hallazgos de Auditoria
23
2
Formulación de las Recomendaciones
26
3
Formulación del Inorme de Auditoria
26
TEMA N.° 4: MARCOS DE REFERENCIA DE AUDITORIA DE SISTEMAS
33
INTRODUCCIÓN
33
Regulaciones Internas
1
33
Regulaciones externas
2
35
ACTIVIDAD N.° 1
42
CONTROL DE LECTURA Nº 1
42
GLOSARIO DE LA UNIDAD I
43
BIBLIOGRAFÍA DE LA UNIDAD I
43
AUTOEVALUACIÓN DE LA UNIDAD I
44
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
47
DIAGRAMA DE PRESENTACIÓN DE LA UNIDAD II
47
ORGANIZACIÓN DE LOS APRENDIZAJES
47
n
TEMA N.° 1: GOBIERNO Y GESTIÓN DE T.I. INTRODUCCIÓN
48 48
1 Corporativo y Gobierno de TI Gobierno
48
2 Gerenciales de Gestión de TI Practicas
49
3 Auditoria al Gobierno y a la Gestión de TI
58
LECTURA SELECCIONADA N.° 1:
60
TEMA N.° 2: CONTINUIDAD DE NEGOCIO Y RECUPERACIÓN DE DESASTRES INTRODUCCIÓN
61 61
Gestión1 de la Continuidad de Negocio
61
2 Planeación a la Continuidad de Negocio y Recuperación de Desastres
63
3 a la Continuidad de negocio Auditoria
67
LECTURA SELECCIONADA N.° 2
68
ACTIVIDAD N.° 2
68
PARTICIPA EN EL FORO DE DISCUSIÓN SOBRE LAS “PRÁCTICAS GERENCIALES EN EL ÁREA DE SISTEMAS”.
68
TAREA ACADEMICA N.° 1
68
GLOSARIO DE LA UNIDAD II
69
BIBLIOGRAFÍA DE LA UNIDAD II
69
UNIDAD III: AUDITORÍA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE
73
DIAGRAMA DE PRESENTACIÓN DE LA UNIDAD III
73
ORGANIZACIÓN DE LOS APRENDIZAJES
73
TEMA N.° 1: ETAPAS DEL CICLO DE VIDA INTRODUCCIÓN
74 74
Ciclo 1de Vida de Desarrollo de Sofware
74
2 de Entrada, procesamiento y Salida Controles
78
TEMA N.° 2: MANTENIMIENTO DE SISTEMAS INTRODUCCIÓN
81 81
Mantenimiento de1 Sistemas
81
2 Procedimiento de Control de Cambios.
81
3 Implantación de cambios 4 5 Cambios de emergencia. 6 Razones por las que suceden los cambios no autorizados
82 82 82 82
LECTURA SELECCIONADA N.° 1:
83
ACTIVIDAD N.° 3
83
TEMA N.° 3: APLICACIONES DE NEGOCIO INTRODUCCIÓN
84 84
Aplicaciones1 de Negocio Verticales
84
TEMA N.° 4: AUDITORIA AL CICLO DE VIDA
88
INTRODUCCIÓN Auditoria al1 Ciclo de Vida
88 88
2 al Mantenimiento de Sistemas Auditoria
90
LECTURA SELECCIONADA N.° 2:
90
CONTROL DE LECTURA Nº 2
91
GLOSARIO DE LA UNIDAD III
91
BIBLIOGRAFÍA DE LA UNIDAD III
91
AUTOEVALUACIÓN DE LA UNIDAD III
92
UNIDAD IV: AUDITORÍA A LA SEGURIDAD DE LA INFORMACIÓN
95
DIAGRAMA DE PRESENTACIÓN DE LA UNIDAD IV
95
ORGANIZACIÓN DE LOS APRENDIZAJES
95
TEMA N.° 1: SEGURIDAD DE LA INFORMACIÓN INTRODUCCIÓN
96 96
Seguridad de1la Inormación Seguridad Inormática
96
2
98
TEMA N.° 2: CONTROLES DE SEGURIDAD I INTRODUCCIÓN
99 99
Gestión de Accesos 1
99
2
102
LECTURA SELECCIONADA Nº 1: ACTIVIDAD N.° 4
104 104
TEMA N.° 3: CONTROLES DE SEGURIDAD II INTRODUCCIÓN
105 105
1 Seguridad en Internet
105
2 Seguridad del Cloud
3.
106 Seguridad de Móviles.
108
TEMA N.° 4: AUDITORIA A LA SEGURIDAD DE LA INFORMACIÓN INTRODUCCIÓN 1 Auditoria a la Seguridad de la Inormación 2 a los controles de Seguridad. Auditoria
110 110 110 110
LECTURA SELECCIONADA Nº 2:
112
TAREA ACADEMICA Nº 2
112
GLOSARIO DE LA UNIDAD IV
112
BIBLIOGRAFÍA DE LA UNIDAD IV
112
AUTOEVALUACIÓN DE LA UNIDAD IV
113
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
INTRODUCCIÓN
ienvenido al curso de Auditoria de Sistemas! En este curso Ud. aprenderá los conceptos y las
B
técnicas más relevantes para realizar Auditorías de Sistemas. La Auditoria de Sistemas es una de las ramas de Tecnologías de Información más importantes, retadoras y excitantes y al mismo tiempo es una de las ramas menos conocidas y también ¿por qué no decirlo?, la Auditoria de Sistemas es una rama muy rentable. La asignatura sigue las mejores prácticas de la Information Systems Audit and Control Association(ISACA) que es la institución mundial más importante en Auditoria de Sistemas. La asignatura está estructurado en 4 Unidades: La primera Unidad está enfocada en el proceso de Auditoria. En este parte Ud. aprenderá los conceptos básicos y el proceso a seguir para realizar Auditorías de Sistemas. También Ud. aprenderá a redactar Hallazgos de Auditoria así como informes de Auditoria, donde expresa su opinión con respecto a una determinada materia o situación. L finalizar e esta Unidad revisaremos los principales Marcos de referencia de auditoria tanto nacionales como internacionales que utilizan los Auditores en la ejecución de su Auditoria. En la Unidad II revisaremos la Auditoria al Gobierno y Gestión de TI. En esta parte revisaremos el Gobierno Corporativo y el Gobierno de TI, las diferencias entre
Gobierno y gestión de TI, las Practicas Gerenciales de Gestión de TI y la forma de ejecución de Auditorias al Gobierno y a la Gestión de TI. Un punto importante a recalcar en esta Unidad es que aprenderemos a Auditar los procesos de Continuidad de Negocio y Recuperación de Desastres, como un asunto vital para la supervivencia de las organizaciones que cada dia dependen más de las T.I. En la Unidad III tendremos la Auditoria al Ciclo de Vida de desarrollo de Software. Aquí revisaremos las Etapas del ciclo de vida de Desarrollo de Software, así como los controles que todo software debe implementar. Por otro lado estudiaremos los procedimientos de Mantenimiento de Sistemas y revisaremos algunas aplicaciones de Negocio específicas que los Auditores suelen revisar. Al finalizar esta Unidad revisaremos la Auditoria al Ciclo de Vida de Desarrollo de Software y al Mantenimiento de Software. En la última Unidad nos enfocaremos en la Auditoria a la Seguridad de la Información. Revisaremos las técnicas y procedimientos de Seguridad de la Información y Seguridad Informática, enfocándonos en temas como encriptación, control de acceso, seguridad de Internet, Cloud, Móviles, entre otros. Finalizaremos esta Unidad con la Auditoria a la seguridad de la información Espero que el curso sea de su provecho y que el contenido aporte su granito de arena para que lo ayude a Ud. en un profesional más completo. ¿Y por qué no? Este curso puede descubrir que Ud. podría ser un excelente Auditor de Sistemas.
7
8
PRESENTACIÓN DE LA ASIGNATURA
COMPETENCIA DE LA ASIGNATURA
Realizar de manera efectiva procesos de auditoría de sistemas a la organización, procesos y soluciones tecnológicas existentes en las áreas de Sistemas, a través de la identificación de los riesgos asociados a las tecnologías de información en las organizaciones de hoy; aplicando los principales estándares, normas, metodologías y mejores prácticas a nivel mundial en auditoria de sistemas.
UNIDADES DIDACTICAS U N I D AI D
Introducción a la Auditoria de Sistemas
U N I D AI ID
Auditoria al Gobierno y Gestión de TI
U N I D AI IDI
Auditoria al Ciclo de Vida de desarrollo de Software
U N I D AI VD
Auditoria a la seguridad de la información
TIEMPO MINIMO DE ESTUDIO U N I D AI D
1era. Semana y 2da. Semana 16 horas
U N I D AI ID
3era. Semana y 4ta. Semana 16 horas
U N I D AI IDI
5ta. Semana y 6ta. Semana 16 horas
U N I D AI VD
7ma. Semana y 8va. Semana 16 horas
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
DIAGRAMA DE PRESENTACIÓN DE LA UNIDAD I
CONTENIDOS
EJEMPLOS
AUTOEVALUACIÓN
ACTIVIDADES
BIBLIOGRAFÍA
ORGANIZACIÓN DE LOS APRENDIZAJES C O N O C I MI EN TO S
Video de presentación de la asignatura Unidad I: Introducción a la Auditoria de Sistemas 1° Videoclase (Video conferencia) Tema N.° 1: Tema 1 1. Visión de la Auditoria 2. Estándares de ISACA 3. El riesgo como elemento clave de la Auditoria de Sistemas Tema N.° 2: El proceso de Auditoria de Sistemas 1. Planeamiento de Auditoria 2. Programa de Auditoria Lectura seleccionada 1 Título: Auditoria de Sistemas. Disponible en: http://www.gerencie.com/auditoria-de-sistemas.html
P R O C ED I MI EN TO S
1. Infiere los procedimientos de auditoría a aplicar. 2. Participa en la definición de los controles para minimizar riesgos. 3. Identifica las diferentes actividades en la ejecución de la Auditoria 4. Identifica las diferentes actividades en la planificación de la Auditoria 5. Identifica las diferentes ejecución de la Auditoriaactividades en la Actividad N.° 1 Participan en el Foro de discusión sobre “Los riesgos srcinados por el uso de las Tecnologías de Información en las organizaciones”.
A C T I TU D E S
1. Valora la importancia de la ejecución de la auditoria de sistemas. 2. Se auto valora por su aprendizaje de las técnicas de auditoria de siste-mas. 3. Asume el compro-miso de revisar los contenidos del manual. 4. Valora la importancia de la auditoria de sistemas para el mejora-miento de una empresa y para las actividades o procesos a realizar. 5. Participa activa-mente en el desarrollo de las actividades de la asignatura.
9
10
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
2° Videoclase Tema N.° 3: Hallazgos y observaciones de Auditoria 1. Formulación de los hallazgos de Auditoria 2. Formulación de recomendaciones para minimizar los riesgos identificados 3. Formulación del Informe de Auditoria Tema N.° 4: Marcos de referencia de auditoria 1. Marcos Internacionales: CobiT, Familia ISO 27001. 2. Marcos Nacionales: Contraloría General de la República, Superintendencia de Banca y Seguros. Lectura seleccionada 2 Título: CobiT5-Introduction-Spanish. Disponible en: www.isaca.org/COBIT/Documents/COBIT5-Introduction-Spanish.ppt Autoevaluación Nº 1
1. Identifica el riesgo y escribe hallazgos de auditoria. 2. Analiza y utiliza lo explicado en un caso práctico. 3. Identifica los estándares, las directrices y las prácticas relacionadas. 4. Identifica leyes, regulaciones y están-dares relevantes. 5. Utiliza los marcos de referencia en los hallazgos de auditoria. Control de Lectura Nº 1 Formula Observaciones de Auditoria del caso “Auditoria de Sistemas en una empresa regional”.
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
TEMA N.° 1: VISIÓN DE LA AUDITORIA DE SISTEMAS
INTRODUCCIÓN Este tema está preparado para que tengas tu primer contacto con la Auditoria de Sistemas. En este primer tema tocaremos los puntos más importantes de la Auditoria de Sistemas. 1
VISIÓN DE LA AUDITORIA 1.1 ¿Qué es la Auditoria? La Auditoria es un proceso sistemático de evaluación post-mortem y de formación de opinión sobre una determinada materia o situación. Para nuestro caso sobre una materia o situación relacionada a Tecnología de Información tal como un Sistema Informático, una Base de datos, una Infraestructura tecnológica, unos Servidores, la gestión del Gerente de TI, un proceso de atención de soporte técnico a usuarios, etc. Este proceso es realizado por los Auditores quienes son profesionales que se encargan de realizar la evaluación y en función su evaluación forma una opinión sobre dicha materia o situación. Aquí vale la pena mencionar que las auditorias también pueden ser previas o durante la ejecución de una determinada materia o situación. 1.2 Tipos de Auditoria Existen muchos tipos de Auditoria. Entre las principales tenemos: • Financieras. En estas Auditorias el Auditor forma una opinión si los estados financieros (balance general, de una
empresa reflejan la realidad financiera de la empresa. • Operacionales. En estas Auditorias Operacionales se forma una opinión de la efectividad de los controles operati-
vos de los procesos de una compañía. Por ejemplo compras, ventas, producción, etc. • Cumplimiento. En las Auditorias de Cumplimiento, se forma una opinión de si una empresa cumple con las leyes
y regulaciones que está obligada a cumplir. • Sistemas. En las Auditorias de Sistemas, el Auditor forma una opinión de la efectividad de los controles tecnológi-
cos para minimizar los riesgos por el uso de la tecnología. Las Auditorias Financieras se realizan al menos una vez al año. Muchas entidades reguladoras exigen que se realicen Auditorias Financieras. Por ejemplo la Superintendencia de Mercado de Valores (SMV) exige que se realicen auditorias financieras a las compañías que cotizan en la Bolsa. Asimismo la Contraloría General de la Republica (CGR) exige que las Entidades del Estado realicen una auditoria una vez al año. La Superintendencia de Banca, Seguros y AFP (SBS) audita que los Bancos e Instituciones Financieras al menos una vez al año. En el Perú, es frecuente encontrar las auditorias de Sistemas como parte de las Auditorias Financieras. Las Auditorias de Sistemas no son tan frecuentes y normalmente son realizadas cuando hay algún problema en el área de TI, o cuando un nuevo Gerente de TI la solicita para tomar conocimiento de la situación que recibe. 1.3 Auditoria Interna vs. Auditoria Externa. Las Auditorias pueden ser internas o externas en función de quien realiza la Auditoria. Así tenemos: • Auditoria Interna. Una Auditoria es considerada Interna cuando el Auditor o equipo de Auditoria labora dentro de
la misma compañía. En una Auditoria Interna se tiene la ventaja del nivel de profundidad de la auditoria. Dado que
11
12
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
los Auditores son internos tienen la ventaja de conocer el negocio y pueden realizar auditorías más detalladas. Una desventaja podría ser que en caso hubiese algún tipo de relación entre el Auditor y la materia auditada, el Auditor perdería su independencia. En Perú los Auditores internos laboran en el área de Auditoria Interna. En las Entidades del Estado laboran en las Oficinas de Control Interno (OCI). • Auditoria Externa. En este caso, el Auditor o equipo de Auditoria pertenece a una compañía externa que tiene una
experiencia amplia por haber auditado muchas compañías de diversos rubros. Como una desventaja se tiene que la Auditoria Externa podría ser menos detallada ya que normalmente cuentan con un periodo de tiempo reducido (semanas o pocos meses) para realizar la revisión. 1.4 Las Big Four. Cuando una empresa requiere realizar una Auditoria Externa, es muy frecuente que las compañías contraten a una de las llamadas Big Four para que realicen la Auditoria. Se llama Big Four al conjunto de las 4 compañías internacionales más prestigiosas en el campo de la auditoria, tal como se muestra en el gráfico 1.
Figura 1. Las Big Four.
Si te interesa saber más de estas compañías, puedes obtener más información en las siguientes direcciones: • Deloitte: http://www2.deloitte.com/pe/es/services/auditoria.html?icid=top_auditoria • Price Waterhouse Coopers: • http://www.pwc.com/pe/es/servicios/assurance.html • Ernst & Young:http://www.ey.com/PE/es/Services/Assurance • KPMG: http://www.kpmg.com/pe/es/servicios/audit/paginas/default.aspx
1.5 ¿Qué es la Auditoria de Sistemas? La Auditoria de Sistemas se refiere a la Auditoria de materias o situaciones relacionadas a las Tecnologías de Información. El auditor de Sistemas tiene el “negocio” de encontrar riesgos. Veamos un ejemplo: Imagina que te contratan como Auditor de Sistemas de una compañía y al hacer la revisión de un Servidor de Base de Datos (todavía no sabes cómo se hace, no te preocupes aun por eso), encuentras que dicho Servidor no cuenta con Antivirus. También encuentras que la contraseña del super usuario de la Base de datos no ha sido cambiada desde hace 3 años y encuentras que al Sistema Operativo nunca se le han instalado parches del fabricante (Imagina que es un Windows Server). ¿Estas 3 situaciones que encontraste pueden srcinar riesgos? ¿Se cuenta con los controles adecuados para minimizar los riesgos? ¿O todo lo contrario? ¿Qué opinión te vas formando de esta situación? Ese es el trabajo del Auditor de Sistemas: encontrar situaciones que srcinan riesgos.
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
2
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
ESTÁNDARES DE ISACA
2.1 ISACA Los Auditores de Sistemas están agrupados en gremios profesionales. A nivel mundial una de las instituciones más prestigiosas es la Information System Audit and Control Association (ISACA). ISACA es una institución con Sede en Chicago, Estados Unidos, que agrupa a los profesionales de auditoria, control, riesgo y gobierno de TI. Te invito a que le des un vistazo a esta institución. Puedes encontrar más información en http://www.isaca.org Asimismo ISACA es uno de las entidades certificadoras de profesionales más importantes del mundo. Actualmente, ISACA ofrece 4 certificaciones, las cuales son: • CISA (Certified Information Security Auditor) • CISM (Certified Information Security Manager) • CGEIT (Certified in the Governance of Enterprise IT) • CRISC (Certified in Risk and Information Systems Control)
Para Auditoria de Sistemas, evidentemente la Certificación que nos sirve es la CISA. Si a lo largo del curso, descubres que la Auditoria de Sistemas te interesa y ves que tienes competencias para identificar riesgos, entonces tu podrías ser un futuro Auditor CISA. En la figura adjunta te muestro como es un certificado CISA:
Figura 2. Muestra de un Certificado CISA.
Encontraras más información de la certificación CISA en: http://www.isaca.org/Certification/CISA-Certified-Information-Systems-Auditor/Pages/default.aspx 2.2 Estándares de ISACA ISACA cuenta con un framework de Auditoria de Sistemas denominado “A Professional practices Framework for IS Audit/Assurance”, más conocido como el framework ITAF. A continuación, vamos a detallar los estándares más relevantes para nuestro curso. • Estándar 1003 Independencia profesional. El estándar indica textualmente que: “Los profesionales de auditoría y ase-
guramiento de SI deben ser independientes y objetivos, tanto en actitud como en apariencia, en todos los asuntos relacionados con las asignaciones de auditoría y aseguramiento”. Esto significa que no debe haber ninguna relación entre al Auditor y la materia que se está auditando. Por ejemplo, imagínate que estas auditando una compañía y tu esposa trabaja para dicha compañía. En este caso podría afectarse tu independencia. Si encuentras muchos riesgos, el que pueda estar en riesgo eres tu!. Espérate al llegar a casa!
13
14
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
• Estándar 1006 Competencia. “Los profesionales de auditoría y aseguramiento de SI, junto con otras personas que ayudan en
la asignación, deben poseer las habilidades y la competencia adecuadas para realizar las asignaciones de auditoría y aseguramiento de SI y ser profesionalmente aptos para realizar el trabajo requerido”. Por ejemplo no podemos hacer una Auditoria de Sistemas a un cajero automático sino tenemos la mínima idea de cómo funciona por dentro. En este caso no somos competentes para realizar la evaluación. • Estándar 1201 Evaluación de riesgo en planificación: “La función de auditoría y aseguramiento de SI debe utilizar un enfo-
que de evaluación de riesgo adecuado y metodología de respaldo para desarrollar el plan completo de auditoría de SI y determinar las prioridades para la asignación efectiva de los recursos de auditoría de SI ”. Como dijimos el riesgo es primordial para el Auditor de Sistemas. En función del riesgo se planifica que auditar y con qué prioridad. • Estándar 1204 Materialidad. “Los profesionales de auditoría y aseguramiento de SI deben considerar las debilidades potenciales
o ausencias de controles mientras planifican una asignación y si esas debilidades o ausencias de controles pudieran resultar en una deficiencia significativa o una debilidad material ”.
• Estándar 1205 Evidencia: “Los profesionales de auditoría y aseguramiento de SI deben obtener evidencias suficientes y apropia-
das para llegar a conclusiones razonables sobre las cuales basar los resultados de la auditoria”. El Auditor siempre se respalda con evidencias, como por ejemplo fotos, videos, actas, documentación, pantallazos, etc. • Estándar 1207 irregularidad y Actos irregulares: “Los profesionales de auditoría y aseguramiento de SI deben considerar el
riesgo de irregularidades y actos ilegales durante la auditoria. Los profesionales de auditoría y aseguramiento de SI deben mantener una actitud de escepticismo profesional durante la asignación. Los profesionales de auditoría y aseguramiento de SI deben documentar y comunicar, de manera oportuna, cualquier acto ilegal o irregularidad material a la parte apropiada”. Esto significa que si encontramos una irregularidad o un acto ilegal, estamos en la obligación de obtener la evidencia correspondiente e informarlo, no podemos ignorarlo. • Estándar 1401 Reportes: “Los profesionales de auditoría y aseguramiento de SI deben proporcionar un reporte para comunicar
los resultados al concluir la auditoria, que incluye: • Identificación de la empresa, los destinatarios previstos y cualquier restricción sobre el contenido y la circulación • Alcance, objetivos de la asignación, período de cobertura y la naturaleza, los plazos y el alcance del trabajo realizado • Hallazgos, conclusiones y recomendaciones de la auditoría • Cualquier calificación o limitación dentro del alcance que el profesional de auditoría y aseguramiento de SI tenga con respecto a
la asignación • Firma, fecha y distribución según los términos del estatuto de la función de auditoría o carta de asignación de auditoría”. Como
ves, este estándar nos indica caramente cuales son los entregables de la Auditoria de Sistemas. • Estándar 1402 Actividades de Seguimiento: “Los profesionales de auditoría y aseguramiento de SI deben monitorear infor-
mación relevante para concluir si la dirección ha planeado/tomado la acción oportuna y apropiada para abordar los hallazgos y las recomendaciones de la auditoría reportados”. El seguimiento se refiere a revisar que los auditados hayan ejecutado las recomendaciones de la Auditoria de Sistemas del periodo anterior.
Estos estándares no son los únicos. Una lista completa de los estándares de Auditoria, los puedes encontrar en: http://www.isaca.org/Knowledge-Center/ITAF-IS-Assurance-Audit-/IS-Audit-and-Assurance/Pages/Standards-for-IS-Audit-and-Assurance-Spanish.aspx Asimismo, si deseas profundizar en el framework ITAF (en ingles) lo puedes encontrar en: http://www.isaca.org/Knowledge-Center/Research/Documents/ITAF-3rd-Edition_fmk_Eng_1014.pdf
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
3
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
EL RIESGO COMO ELEMENTO CLAVE DE LA AUDITORIA DE SISTEMAS
3.1 Identificar el riesgo En la sección 1.5 vimos un ejemplo de 3 situaciones que srcinan riesgo. Ahora imagina que haces la revisión y no encuentras situaciones de riesgo. Es decir, haces la Auditoria y se “te escapan” estos puntos. Es decir no encuentras las situaciones que srcinan los riesgos (que en el ejemplo son muy evidentes). ¿Qué opinión te formarías? Se dice que Auditor de Sistemas que no encuentra riesgos, no es Auditor de Sistemas. Por eso es muy importante que aprendamos a identificar los riesgos. Y lo primero es que debes tener muy presente lo que es el riesgo. Veamos la definición de la Norma ISO 13335. “El riesgo es la probabilidad que una amenaza se aproveche de una vulnerabilidad y nos genera un daño”. Aquí la amenaza es cualquier cosa que tenga el potencial de hacer daño. La vulnerabilidad es cualquier deficiencia que se tenga. El daño es el impacto negativo que tenemos si la amenaza se aprovecha de la(s) vulnerabilidad(es). El daño pude ser económico, patrimonial, de imagen, etc. Volvamos a las tres situaciones identificadas del primer ejemplo. Tenemos que: • El Servidor no cuenta con Antivirus. • La contraseña del super usuario de la Base de datos no ha sido cambiada desde hace 3 años y • Al Sistema Operativo nunca se le han instalado parches del fabricante
Descompongamos la primera situación en función de la definición del riesgo: ¿Cuál sería la amenaza? Es evidente que lo que nos puede hace daño aquí es el malware. ¿Cuál sería la vulnerabilidad? La propia inexistencia del Antivirus es la vulnerabilidad. ¿Cuál sería el daño? El ingreso de malware podría srcinar la inutilización del servidor, el robo de información del servidor, entre otros. Ahora, veamos la segunda situación: ¿Cuál sería la amenaza? Cualquier persona que tenga acceso al servidor y que conozca o adivine la contraseña es considerada una amenaza. ¿Cuál sería la vulnerabilidad? Mantener la misma contraseña es la vulnerabilidad. ¿Cuál sería el daño? El robo o la modificación de la información contenida en el servidor. Finalmente, veamos la tercera situación: ¿Cuál sería la amenaza? El malware o los criminales informáticos son las amenazas. ¿Cuál sería la vulnerabilidad? El no actualizar los parches del Sistema Operativo ¿Cuál sería el daño? El robo o la modificación de la información contenida en el servidor. Como vez, en las 3 situaciones se encuentra la amenaza, la vulnerabilidad y el daño. Los Auditores de Sistemas se enfocan en identificar los riesgos.
15
16
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
3.2 ¿Qué se hace con el riesgo? Una vez que el riesgo ha sido identificado, el riesgo debe ser tratado. El término “tratamiento del riesgo” quiere decir que hay que hacer algo con ese riesgo. El tratamiento del riesgo le corresponde al Auditado. El auditado tiene 4 opciones para trata el riesgo: • Reducirlo. Cuando se decide reducir (o minimizar) el riesgo, se tiene que hacer algo para que ese riesgo se reduzca.
Por ejemplo mantener actualizado un Sistema Operativo actualizado con los parches que emite el fabricante. • Transferirlo. En algunas situaciones es posible transferir el riesgo a un tercero. Por ejemplo tercerizar un proyecto
de desarrollo de software a un tercero, en lugar de hacerlo nosotros mismos. Otro ejemplo podría ser contratar una póliza de seguros. • Aceptarlo. Aceptar un riesgo es lo mismo que no hacer nada. Simplemente, se “le acepta”. Ejemplo de esto es seguir
sin Antivirus a pesar de que se encontró que un computador esta sin Antivirus. • Cesar la actividad que da srcen al riesgo. A esta opción algunos autores le llaman “eliminar” el riesgo. Por ejemplo,
si no se puede instalar un Antivirus (cosa poco probable) siempre queda la alternativa de apagar el computador. Al apagar el computador, estoy cesando la actividad que da srcen al riesgo. Pero esta acción ha tenido un costo muy alto. Si bien es cierto que “elimine” el riesgo de infección, también inhabilite el uso del computador. 3.3 Controles Cuando se decide reducir el riesgo, entonces se requiere de un control que haga ese trabajo. Un control en su término más amplio es cualquier cosa que minimiza un riesgo. Por ejm. escribir un procedimiento, implementar un firewall, instalar un antivirus, ejecutar un respaldo (backup), etc. Para minimizar los riesgos se pueden implementar varios tipos de controles: • Preventivos. Siempre se debe preferir este tipo de controles. Su función es detectar problemas antes de que estos
ocurran. Por ejemplo una pantalla de usuario y contraseña de acceso a un Sistema o la encriptación de datos sensibles. • Detectivos. Estos controles como su nombre lo indica detectan y reportan la ocurrencia de un incidente, error o
situación. Por ejemplo un log de auditoria, una alarma o una función hash. • Correctivos. Los controles correctivos minimizan el impacto de una amenaza así como corrigen los problemas des-
cubiertos por los controles detectivos. Por ejemplo un respaldo (backup) o un plan de contingencias. El auditor como parte de su trabajo debe recomendar los mejores controles para reducir el riesgo que identificó. A lo largo del curso te presentaré muchos ejemplos de las diferentes situaciones que evalúan los Auditores de Sistemas y los riesgos que se identifican.
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
TEMA N.° 2: EL PROCESO DE LA AUDITORIA DE SISTEMAS
INTRODUCCIÓN Este tema está enfocado en como efectuar una Auditoria de Sistemas. No se trata de auditar lo primero que veamos. Se trata de Auditar en función al riesgo y para ello es esencial la planificación y luego de ella, la ejecución de la Auditoria. 1
PLANEAMIENTO DE LA AUDITORIA 1.1 Planeamiento de la Auditoría de Sistemas Ahora ya estamos listos para empezar nuestra primera Auditoria. ¿Por dónde empezamos? Pues por el principio. Es decir, por el Planeamiento. El planeamiento adecuado es el primer paso para efectuar auditorías de TI eficaces. ¿Cómo se planifica? Existen 2 tipos de planeamiento: • Planeamiento a largo plazo. En este planeamiento se define el plan de auditoria anual. El riesgo define que se au-
dita primero y que se audita después. •
Planeamiento individual. Este planeamiento se debe hacer para cada Auditoria definida en el punto anterior.
Según ISACA debemos seguir los siguientes pasos para realizar una planificación de Auditoria. • Comprender el negocio. Esto significa comprender la misión, los objetivos, y los procesos de negocio. • Revisar los papeles de trabajo anteriores. Esto significa que el Auditor debe revisar todo el trabajo que se ha reali-
zado en las auditorias anteriores. • Entender los cambios en el entorno de negocios del auditado. • Identificar la estructura organizacional, así como las políticas, normas, procedimientos que le aplican. • Establecer el alcance y los objetivos de la Auditoria. • Desarrollar el enfoque de la Auditoria • Asignar recursos a la Auditoria • Dirigir la logística de trabajo a la Auditoria.
Por otro lado es imprescindible que el Auditor considere las leyes y regulaciones que aplican a la compañía. Por ejemplo si vamos a auditar un Banco, entonces hay que entender las regulaciones definidas por la Superintendencia de Banca y Seguros (SBS). Si vamos a auditar una compañía de electricidad hay que identificar la regulación del Organismo Supervisor de la Inversión en Energía y Minería (OSINERGMIN). Si vamos a auditar una compañía telefónica la regulación a identificar será la de Organismo Supervisor de Inversión Privada en Telecomunicaciones (OSIPTEL). Debes tener en cuenta que históricamente existen 2 tipos de industria que son altamente regulados: la banca y finanzas y las compañías de telecomunicaciones.
17
18
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
1.2 Ejemplo de planificación de Auditoria. Veamos un ejemplo de la planificación de manera general. Tenemos que planificar una Auditoria de Sistemas Externa a una compañía de distribución de electricidad ubicada en el sur del país. • Comprender el negocio. Habíamos dicho que en este punto se debe comprender la misión, los objetivos, y los pro-
cesos de negocio. Una forma inicial es ingresar a la página web de la Compañía. En la sección Conócenos o Quienes somos o sección similar del sitio Web se puede obtener la Misión, Visión y alcance de lo que hace la compañía. Por ejemplo de una rápido recorrido a la página Web de nuestra compañía de ejemplo obtuvimos: Nuestra misión: “Contribuir con el desarrollo de la región sur, brindando oportunamente productos y servicios eléctricos de calidad a satisfacción del cliente, con personal comprometido; consolidando de manera sostenida la rentabilidad de la empresa”. Nuestra visión: “Ser reconocidos como la mejor empresa distribuidora de energía eléctrica en el país”. Al revisar la misión se indica que brindan productos y servicios eléctricos, los cuales se soportan en el uso de tecnologías de Información, que es donde nos enfocaremos para hacer la Auditoria de Sistemas. • Revisar los papeles de trabajo anteriores. Esto significa que debemos solicitar el(los) Informe(s) de Auditoria ante-
rior(es) y los papeles de trabajo que se utilizaron en dicha(s) auditoria(s). En ese (esos) documento(s) encontraremos mucha información que utilizaremos para nuestra planificación. • Entender los cambios en el entorno de negocios del auditado . Aquí debemos identificar los riesgos a los que está
expuesta la compañía y el riesgo al que está expuesta por el uso de la tecnología de la información. Asimismo se debe tener un claro conocimiento de las regulaciones que aplican que para este casos serían las de OSINERGMIN. • Identificar la estructura organizacional, así como las políticas, normas, procedimientos que le aplican . Para poder
planificar debemos tomar conocimiento de del Organigrama de la compañía, como funciona la compañía, que procesos tienen y como operan y tomar conocimiento de todo el conjunto de documentos normativos internos. Este conjunto de documentos lo constituyen las políticas, las normas, las directivas, los estándares, los procedimientos e instructivos. Cada compañía es diferente y los nombres de los tipos de documentos podrían variar. • Establecer el alcance y los objetivos de la Auditoria . En función a los puntos anteriores, ya tenemos una buena
idea de los riesgos de la tecnología y en ese contexto podemos planificar el alcance y los objetivos de la Auditoria. Recuerda que el alcance es igual a trabajo. Eso significa que debemos decidir que trabajo vamos a realizar. Aquí se decide que vamos a auditar (el alcance) y que queremos lograr con la auditoria (los objetivos). • Desarrollar el enfoque de la Auditoria . En este punto ya podemos trazar un plan de trabajo con las actividades
generales para nuestra Auditoria. • Asignar recursos a la Auditoria. En este punto se debe determinar el equipo de trabajo que van a realizar la Audito-
ria. Es evidente que necesitamos a un Auditor con experiencia en sistemas eléctricos. • Dirigir la logística de trabajo a la Auditoria . Aquí se ven los recursos que necesitamos para ejecutar la Auditoria.
Dado que se va a ejecutar una auditoria en el sur del país hay que trasladar útiles de oficina, personas lo que significa pasajes, estadía, viáticos y resolver todos los temas como en donde van a trabajar los auditores, la seguridad de la ubicación de los auditores, su equipamiento informático, su conexión y acceso a la red, entre otros. 2
PROGRAMA DE AUDITORIA.
2.1 Fases para la ejecución de la Auditoria. Una vez que hemos planificado la Auditoria, ya estamos listos para ejecutar la Auditoria. Las Auditorias de Sistemas típicamente siguen las siguientes fases:
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
• Conocimiento del área / tema de la auditoría. • Planeamiento detallado de la auditoría • Revisión preliminar del área a auditar • Evaluación del área/tema a auditar • Verificación y evaluación de los controles • Realización de Pruebas de cumplimiento • Realización de Pruebas sustantivas • Formulación del Informe comunicando los resultados • Seguimiento
2.2 Evidencia de Auditoria. Es un requisito que las conclusiones del auditor estén basadas en evidencia suficiente y competente. El Auditor que no obtiene evidencia no puede escribir sus hallazgos. La evidencia debe tener los siguientes atributos: •
Independencia de quien provee la evidencia
•
Calidad de quien provee la información o evidencia
•
Objetividad de la evidencia
•
Oportunidad de la evidencia
Asimismo, existen diversas técnicas para recopilar evidencia • Revisión del organigrama de SI • Revisión de las políticas, las normas y los procedimientos de SI • Revisión de la documentación de SI • Entrevistas a personal clave • Observación de los procesos y el desempeño del personal
2.3 Ejemplo de un programa de Auditoria. A continuación revisaremos un programa de Auditoria de la compañía Eléctrica “SuperElectro”.
19
20
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
PROGRAMA DE AUDITORIA I. INTRODUCCION Naturaleza La actividad principal de SuperElectro S.A., es la distribución y comercialización de energía eléctrica, en las unidades de concesión otorgadas por el Estado Peruano, así como la generación y transmisión eléctrica en los sistemas aislados, siempre que cuente con las autorizaciones respectivas. Base Legal Las normas que rigen a la Entidad son las siguientes: •
Decreto Ley N.° 25844 Ley de Concesiones Eléctricas, publicado el 19 de Noviembre de 1992 y modificatorias.
•
Decreto Supremo N.° 009-93-EM Reglamento de la Ley de Concesiones Eléctricas, disposiciones, modificatorias y complementarias.
•
Ley N.° 27170 Ley del Fondo Nacional de Financiamiento de la Actividad Empresarial del Estado-FONAFE, publicado el 09 de Setiembre de 1999.
•
Ley N.° 24948 Ley de la Actividad Empresarial del Estado, publicada el 04 de diciembre de 1988.
•
Ley N.° 26734 Ley que crea el Órgano Superior de la Inversión de Energía OSINERGMIN, 1996.
•
Ley N.° 26887, Ley General de Sociedades, sus modificatorias y ampliatorias
•
Ley N.° 27293, Ley del Sistema Nacional de Inversión Pública. Ley N.° 28716 Ley de Control Interno de las Entidades del Estado, publicada el 17 de abril del 2006.
•
Normas de Tecnologías de Información y Comunicaciones •
Modificación al Plan de Gestión Corporativa de Tecnología de Información y Comunicaciones para las empresas bajo el ámbito de FONAFE (2009-2011) aprobada mediante Resolución de Dirección Ejecutiva Nº 046-2009/DE-FONAFE.
•
Aprobar el Nuevo Texto de los Lineamientos para el Uso de las Firmas Digitales e Intercambio Electrónico de Documentos-SIED entre FONAFE y las empresas bajo su ámbito, que en el anexo 1 forman parte del presente acuerdo. Resolución Dirección Ejecutiva N.° 027-2011/DE-FONAFE.
•
Plan de Gestión Corporativa de Tecnología de Información y Comunicaciones para las empresas bajo el ámbito de FONAFE (2008-2011) aprobada mediante Resolución de Dirección Ejecutiva Nº 059-2008/DE-FONAFE.
•
Directiva de uso compartido de software en las empresas bajo el ámbito de FONAFE. Aprobada por Acuerdo de Directorio N.° 004-2007/010-FONAFE.
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
Estructura del Informe El informe de Auditoria se ceñirá a lo dispuesto en las Normas de Auditoria Gubernamental; tanto en lo que se refiere a su estructura como a su contenido, para lo cual se deberá tener en cuenta lo siguiente: I. Introducción. II. Hallazgos. III. Conclusiones. IV. Anexos. I. INTRODUCCION
1. 2. 3. 4. 5. 6. 7.
Origen del examen. Naturaleza y objetivos del examen. Alcance del examen. Antecedentes y base Legal de la Empresa. Comunicación de Hallazgos. Memorándum de Control Interno. Otros aspectos de importancia.
II. HALLAZGOS Se incluirán hallazgos determinados como consecuencia del trabajo de campo realizado y la aplicación de los procedimientos de Auditoria según nuestro programa de trabajo. Dichas observaciones serán evaluadas con las respuestas de los hallazgos comunicados a las personas comprendidas en los mismos, así como la documentación y evidencia sustentatoria respectiva. Estarán referidos a asuntos significativos, e incluirán información suficiente y competente. Cada observación deberá redactarse en forma narrativa, teniendo en cuenta para su presentación los aspectos siguientes: 1) Sumilla. 2) Elementos de la Observación:
2.a) Condición. 2.b) Criterio. 2.c) Efecto. 2.d) Causa.
21
22
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
3) Comentarios y/o aclaraciones del personal comprendido en las observaciones. 4) Evaluación de los comentarios y/o aclaraciones presentados. Tal como lo dispone las Normas de Auditoria Gubernamental, el contenido del informe revelará cada observación considerando lo siguiente: -
Título que utiliza el hecho observado (sumilla).
-
La situación irregular o deficiencia hallada (condición).
-
Las normas transgredidas (criterio).
-
Las razones fundamentales por la cual ocurrió la condición o el motivo por el que no se cumplió el criterio o la norma (causa).
-
Los efectos reales y/o riesgos potenciales cuantitativos o cualitativos que ocasiona el hallazgo (efecto).
III. CONCLUSIONES Juicios de carácter profesional, sustentados en las observaciones resultantes del examen efectuado. IV. RECOMENDACIONES Las recomendaciones constituyen las medidas sugeridas a la Gerencia de la Empresa examinada, orientada a promover la superación de las observaciones o Hallazgos de la evaluación de la gestión. V. ANEXOS Se utilizará los anexos indispensables que competen o amplíen la información de importancia contenida en el mismo. La exposición respecto a la evaluación del cumplimiento y aplicación de los controles Tecnológicos, deberá contener comentarios por cada Área y/o sistema examinado, las cuales se citarán en el informe, incluyendo los aspectos de incidencia. Además deberá darse una apreciación crítica sobre el funcionamiento de cada área y sistema con relación a la Empresa considerada en su integridad.
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
TEMA N.° 3: HALLAZGOS DE AUDITORIA DE SISTEMAS INTRODUCCIÓN En esta sección de la asignatura aprenderás a escribir hallazgos de Auditoria de Sistemas tal cual lo hacen los Auditores de Sistemas profesionales. 1
FORMULACIÓN DE LOS HALLAZGOS DE AUDITORIA
1.1 Hallazgos de Auditoria Como ya se mencionó, el trabajo del Auditor de Sistemas es identificar situaciones que srcinan riesgo y recomendar controles adecuados para su minimización. Cuando el Auditor encuentra una situación de riesgo, escribe un Hallazgo de Auditoria. A continuación te presentaré los componentes de un Hallazgo de Auditoria: Titulo •
Descripción
•
Riesgo
•
Recomendación
El titulo o sumilla presenta de forma precisa el hecho encontrado. Cada hallazgo tiene 3 párrafos: • La descripción presenta la situación o acto irregular que el Auditor detecto. • El riesgo se refiere al daño que se ha srcinado o podría srcinarse si el riesgo se materializa. • La recomendación es el control que el auditor propone para reducir el riesgo.
1.2 Hallazgo de Auditoria en el Sector público. En la Auditoria a una empresa del Estado, se incluyen observaciones determinadas como consecuencia del trabajo de campo realizado y la aplicación de los procedimientos de Auditoria según el programa de auditoria. Las observaciones están referidas a asuntos significativos, e incluirán información suficiente y competente. El formato del hallazgo se amplía a 6 párrafos, esto debido a que así lo exige la normatividad de la Contraloría General de la Republica. Titulo •
Condición
•
Criterio
•
Causa
•
Riesgo
•
Recomendación
23
24
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
•
Conclusión
El Título describe el hecho observado (sumilla). Cada hallazgo tiene 6 párrafos: • La situación irregular o deficiencia hallada (condición). • Las normas transgredidas (criterio). • Las razones fundamentales por la cual ocurrió la condición o el motivo por el que no se cumplió el criterio o la
norma (causa). • Los efectos reales y/o riesgos potenciales cuantitativos o cualitativos que ocasiona el hallazgo (efecto). • La recomendación es el control que el auditor propone para reducir el riesgo. • La conclusión es la conclusión del Auditor después de dar la oportunidad de réplica al auditado.
Las observaciones son evaluadas con las respuestas de los hallazgos comunicados a las personas comprendidas en los mismos, así como la documentación y evidencia sustentatoria respectiva. 1.3 Ejemplos de hallazgos de auditoria. Ahora vamos a revisar algunos ejemplos de hallazgos de Auditoria. Ejemplo 1: 150 PCs del parque informático de la Entidad cuentan con el Sistema Operativo Windows XP que ya no cuenta con soporte del fabricante. De la revisión al parque informático de la Entidad, se encontró que existen 150 equipos informáticos que cuentan con el sistema operativo Windows XP. Dicho sistema operativo ya no es soportado por Microsoft desde el 08 de abril del 2014, lo cual significa que los equipos que aún cuentan con dicho sistema operativo se encuentran vulnerables, ya que el fabricante ya no emite parches de seguridad. La información completa del fin del soporte para el sistema operativo Windows XP se encuentra disponible en el sitio web oficial de Microsoft, en el link. http://windows.microsoft.com/en-us/windows/products/lifecycle#section_2 Esta situación expone a los equipos con dicho sistema operativo ya que no reciben actualizaciones de software ni parches de seguridad, lo que convierte a dichos equipos en altamente vulnerables a las amenazas informáticas tales como virus, gusanos, troyanos, spyware, rootkits, etc, lo que a su vez, podría srcinar falta de disponibilidad en dichos equipos y comprometer a los demás equipos conectados a la red. Se recomienda que la Gerencia General disponga que la Gerencia de Tecnología de Información y Comunicaciones evalúe y planifique la renovación tecnológica de los equipos vulnerables o en su defecto se programe la migración del sistema operativo Windows XP instalado en los equipos de la Entidad a una versión más reciente y que cuente con el soporte de parches y actualizaciones vigentes.
Se puede apreciar que el Auditor ha escrito el título de la observación, de tal manera que al leerla no nos quede duda de que se trata la observación. Como dijimos, el titulo debe ser lo más preciso posible. Luego del título, el primer párrafo pertenece a la descripción. Aquí el Auditor ha descrito la situación o debilidad encontrada que srcina riesgo. En este caso encontró 150 equipos con Sistema Operativo cuyo fabricante (Microsoft) ya no envía parches ya que esta fuera de soporte. El segundo párrafo se refiere al riesgo que el auditor identificó. En este párrafo se describe claramente el riesgo identificado, en este caso, los equipos están expuestos a ataques informáticos. El último párrafo del hallazgo se refiere a la recomendación del auditor. El auditor recomienda la implementación de algún tipo de control para minimizar el riesgo encontrado. En este caso el Auditor recomienda la renovación de los equipos o la migración a un Sistema Operativo más seguro. Veamos un segundo ejemplo.
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
Ejemplo 2: Se identificaron cuentas de personal cesado que permanecen activas en el Sistema ERP SAP. Durante la revisión a la vigencia de los accesos en el sistema de información SAP, identificamos cuentas de usuarios de personal cesado, según el reporte de cese emitido por Recursos Humanos, que permanecen activos en el sistema SAP, tales como: C Ó D I G OEM P LE A D O
UNIDAD ORGANIZACIONAL
N O MB R ES
F E C H AD EC E SE
M Ó D U LOS A P
795835
Bochelli,Andrea
LOGISTICA
09/01/2016
Order Management
795842
Boyle,Susan
LOGISTICA
09/01/2016
Order Management
795455
Riu,Andre
CONTABILIDAD
31/03/2016
GeneralLedger
Esta situación incrementa el riesgo de accesos no autorizados al sistema, mediante el uso de cuentas de personal cesado que se mantienen activas, después de su fecha de cese. El impacto asociado al riesgo identificado, dependerá de los permisos relacionados a los accesos asignados a cada una de las cuentas. Se recomienda realizar un seguimiento sobre la desactivación de dichas cuentas de usuarios en el Sistema SAP y realizar un monitoreo continuo sobre las cuentas de usuario de personal cesado.
En este segundo ejemplo, se puede apreciar que el Auditor nuevamente ha escrito el título de la observación, de tal manera que al leerla no nos quede duda de que se trata la observación. El titulo debe ser lo más preciso posible. Luego del título, el primer párrafo pertenece a la descripción. Aquí el auditor debe escribir la situación encontrada. El segundo párrafo se refiere al riesgo que el auditor identifico. En este párrafo se describe el riesgo identificado. El último párrafo del hallazgo se refiere a la recomendación del auditor. El auditor recomienda la implementación de algún tipo de control para minimizar el riesgo encontrado. Veamos un tercer caso. Ejemplo 3: El Centro de Datos presenta algunas debilidades a nivel de seguridad ambiental. De la revisión al Centro de Datos de la Entidad, se encontró que dicho Centro cuenta con deficiencias a nivel de seguridad ambiental. Así tenemos las siguientes debilidades: -
Se encontró que el Centro permanece a una temperatura no adecuada. Se encontró un extractor de aire no instalado.
-
Todos los equipos del Centro de Datos se encontraba cubiertos de polvo, ya que para ventilar el ambiente se mantiene la ventana del Centro que da la calle, permanentemente abierta.
-
El Centro de Datos no cuenta con un falso piso no falso techo.
-
Se cuenta con UPS individuales para cada servidor.
-
No existe una bitácora de ingreso.
25
26
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
Esta situación podría srcinar el riesgo de malfuncionamiento de los Servidores y de los equipos de comunicación ubicados en dicho Centro, lo que podría srcinar a mediano plazo, interrupciones de los servicios y sistemas gestionados por la Oficina de Sistemas e Informática. Se recomienda que la Gerencia General, disponga la evaluación de las acciones necesarias para que la Oficina de Sistemas e Informática priorice las acciones necesarias para subsanar las debilidades encontradas.
En todos los casos se aprecia que el formato de la observación de auditoria se mantiene. 2
FORMULACIÓN DE LAS RECOMENDACIONES
Es importante que el Auditor escriba racionalmente las recomendaciones de cada uno de sus hallazgos. Las recomendaciones deben ser escritas en forma clara y no deben escribirse recomendaciones que puedan significar un desembolso significativo de dinero por parte del Auditado. Veamos los siguientes ejemplos de recomendaciones: Tabla 1 Formulaci{on de recomendaciones F O R MIAN C O R R EC TA
Comprarunnuevosoftware
Evaluarlafactibilidaddeadquirirunnuevosoftware
Reemplazar un Sistema de Información
Disponer que la Gerencia General en conjunto con la Gerencia de TI evalúen la posibilidad de cambiar el Sistema de Información
CambiaralGerentedeTI Cambiar el 50% de las computadoras actuales del parque informático
3
F O R MCA O R R E C TA
DisponerquelaGerenciadeRRHHevalúelaconveniencia de reemplazar al Gerente de TI Evaluar la factibilidad de cambiar el 50% de las computadoras actuales del parque informático
FORMULACIÓN DEL INFORME DE AUDITORIA
3.1 El informe de Auditoria El informe de Auditoria es el entregable final del trabajo de un Auditor. Típicamente es escrito en MS-Word y contiene los siguientes componentes: •
Antecedentes
•
Objetivo
•
Alcance
•
Relación de Observaciones / Hallazgos
•
Limitaciones a la auditoria
•
Otros Aspectos de Importancia
•
Conclusiones
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
3.2 Pasos para la presentación del Informe de Auditoria. Una vez que el Auditor escribe el informe, éste estará en modo borrador. El Auditor seguirá los siguientes pasos para la entrega del informe: •
El informe se enviara al auditado (normalmente el Gerente de Sistemas) para darle la posibilidad de que responda
a los hallazgos encontrados. •
El Auditado revisará el informe y responderá a los hallazgos encontrados. Normalmente el Auditado se comprome -
te a cumplir con las recomendaciones de los hallazgos en una determinada fecha. Sin embargo, en algunas ocasiones el Auditado podría oponerseesa un determinado hallazgo, debido a que se equivocó el hallazgo debido a que la recomendación imposible de ejecutar, ya que podría ser elnoAuditor beneficioso para losenintereses de lao compañía. •
El Auditor se entrevista con el Auditado para discutir las respuestas del Auditado y resolver cualquier inquietud.
•
El Auditor coordinará una entrevista nal al más alto nivel de la Compañía (normalmente con el Gerente General)
para la comunicación de los resultados de la auditoría •
Se cierra formalmente la Auditoria.
3.3 Ejemplo de Informe de Auditoria INFORME DEL EXAMEN ESPECIAL AL DEPARTAMENTO DE INFORMATICA
Del 1 de enero 2016 al 30 de marzo de 2016 ÍNDICE
Pág. INFORME DEL EXAMEN ESPECIAL AL DEPARTAMENTO DE INFORMATICA I. Síntesis gerencial
2
II. INTRODUCCIÓN
3
2. Origen del examen
3
3. Naturaleza y objetivos del examen
4
4. Alcance del examen
4
Otros aspectos de importancia
4
III. HALLAZGOS
5
IV. CONCLUSIONES
10
Síntesis Gerencial El presente Examen Especial comprende la evaluación de los Sistemas Informáticos con los que cuenta la Compañía, los mecanismos de seguridad informáticos, los mecanismos de contingencias y recuperación de desastres y la implantación del control interno en el departamento de Informática dentro del período del 01.01.16 al 31.03.16. Las principales conclusiones del trabajo realizado son las siguientes:
27
28
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
1. El departamento de Informática realiza básicamente labores de soporte a los usuarios, no habiendo actividades de desarrollo de Sistemas. 2. El departamento de Informática no cuenta con normatividad esencial para su funcionamiento. Específicamente no cuenta con un Plan de Contingencias adecuado y además no cuenta con un Plan Estratégico de Sistemas. 3. Algunos procedimientos del área no se encuentran normados. 4. La ejecución del proceso del backup se considera expuesta a demasiado riesgo, toda vez que los backups no son almacenados adecuadamente en un lugar seguro. Como resultado de esta acción de control se identificaron seis (6) hallazgos, y diversas deficiencias de control interno entre las que destacan las relacionadas con deficiencias en la seguridad física, ejecución de backups de software base y la documentación relacionada, por lo que con la finalidad de promover la superación de las causas que las motivaron, se proponen las siguientes recomendaciones tanto al Comité Directivo, Gerencia A, Gerencia B y Gerencia C. I. INTRODUCCIÓN A continuación se presenta información general sobre el presente Examen al Departamento de Informática de la Compañía.
1. Origen del examen El Examen Especial al Departamento de Informática, por el período comprendido entre el 01.01.16 y 30.03.16, se realiza en cumplimiento del Plan Anual de Control para el 2016 del Órgano de Control Institucional de la Compañía. Es importante destacar que las áreas relacionadas con el Departamento de Informática no han sido materia de acciones de control posterior en los últimos dos años.
2. Naturaleza y objetivos del examen Esta acción de control consiste en un Examen Especial y tiene como objetivos generales y específicos los siguientes: Objetivo General Evaluar el adecuado uso de las Tecnologías de Información incidiendo en software, hardware, comunicaciones, seguridad y control de calidad, así como evaluar la adecuada organización, planificación y administración del Área de Informática. Objetivos específicos a) Evaluar el Sistema Informático con el que cuenta la Compañía, determinando si los aplicativos actuales satisfacen las necesidades de la Compañía, la interrelación de sus aplicativos, su grado de funcionamiento y los controles implementados. b) Evaluar los mecanismos de Seguridad Informáticos implantados en la Compañía para asegurar la integridad de la información y de los recursos informáticos de la Compañía. c) Evaluar los mecanismos de Contingencias y recuperación de desastres de la Oficina de Informática para minimizar los riesgos de interrupciones y/o paralizaciones en el servicio. d) Determinar el grado de cumplimiento del sistema de Control Interno del departamento de Informática.
3. Alcance del examen El alcance del Examen Especial al Departamento de Informática está referido a todas las acciones de control posterior y demás actividades desarrolladas para lograr un adecuado y oportuno funcionamiento de los sistemas de la Compañía, ejecutadas durante el periodo comprendido entre el 01.01.16 y 30.03.16. De acuerdo con el Plan Anual de Control 2016, los procesos ó áreas a ser examinados serán la administración eficiente de los recursos destinados al desarrollo de actividades del Departamento de Informática; el nivel de seguridad de los recursos informáticos, el nivel de cumplimiento de objetivos del área; aplicación de las normas legales e internas que regulan la labor de informática y la realización de
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
las labores del área. El presente examen especial se desarrolló en la ciudad de Lima, en las instalaciones del local institucional de la Compañía. El plazo inicialmente estimado para el desarrollo de este examen se vio ampliado debido a la solicitud de ampliación de plazo presentada por el Gerente A y la Directora de Informática para la presentación de sus comentarios y aclaraciones en relación con los hallazgos comunicados; así como al plazo adicional otorgado a los mencionado funcionarios.
4. Otros aspectos de importancia Por ser de importancia para los fines del presente informe, es preciso resaltar los siguientes hechos o circunstancias verificados durante el desarrollo de esta acción de control posterior, relacionados con los objetivos de ésta y con las situaciones evidenciadas en la Compañía: a) Durante la revisión del software con el que cuenta la Compañía, se pudo apreciar que la Compañía no cuenta con un aplicativo que le permita llevar el control de las partidas presupuestales. Se pudo evidenciar que actualmente, el sistema de Contabilidad SISCONT no cuenta con información de control que sirva como instrumento para la toma de decisiones relacionadas al Presupuesto. Las actividades de formulación y control de los montos ejecutados y pendientes son realizadas de forma manual. II. HALLAZGOS Durante el desarrollo de esta acción de control se determinaron las siguientes observaciones, las cuales incluyen los comentarios y aclaraciones de los funcionarios de la Compañía.
1. ALGUNAS TABLAS DEL SISTEMA CORE1 NO CUENTAN CON LLAVE PRIMARIA De la revisión a la estructura de la Base de Datos del Sistema CORE1 (Sistema de Información Gerencial), se evidenció que de un total de 90 tablas, 18 tablas no contenían llaves primarias (es la que permite identificar cada registro individual de los demás registros en una determinada tabla). Las tablas que no cuentan con llave primaria son: FormaA1
MoviMiembros
TbRegistro
TasasME
TasasME1
TasasMN
TasasMN1
TbRatios
XCOLOCACIONES
Xconcepto
Xformula
XMontosCtas
XRESULTADO
XRESULTADO1
XRESULTADO2
XRESULTADOFINAL
Xstitulo
Xtitulo
Esto se debe a que en el Departamento de Informática no existen procedimientos de monitoreo que permitan asegurar la integridad referencial de la Base de Datos del Sistema CORE1. Esta situación podría conllevar a que los registros de información presenten duplicidad en información, incrementa el riesgo de que la Base de Datos del Sistema CORE1 contenga información no validada o información sujeta a errores. Se recomienda que la Dirección de Informática priorice la implementación de la integridad referencial en la Base de Datos del Sistema CORE1.
2. EL PLAN DE CONTINGENCIAS NO CUENTA CON LOS PROCEDIMIENTOS DE RECUPERACIÓN DE DESASTRES ANTE LA OCURRENCIA DE ALGUNA EVENTUALIDAD El Plan de Contingencias formulado por el Departamento de Informática, presenta algunas deficiencias, las cuales se detallan a continuación: a) El Plan de Contingencias no cuenta con los procedimientos de recuperación a seguir ante la ocurrencia de una eventualidad.
29
30
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
b) No se contempla los diferentes escenarios de desastre. c) El Plan no cuenta con un calendario de pruebas. d) El Plan de Contingencias, siendo un documento confidencial, ha sido distribuido a todas las Jefaturas e) El Plan no considera la recuperación de las aplicaciones CORE2, CORE3 y SISFACT. La falta de procedimientos en el Plan de Contingencias srcina que la Compañía no esté preparada para afrontar la ocurrencia de una situación de emergencia o desastre, la cual podría devenir en cortes y/o interrupciones prolongadas del servicio informático ofrecido por el Departamento de Informática. Se recomienda que la Gerencia General disponga que la Directora de la Oficina de Informática evalúe la priorización de la actualización del Plan de Contingencias, definiendo las siguientes actividades: a) Definir los procedimientos de recuperación a seguir ante la ocurrencia de una eventualidad. b) Contemplar diferentes escenarios de desastre por cada riesgo identificado. c) Definir un calendario para la realización de pruebas a los procedimientos del Plan.
3. LA COMPAÑIA NO CUENTA CON UN PLAN DE SISTEMAS DE INFORMACIÓN De la revisión y evaluación de la documentación de Planeamiento se determinó que el Departamento de Informática no cuenta un Plan de Sistemas, el cual es una herramienta de gestión que establece las necesidades de información de la Compañía, teniendo el propósito de prever el desarrollo de los recursos físicos y lógicos con un horizonte temporal determinado, de manera que contribuya efectivamente con los objetivos de la Compañía. El Departamento de Informática en la actualidad cuenta con un Plan de Actividades que muestra las actividades realizadas en dicho periodo. Esta situación podría conllevar que las actividades del área Informática no se encuentren alineadas con los objetivos institucionales y estratégicos de la Compañía así como a los requerimientos de la empresa; Además el no contar con un Plan de Sistemas a largo plazo, srcina que la empresa no se comprometa a destinar recursos suficientes para el cumplimiento de los mismos. Se recomienda que la Dirección de la Oficina de Informática evalúe la priorización de elaborar el Plan de Sistemas de Información, el cual debe estar alineado con los Objetivos Institucionales trazados en el Plan Estratégico de la Compañía. Específicamente el Plan de Sistemas debe contener: • Diagnóstico de la situación informática actual con la finalidad de saber las capacidades actuales de la Compañía;
·
Elaboración de objetivos y estrategias del sistema de información que sirva de base para apoyar la misión y los objetivos de la Compañía;
·
Desarrollo del modelamiento de datos para determinar qué información es necesaria para la Compañía;
·
Generación, ordenamiento y priorización (por nivel de importancia e inversión) sistemática de los proyectos informáticos;
·
Programación de los tiempos requeridos para la puesta en marcha de los proyectos designados, estimando el período de vida de cada proyecto.
4. LOS RESPALDOS DE INFORMACIÓN (BACKUPS) QUEREALIZA EL DEPARTAMENTO DE INFORMÁTICA NO SE ALMACENAN EN UN LUGAR SEGURO Se comprobó que los backups son elaborados de forma semanal, guardándose en un disco de uno de los Servidores del Departamento
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
de Informática. Dichos backups de manera quincenal son almacenados en cinta. Las cintas son luego, guardadas en la Gerencia de Administración, en un estante que no brinda ninguna seguridad ni protección para el buen estado de las cintas. Esta situación pone en riesgo la continuidad del servicio ofrecido por el Departamento de Informática, toda vez que ante la ocurrencia de un desastre, existe el riesgo de no contar con los recursos necesarios para restaurar el servicio ofrecido por el Departamento de Informática. Se recomienda que la Directora de la Oficina Informática defina un procedimiento que garantice el adecuado almacenamiento de los backups. Se recomienda que los backups se almacenen en la caja fuerte del departamento de Administración. Asimismo definir un procedimiento que permita a la Directora de Informática contar con el acceso a dicha caja fuerte solo en los casos de la ocurrencia de alguna eventualidad.
5. EL DEPARTAMENTO DE INFORMÁTICA NO REALIZA PERIÓDICAMENTE UN MONITOREO DE LAS ACTIVIDADES DE USO Y ACCESO A LOS RECURSOS INFORMÁTICOS De la revisión a los procedimientos de monitoreo de la seguridad lógica, se evidenció que el Departamento de Informática no realiza ningún monitoreo periódico de actividades de uso y acceso a los recursos informáticos de la Compañía, con el fin de determinar el uso correcto de dichos recursos, así como detectar intentos de violación y/o acceso no autorizados a los recursos informáticos de la Compañía. Así tenemos que no se encontró evidencia de la realización de un monitoreo periódico a las actividades de uso de Internet, tráfico de correo, tráfico sospechoso por la red, actualización de cliente antivirus, cambio de passwords, ni de intentos de acceso o acceso no autorizado a los recursos informáticos administrados por el Departamento de Informática. Esta situación srcina que no se detecten los intentos de acceso o los accesos no autorizados a los recursos informáticos de la Compañía e incluso podría devenir en fuga de información sensitiva fuera de la Compañía. Se recomienda que la Directora de la Oficina de Informática elabore un calendario periódico que permita definir fechas de realización del de las actividades de uso y acceso a los recursos informáticos la Compañía. como resultado de dicho monitoreomonitoreo se debe informar a la Gerencia de las actividades encontradas en dichodemonitoreo, con elAsimismo objeto de realizar las acciones correctivas correspondientes contra el o los infractores.
6. NO EXISTE UN PROCEDIMIENTO FORMAL QUE REGULE EL ACCESO REMOTO A LOS SERVIDORES DE LA COMPAÑIA Durante la inspección realizada para verificar los controles de acceso lógico implementados en la Compañía, se pudo verificar que la Directora de Informática ha realizado en un par de ocasiones el acceso remoto a los recursos de la Compañía. Este acceso remoto se realiza a través de Internet. A la fecha de nuestra revisión, este acceso no se encontraba normado. Esta situación podría ocasionar un acceso no autorizado de información, toda vez que al tratarse de un acceso remoto, no se necesita estar dentro de las instalaciones de la Compañía. Se recomienda que la Dirección de la Oficina de Informática defina un procedimiento que regule el acceso a los recursos informáticas vía acceso remoto. Asimismo como parte de las actividades del procedimiento se debe emitir un informe a la Gerencia ha, informando las actividades realizadas para cada uno de los accesos remotos ocurridos. III. CONCLUSIONES Como resultado del examen especial realizado, arribamos a las siguientes conclusiones:
1. El departamento de Informática no cuenta con un Plan de Contingencias actualizado y completo, debido a que no se ha priorizado la definición de los procedimientos de recuperación del Plan de Contingencias. 2. El departamento de Informática no cuenta con un Plan de Sistemas de Información, debido a que el Departamento de Informática basa la ejecución de sus actividades en un Plan de Actividades anual, el cual contiene la descripción y cronograma de ejecución de dichas actividades.
31
32
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
3. Los respaldos de información (backups) no son almacenados en un lugar seguro, debido a que no se han tomado todas las medidas necesarias para garantizar la disponibilidad, protección y buen estado de las cintas, necesarias ante la ocurrencia de alguna contingencia. 4. No se ejecuta un monitoreo periódico de las actividades de uso y acceso a los recursos informáticos de la Compañia, debido a que no se ha previsto la realización de un cronograma de monitoreo de uso y acceso a los recursos ni al seguimiento del cumplimiento de normas y políticas del Departamento. 5. No existe un procedimiento formal que regule el acceso remoto a los servidores de la Compañia, debido a que no se ha previsto la formulación de un procedimiento que regule el acceso remoto a los recursos informáticos de la Compañía. En conclusión, se advierte que los sistemas de información y la infraestructura tecnológica que administra la Oficina de Informática cuentan con controles deficientes que necesitan ser subsanados para proteger adecuadamente a la Compañía.
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
TEMA N.° 4: MARCOS DE REFERENCIA DE AUDITORIA DE SISTEMAS
INTRODUCCIÓN En esta sección revisaremos los principales marcos de referencia internacionales que son utilizados por el Auditor de Sistemas. 1
REGULACIONES INTERNAS
A nivel de Perú contamos con normas. 1.2 Superintendencia de Banca y Seguros(SBS) La SBS es una entidad reguladora que supervisa el funcionamiento de las entidades financieras que incluye la banca, seguros y sistema privado de pensiones; así como la de prevenir el lavado de activos. Todo esto para lograr el objetivo de preservar los intereses de los depositantes, asegurados y afiliados a las AFPs. Entre sus funciones está a función de supervisión de dichas entidades en función a los diferentes tipos de riesgos tales como riesgo crediticio, de mercado, de liquidez, operacional y legal. Dentro del riesgo operacional está el riesgo relacionado a las tecnologías de información. En ese contexto, la SBS pública normas que son de carácter obligatorio para las entidades mencionadas. Entre las normas más relevantes para la Auditoria de Sistemas se tiene las circulares G-139 y G-140. La circular G-139-2009-SBS obliga a las entidades financieras a mantener una gestión de la continuidad del negocio como un proceso, por Directorio, la Gerencia el personal, que implementa respuestas efectivas para que la operatividad delefectuado negocio de la el empresa continúe de unaymanera razonable, con el fin de salvaguardar los intereses de sus principales grupos de interés, ante la ocurrencia de eventos que pueden crear una interrupción o inestabilidad en las operaciones de la empresa. Las empresas deben realizar una gestión de la continuidad del negocio adecuada a su tamaño y a la complejidad de sus operaciones y servicios. Si te interesa conocer más de esta circular, la puedes encontrar en https://intranet2.sbs.gob.pe/intranet/INT_CN/ DV_INT_CN/246/v1.0/Adjuntos/g-139-2009.c.pdf Por su lado, la circular G-140-2009-SBS obliga a las entidades financieras establecer, mantener y documentar un Sistema de Gestión de Seguridad de la Información (SGSI) tomando como referencia las normas internacionales ISO 17799 e ISO 27001. Si te interesa conocer más de esta circular, la puedes encontrar en: https://intranet2.sbs.gob.pe/intranet/INT_CN/ DV_INT_CN/249/v1.0/Adjuntos/g-140-2009.c.pdf 1.3 Contraloría General de la Republica (CGR) La CGR es la máxima autoridad del Sistema Nacional de Control. La CGR supervisa, vigila y verifica la correcta aplicación de las políticas públicas y el uso de los recursos y bienes del Estado Peruano. Para realizar con eficiencia sus funciones, cuenta con autonomía administrativa, funcional, económica y financiera En ese contexto, la Contraloría emite normas que son de cumplimiento obligatorio para las entidades del Sector Publico. La Norma que gobierna las actividades de Auditoria son las Normas Generales de Control Gubernamental. Puedes encontrar las Normas Generales en:http://doc.contraloria.gob.pe/libros/2/pdf/RC_273_2014_CG.pdf. Si le das una leída, estas normas tienen muchos de los componentes que revisamos en el acápite 2.2 Estándares de ISACA del tema 1.
33
34
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
A nivel de Auditoria de Sistemas, las Normas que debemos tomar en cuenta son las Normas de Control Interno que están vigentes desde el 2006. En este documento en la sección III tenemos 3 cláusulas que se deben tener en cuenta: 1.3.1 Clausula 2Norma Generalpara el componente deevaluación deriesgos: “El componente evaluación de riesgos abarca el proceso de identificación y análisis de los riesgos a los que está expuesta la entidad para el logro de sus objetivos y la elaboración de una respuesta apropiada a los mismos. La evaluación de riesgos es parte del proceso de administración de riesgos, e incluye: planeamiento, identificación, valoración o análisis, manejo o respuesta y el monitoreo de los riesgos de la entidad”. 1.3.2 Clausula 3.10 Controles para las tecnologías de Información y Comunicaciones: “La información de la entidad es provista mediante el uso de Tecnologías de la Información y Comunicaciones (TIC). Las TIC abarcan datos, sistemas de información, tecnología asociada, instalaciones y personal. Las actividades de control de las TIC incluyen controles que garantizan el procesamiento de la información para el cumplimiento misional y de los objetivos de la entidad, debiendo estar diseñados para prevenir, detectar y corregir errores e irregularidades mientras la información fluye a través de los sistemas”. 1.3.3 Clausula 4.4 Sistemas de Información: “Los sistemas de información diseñados e implementados por la entidad constituyen un instrumento para el establecimiento de las estrategias organizacionales y, por ende, para el logro de los objetivos y las metas. Por ello deberá ajustarse a las características, necesidades y naturaleza de la entidad. De este modo, el sistema de información provee la información como insumo para la toma de decisiones, facilitando y garantizando la transparencia en la rendición de cuentas”. El texto completo del documento Normas de Control Interno lo puedes ubicar en: http://controlinterno.concytec.gob.pe/images/stories/2012/normatividad/RCG_320_2006_CG.pdf Si este interesado en conocer más de la Contraloría General de la Republica, puedes dirigirte a: http://doc.contraloria.gob.pe/documentos/PREGUNTAS_FRECUENTES_2015.pdf 1.4 Ley 29733 de Protección de Datos Personales. Esta ley obliga a las compañías a tomar medidas para preservar los datos personales que las compañías tienen de las personas naturales, es decir proteger la privacidad de las personas. ¿Qué se entiende por privacidad? Se refiere al ámbito de la vida personal de un individuo que se desarrolla en un espacio reservado y debe mantenerse de manera confidencial. La Ley fue promulgada el 03/07/11, y fue reglamentada el 22/03/13. La Directiva de Seguridad fue emitida el 16/10/13 y entró en plena vigencia el 08/05/15. La ley defineaatravés los datos personales a toda aquella información sobre una persona natural que la identifica o laApellihace identificable de medios que pueden ser razonablemente utilizados. Así por ejemplo tenemos Nombres, dos, DNI, teléfonos, dirección domicilio, correo electrónico, fecha de nacimiento, sexo, Nro. Identificación tributaria, Razón Social, Nro. De cuenta bancaria. Asimismo, la ley define un tipo especial de datos personales. Nos referimos a los datos sensibles. Los Datos Sensibles son los Datos personales constituidos por los datos biométricos que por sí mismos pueden identificar al titular; datos referidos al srcen racial y étnico; ingresos económicos , opiniones o convicciones políticas, religiosas, filosóficas o morales; afiliación sindical; e información relacionada a la salud o a la vida sexual. Un claro ejemplo de datos sensibles son los Sueldos de los trabajadores en una compañía.
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
Las compañías están obligadas a inscribir los Bancos de datos que contienen datos personales. Un banco de Datos es un conjunto de datos personales. De nuestra experiencia, hemos podido identificar que toda compañía tiene al menos 4 Bancos de Datos que contienen datos personales: •
Clientes
•
Trabajadores
•
Proveedores (personas naturales)
•
Visitantes
Uno de los temas más importantes de la Ley son los Derechos ARCO. Estos son los derechos fundamentales a los que una persona tiene derecho y que pueden ser usados con una compañía que tiene sus datos personales. Los derechos son: •
Acceso. Una persona tiene derecho a saber que datos tiene una compañía de ella.
•
Recticación. Una persona tiene el derecho a recticar cualquier dato erróneo que una compañía tenga de ella.
•
Cancelación. La persona tiene derecho a que la compañía borre la información de ella. Esto, siempre y cuando,
no haya una relación existente. Por ejemplo un trabajador no puede pedir a su compañía que borre toda la información de ella. •
Oposición. Un apersona puede oponerse a que una compañía use sus datos personales para un uso particular. Por
ejemplo, una persona puede oponerse a que le envíen publicidad. El cumplimiento de la Ley está a cargo de la Autoridad Nacional de Protección de datos personales (ANPDP) que depende del Ministerio de Justicia. La ANPDP emitió la Directiva de Seguridad que define los controles tecnológicos, legales y administrativos que las compañías deben seguir para proteger los datos personales. Entre los controles tecnológicos más importantes esta la implementación de un Sistema de Gestión de Seguridad de la Información, controles criptográficos, controles de acceso, respaldo, entre otros. Puedes ver un video de la Autoridad nacional de Protección de datos personales en: https://www.youtube.com/watch?v=1c4YMd_YaRs 2
REGULACIONES EXTERNAS
2.1 COSO ERM. El Committee of Sponsoring Organizations of the Treadway – Enterprise Risk Management, más conocido como COSO ERM es una marco de referencia (framework) de riesgos empresariales. Actualmente está en la versión 3. El marco es formulado por la Organización COSO que es un comité voluntario de 5 instituciones y que está orientado a gestionar tres temas fundamentales: la gestión del riesgo empresarial (ERM), el control interno, y la disuasión del fraude en las compañías. La idea del COSO es promover la gestión de riesgos en todos los niveles de la compañía y establece directrices para la toma de decisiones de los líderes de las compañías para el control de los riesgos y la asignación de responsabilidades. En su más reciente versión, el marco define 5 componentes de control: • Entorno de control • Evaluación de riesgos • Actividades de Control
35
36
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
• Información y Comunicación • Actividades de supervisión
Todas las compañías que gestionan el riesgo (no solo el riesgo de TI) utilizan este framework como guía para sus actividades. Si deseas saber más sobre el COSO ERM, puedes acceder a un resumen ejecutivo en la siguiente dirección: http://doc.contraloria.gob.pe/Control-Interno/Normativa_Asociada/coso_2013-resumen-ejecutivo.pdf 2.2 CobiT 5. Es el marco de referencia (framework) más importante de TI para el gobierno y la gestión de las TI en una compañía. No existe documento más importante en TI que el CobiT. Según el documento Cobit5 Introducción:”COBIT 5 ayuda a las Compañías a crear un valor óptimo a partir de la TI, al mantener un equilibrio entre la realización de beneficios y la optimización de los niveles de riesgo y utilización de los recursos. COBIT 5 permite que lastecnologías de la información y relacionadas se gobiernen y administren deuna manera holística a nivel de toda la Organización, incluyendo el alcance completo de todas las áreas de responsabilidad funcionales y de negocios, considerando los intereses relacionados con la TI delas partes interesadas internas yexternas”. Para ello, Cobit5 define 5 principios, los cuales se presentan en el gráfico 3: Satisfacer las necesidades de los stackeholders.
Separar Gobierno de Gestión.
Cubrir totalmente la empresa.
Principios
Habilitar un enfoque holístico.
Aplicar un único marco de referencia integrado.
Figura 3. Los 5 principios de Cobit5. Fuente: ISACA.
Asimismo, Cobit5 define 7 habilitadores. Este término algo extraño no es más que los factores que, individual y colectivamente, influyen sobre si algo funcionarán – en este caso, el Gobierno y la Gestión de la TI.
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
Los 7 habilitadores que define CobiT se muestran en la siguiente figura.
Figura 4. Habilitadores de Cobit 5. Fuente ISACA.
COBIT 5 une los cinco principios que permiten a la Organización construir un marco efectivo de Gobierno y Gestión basado en los siete habilitadores, para que juntos, optimicen la inversión en tecnología de información así como su uso en beneficio de las partes interesadas. Asimismo, uno de los temas transcendentales del CobiT es que separa el Gobierno de TI de la Gestión de TI. Durante muchos años se usó indistintamente ambos conceptos, pero ahora se tienen claramente diferenciados. Gobierno de TI es la definición de los objetivos de TI (en función de los objetivos de Negocio). Gestión de TI es el logro de los objetivos trazados. Por tanto un gestor es aquel que logra que las cosas se hagan. ¿Qué cosas? Las definidas en el Gobierno de TI. La figura 5 presenta la separación de los dominios de CobiT separando el Gobierno de la Gestión
Figura 5. Gobierno y Gestión de TI. Fuente: ISACA
37
38
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
En función a ello, CobiT define un conjunto de 37 procesos, tal como se presentan a continuación:
Figura 6. Mapa de Procesos de CobiT. Fuente: ISACA
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
Para los Auditores, los temas de Gobierno de TI son de mucha utilidad ya que el Auditor puede evaluar la definición de objetivos de TI en función de los Objetivos de Negocio. Por el lado de Gestión de TI, el Auditor puede evaluar los procesos que en su conjunto persiguen el logro de los objetivos de TI. Si deseas saber más de CobiT5, te recomiendo el siguiente link: http://www.isaca.org/COBIT/Documents/COBIT5-Introduction-Spanish.ppt 2.3 Familia ISO 27000. La Familia ISO 27000 es un conjunto de normas internacionales relacionadas a la seguridad de la Información. Esta familia tiene cerca de 40 normas. En este curso nos centraremos en las 2 normas más importantes de la familia: La Norma ISO 27001 y la norma ISO 27002. 2.3.1 Norma ISO 27002. No, no nos hemos equivocado en la numeración. Primero vamos a presentar la ISO 27002 y lo vamos a hacer antes de la ISO 27001. La Norma ISO 27002:2013 define un conjunto de requisitos presenta un total de 14 Capítulos (en la norma se llaman Dominios), 35 Objetivos de Control y 114 Controles que una compañía debe implementar para proteger su información. Los 14 dominios de la Norma son: – Política de Seguridad – Organización de la Seguridad de la Información – Seguridad relacionada a los RRHH – Gestión de Activos – Control de Accesos – Criptografía – Seguridad física y ambiental – Seguridad en las operaciones – Seguridad en las comunicaciones – Adquisición, desarrollo y mantenimiento de sistemas – Relación con los proveedores – Gestión de incidentes de seguridad de la información – Seguridad de la continuidad de negocio – Cumplimiento Un resumen de la norma la puedes encontrar en: http://www.iso27000.es/download/ControlesISO27002-2013.pdf Antes esta norma se llamaba ISO 17799, a veces los cambios de numeración confunden. En el Perú existe la Norma
39
40
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
Técnica Peruana NTP ISO/IEC 17799, que es el equivalente a la ISO 27002:2013. Que no te sorprenda la numeración! La Presidencia del Consejo de Ministros obliga a las Entidades del Estado a cumplir con esta Norma. 2.3.2 Norma ISO 27001. Esta norma pretende la implementación de un Sistema de Gestión de Seguridad de la Información, más comúnmente conocido como SGSI. La ISO 27001 define un conjunto de requisitos para establecer, implementar, mantener y mejorar un SGSI dentro de una Compañía. Asimismo define requisitos para la evaluación y tratamiento de riesgos de seguridad de la información. El Sistema de Gestión de la Seguridad la Información (SGSI) en las compañías ayuda a establecer políticas, procedimientos y controles en relacióndea los objetivos de negocio. En el Perú la Norma Técnica Peruana Vigente es la NTP ISO/IEC 27001:2014. A la fecha existen más de 10 compañías en el Perú que han obtenido el certificado ISO 27001. Entre las que se pueden mencionar a: Atento, GMD, Hermes transportes blindados, Hochschild Minning PLC, Indecopi, Oficina de Normalización Previsional ONP, PMC Latam, Secure Soft, Telefónica del Perú, Telefónica Empresas y Telefónica Gestión de Servicios Compartidos Perú SAC Cualquier compañía puede tomar la decisión de certificarse. Existen mecanismos de implementación que requieren el apoyo de la Alta Gerencia. Un ejemplo de la Certificación la puedes observar en el siguiente gráfico:
La compañía donde trabajas
Figura 7. Ejemplo de la certificación ISO 27001:2013
La Auditoria de Sistemas a una compañía que cuenta con el certificado ISO 27001 es una Auditoria especializada que requiere que el Auditor conozca y evalúe sobre la correcta implementación del SGSI,
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
2.4 Sarbanes-Oxley (SOX). La Ley Sarbanex-Oxley es una ley federal de los Estados Unidos cuyo objetivo es monitorear a las compañías que cotizan en la Bolsa de valores, a través de controles contables para que el valor de las acciones no sean “manipuladas” en deterioro de los accionistas. Esta ley fue aprobada en el año 2002 después de la quiebra en el 2001 de la gigantesca compañía energética Enron que manipulo escandalosamente sus cifras contables para que la cotización de sus acciones siempre estuviese alta. Cuando sucede la quiebra de Enron sus acciones pasaron de costar USD 90 a costar USD 0.30, lo que significó un desastre financiero para sus accionistas. En realidad, Enron fue “la gota que derramo el vaso”, toda vez que existieron otras quiebras como las de las compañías Tyco International, WorldCom y Peregrine Systems que aumentaron la desconfianza en las compañías que cotizaban en bolsa y en las compañías de Auditoria que realizaban la Auditoria Financiera. De hecho, una de las grandes compañías de Auditoria quebró también. La compañía se llamaba Arthur Andersen, quienes se hicieron “de la vista gorda” con las prácticas contables de Enron. Los puntos más importantes que introdujo la Ley Sarbanes-Oxley fueron de índole contable, que afectan a la TI ya que los sistemas contables corren en ambientes tecnológicos. • Se creó la Public Company Accounting Oversight Board (PCAOB por sus siglas en inglés), que es una Entidad que
debe supervisar las auditorías de las compañías que cotizan en bolsa. • Es obligatorio que las compañías que cotizan en bolsa garanticen la veracidad de las evaluaciones de sus controles
internos en sus informes financieros, así como que los auditores independientes de estas compañías constaten esta transparencia y veracidad. • Los estados financieros deben estar certificados por parte del comité ejecutivo y financiero de la compañía. • Las compañías deben trabajar con empresas auditoras completamente independientes. • Se exige que las compañías que cotizan en bolsa tengan un comité de auditoría, con personal completamente in-
dependiente, que supervisen la relación entre la compañía y sus auditores externos • Prohibición de préstamos personales de dinero a los altos ejecutivos de la compañía. • Transparencia de la información de acciones y opciones, de la compañía en cuestión, que puedan tener los directi-
vos, ejecutivos y empleados claves de la compañía y consorcios, en el caso de que posean más de un 10 % de acciones de la compañía. Asimismo estos datos deben estar reflejados en los informes de las compañías. • Endurecimiento de la responsabilidad civil y penal por incumplimiento de la Ley Sox. La ley amplia las penas de
prisión y las multas a los altos ejecutivos que incumplen y/o permiten el incumplimiento de las exigencias financieras. Dado que en el Perú operan filiales de compañías estadounidenses que cotizan en bolsa, es común auditar a las filiales peruanas en el cumplimiento de la Ley Sox. Para terminar sobre la ley, te recomiendo que veas el famoso documental sobre el caso Enron: Los tipos que estafaron América. Lo puedes encontrar en: https://www.youtube.com/watch?v=mnyzZ7r1zdA 2.5 Basilea III. Son un conjunto de normas de regulación bancaria para las instituciones bancarias, que se encuentran vigentes desde el 2010, orientadas a proporcionar las mecanismos eficientes para mejorar la capacidad de respuesta del sistema bancario ante perturbaciones económicas y financieras (burbujas, debacles, etc) y conseguir así una mayor estabilidad financiera mundial. Estas normas reemplazan a Basilea II, y fueron la respuesta regulatoria para superar los riesgos que sufrieron las instituciones financieras debido a la crisis hipotecaria que golpeó a Estados Unidos y se esparció por todo el mundo en el año 2008. Las Normas son emitidas por el Comité de Supervisión Bancaria de Basilea del Bank of International Settlements( BIS) o Banco de Pagos Internacionales, que es el Banco Central de los Bancos Centrales, cuya sede está en Basilea, Suiza.
41
42
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
2.6 PCI-DSS (Payment Card Industry – Data Security Standar). Las Normas de seguridad de datos de la industria de tarjetas de pago (PCI DSS) se desarrollaron para fomentar y mejorar la seguridad de los datos del titular de la tarjeta y facilitar la adopción de medidas de seguridad uniformes a nivel mundial. Las PCI DSS proporcionan una referencia de requisitos técnicos y operativos desarrollados para proteger los datos de los titulares de tarjetas. Las PCI DSS se aplican a todas las entidades que participan en el procesamiento de tarjetas de pago, entre las que se incluyen comerciantes, procesadores, adquirientes, entidades emisoras y proveedores de servicios, como también todas las demás entidades que almacenan, procesan o transmiten CHD (datos del titular de la tarjeta) o SAD (datos de autenticación confidenciales). Las normas abarcan 12 la seguridad de las redes, la seguridad del titular de la tarjeta, gestionar las vulnerabilidades, medidas de control de acceso, la supervisión y evaluación periódica de las redes, y políticas de seguridad de la información para todo el personal. Puedes visitar el sitio web de PCI en: https://www.pcisecuritystandards.org/ Asimismo, la norma está disponible en: https://es.pcisecuritystandards.org/minisite/en/pci-dss-v3-0.php
LECTURA SELECCIONADA N.° 1 Leer artículo: Auditoria de sistemas. D’Sousa, C. (2008). Auditoria de sistemas [Sitio Web]. Disponible http://www.gerencie.com/auditoria-de-sistemas.htnl en: ,
ACTIVIDAD N.° 1
Participa en el Foro de discusión sobre “Los riesgos srcinados por el uso de las Tecnologías de Información en las organizaciones”. INSTRUCCIONES • Lee y analiza un caso sobre riesgos srcinados por el uso de las TICs. • Expresa tus opiniones en relación al caso en el foro de discusión que se encuentra en el aula virtual.
CONTROL DE LECTURA Nº 1 Esta actividad puede consultarla en su Aula virtual.
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
GLOSARIO DE LA UNIDAD I Amenaza: Es cualquier cosa que tenga el potencial de hacer daño. Auditoria de Sistemas: es un proceso sistemático de evaluación post-mortem y de formación de opinión sobre una determinada materia o situación. Para nuestro caso sobre una materia o situación relacionada a Tecnología de Información tal como un Sistema Informático, una Base de datos, una Infraestructura tecnológica, unos Servidores, la gestión del Gerente de TI, un proceso de atención de soporte técnico a usuarios, etc. Causa: En el contexto de un hallazgo de Auditoria en el Sector Publico se refiera a la(s) razón(es) fundamental(es) por la cual ocurrió la condición o el motivo por el que no se cumplió el criterio o la norma. CISA: Acrónimo de Certified Information Systems Auditor. Es la certificación internacional más reconocida en el ámbito de la Auditoria de Sistemas. Control: Es cualquier cosa que minimiza un riesgo. Por ejm. escribir un procedimiento, implementar un firewall, instalar un antivirus, ejecutar un respaldo (backup), etc. Criterio. En el contexto de un hallazgo de Auditoria en el Sector Publico se refiere a la(s) norma(s) transgredida(s). Daño: Es el impacto negativo que tenemos si la amenaza se aprovecha de la(s) vulnerabilidad(es). El daño pude ser económico, patrimonial, de imagen, etc. Hallazgo de Auditoria: Es la descripción que hace un Auditor de Sistemas para dar a conocer una situación de riesgo. ISACA. Acrónimo de Information Systems Audit and Control Association(ISACA) que es la institución mundial más
importante en Auditoria de Sistemas. Recomendación: Es el control que el auditor propone para reducir el riesgo. Riesgo: Es la probabilidad que una amenaza se aproveche de una vulnerabilidad y nos genera un daño. Vulnerabilidad: es cualquier deficiencia que tenga un activo informático.
BIBLIOGRAFÍA DE LA UNIDAD I Information systems audit and control association. (2016). CISA Re-view Manual. Chicago: ISACA. Information systems audit and control association. (2012) COBIT 5 Un marco de negocio para el Gobierno y la Gestión de la TI en la Empresa. USA: ISACA.
43
44
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
AUTOEVALUACIÓN DE LA UNIDAD I
1. Ud. está planificando una auditoria al área de Sistemas de la compañía farmacéutica Pharmax. Al respecto, ¿Cuál de los siguientes NO sería parte de su planificación de Auditoria? A) Evaluación del área / tema de la auditoría B) Obtención de la evidencia C) Verificación de las Pruebas D) Entrega del Informe 2. Ud. se encuentra auditando lagestión de la Gerencia de Sistemasde la compañía Aji-si-moto yen el transcurso de la auditoria se le acerca uno de los integrantes del equipo de Sistemas que le indica que necesita conversar con Ud. en privado sobre un asunto importante y confidencial. Ud. acepta conversar con la persona y esta le informa que el Gerente área de Sistemas está malversando el presupuesto del área ya que todos los contratos de desarrollo de software los gana un único proveedor y este proveedor deja los proyectos inconclusos y aun así, el Gerente destemas Si autoriza el pago puntual a la referida compañía. La persona le indica que se ha enterado que el Gerente del proveedor es amigo de la infancia del Gerente de Sistemas de Aji-si-moto. Al respecto, Ud. le solicita a la persona que: A) Presente una queja formal B) Relacione lo indicado con los objetivos de la Auditoria C) Indique una recomendación D) Demuestre lo indicado 3. Ud. está realizando el seguimiento a observaciones de auditoria de sistemas del periodo anterior para una compañía del sector público, Ud. encuentra que solo existe una observación por subsanar y que dicha observación cuenta con la siguiente estructura: Descripción Criterio Riesgo Causa Recomendación Conclusión En ese contexto, cuál de los siguientes representa a la sección “Criterio”. A) La norma transgredida B) El criterio del auditor C) La clasificación del riesgo encontrado por el auditor D) La amenaza
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
4. Lea cuidadosamente la siguiente observación de Auditoria: Durante la visita efectuada al área de TI, se observó que no existe una configuración de redes virtuales (VLANs) en las sedes de la compañía, que permitan segmentar el enrutamiento de los datos y mitigar el riesgo de un acceso ilimitado a toda la red. Recientemente, el área de TI evidenció la adquisición de 2 switches (por renovación tecnológica), que permitirían la configuración de dichas redes virtuales. El Gerente de TI indicó que las VLANs serán implementadas como parte del proyecto de Comunicaciones Unificadas (CISCO Telephony) la cual estará programada para finales de enero 2016 o inicios de febrero 2016. Si bien existe una propuesta técnica y un contrato elaborado para iniciar la implementación, al cierre de la revisión aún se encuentra pendiente la formalización e inicio del Proyecto Comunicaciones Unificadas. El riesgo ya se ha materializado, ya que se evidenció que hace 3 meses, un atacante logro acceder a la red desde el exterior y tuvo acceso a los servidores de la compañía, lo que significó una paralización de la red por 2 días. Esto se debió a que la red no cuenta con las VLANs implementadas. ¿Cuál sería la recomendación más idónea para reducir el riesgo presentado? A) Se recomienda que el Gerente General contrate los servicios de una empresa especializada en implementación de redes virtuales. B) Se recomienda que el Gerente de TI tenga listo un script para configurar los switches para ganar tiempo apenas aprueben el proyecto de Comunicaciones Unificadas. C) Se recomienda que el Gerente General disponga que el Gerente de TI priorice la implementación de las redes virtuales, sin esperar el inicio del proyecto de Comunicaciones Unificadas. D) Se recomienda que el Gerente de TI logre la autorización del Gerente General para el proyecto de Comunicaciones Unificadas. 5. Ud. comprende la importancia de gobernar y gestionar adecuadamente las tecnologías de Información. Al respecto. Ud principalmente recomendaría utilizar el marco de referencia: A) ITIL B) CobiT C) PMBOK D) ISO 27002 6. Ud. ha implementado un Sistema de Gestión de Seguridad de la Información (SGSI) recientemente. Luego de la implementación Ud. recibe la visita del equipo de Auditoria y el equipo le indica que la auditoria se va a enfocar en el proceso de evaluación de riesgos de seguridad de la información. ¿Cuál de las siguientes normas es más probable que el equipo de auditoria utilice como referencia para ejecutar la auditoria? A) ISO 27002 B) ISO 27001 C) Cobit5 D)COSO ERM
45
46
UNIDAD I: INTRODUCCIÓN A LA AUDITORIA DE SISTEMAS
7. Una empresa trasnacional de alimentos con sede en Estados Unidos que cotiza en la Bolsa de New York (NYSE), cuenta con una importante operación en Perú. ¿Cuál de las siguientes regulaciones estaría en obligación de cumplir la oficina en Perú? A) CobiT B) ISO 27001 C) Sarbanes Oxley (SOX) D) Normas técnicas de Control Interno de la Contraloría General de la Republica 8. Considere la “Capacidad para el establecimiento de objetivos” versus “la capacidad para lograr los objetivos“. Esto representa la diferencia entre: A) Auditoria y Gobierno B) Gobierno y Gerencia C) Gobierno y mejores practicas D) Gobierno y Gestión 9. ¿Cuál de los siguientes es VERDADERO en relación a los derechos ARCO que tiene un ciudadano con respecto a sus datos en poder tienen las compañías en el Perú en el marco de la Ley 29733 de Protección de Datos personales? A) El derecho de Cancelación se refiere a que un ciudadano puede solicitar a una compañía que le cancele un monto de dinero por el uso de sus datos. B) El derecho de Oposición se refiere a que un ciudadano puede oponerse a algún tratamiento de sus datos como por ejemplo no recibir publicidad de dicha compañía. C) El derecho de Acceso se refiere a que un ciudadano puede solicitar que sus datos puedan ser accedidos de manera pública. D) El derecho de Rectificación se refiere a que un ciudadano pueda solicitar a una compañía que elimine completamente los datos personales de dicho ciudadano. 10. Una importante grupo industrial que cotiza en la Bolsa de USA ha decidido instalar su oficina principal de Latinoamérica en el Perú y está revisando los temas regulatorios que debe cumplir para su correcto funcionamiento en el país. Al respecto, ¿De Cuál de las siguientes regulaciones estará la compañía preocupada debido a que maneja datos como pruebas de reacciones alérgicas en personas voluntarias a las pruebas?
A) Ley 29733 de protección de datos B) Basilea III C) SOX D) ISO 27001
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
DIAGRAMA DE PRESENTACIÓN DE LA UNIDAD II CONTENIDOS
EJEMPLOS
AUTOEVALUACIÓN
ACTIVIDADES
BIBLIOGRAFÍA
ORGANIZACIÓN DE LOS APRENDIZAJES C O N O C I MI EN TO S
3° Videoclase (Video conferencia) Tema N.° 1: Gobierno y Gestión de TI 1. Gobierno Corporativo y Gobierno de TI 2. Practicas Gerenciales de Gestión de TI 3. Auditoría al Gobierno y a la Gestión de TI Lectura seleccionada 1 : De gerente de TI a CIO, una evolución necesaria en el Perú http://www.esan.edu.pe/conexion/actualidad/2011/11/14/de-gerente-de-ti-a-cio-unaevolucion-necesaria-en-el-peru/
P R O C ED I MI EN TO S
1. Identifica el gobierno (governance) corporativo y su relación con el gobierno de TI. 2. Formula la estrategia de TI. 3. Identifica el árbol normativo de TI. 4. Aplica las prácticas de inversión y asignación de recursos. 5. Conocimiento de la estructura organizacional, los roles y las responsabilidades relacionadas con TI. 6. Participa en la redacción de hallazgos relacionadas al Gobierno y la Gestión de TI. Actividad N.° 2 Participan en el Foro de discusión sobre “las prácticas gerenciales en el área de Sistemas”.
4° Videoclase Tema N.° 2: “Continuidad de Negocio y Recuperación de Desastres” 1. Gestión de la Continuidad de Negocio 2. Planeación a la Continuidad de Negocio y Recuperación de Desastres 3. Auditoria a la Continuidad de negocio 4. Formulación del Informe de Auditoria
1. Identifica los riesgos relacionados a la continuidad de negocio. 2. Identifica los pasos de la ejecución de un plan de continuidad de Negocio. 3. Formula hallazgos de auditoria de Sistemas tomando como base los riesgos de la continuidad de negocio.
Lectura seleccionada 2 Título: Lecciones aprendidas para la recuperación de desastres tras el 9/11 http://www.pcworld.com.mx/Articulos/18319.htm Autoevaluación Nº 2
Realiza una Auditoria al caso “Recuperación de Desastres”.
Tarea Académica Nº 1
A C T I TU D E S
1. Valora la importancia de la ejecución de la auditoria de sistemas. 2. Se auto valora por su aprendizaje de las técnicas de auditoria de siste-mas. 3. Asume el compro-miso de revisar los contenidos del manual. 4. Valora la importancia de la auditoria de sistemas para el mejora-miento de una empresa y para las actividades o procesos a realizar. 5. Participa activamente en el desarrollo de las actividades de la asignatura.
47
48
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
TEMA N.° 1: GOBIERNO Y GESTIÓN DE T.I.
INTRODUCCIÓN En este tema nos iremos a 10,000 metros de altura para presentar los tópicos que gestiona un Gerente de Tecnología de Información. Revisaremos los conceptos de Gobierno Corporativo, como impacta en la Organización y como la gerencia de TI debe asegurar el Gobierno de TI en donde se definen los objetivos de TI alineados al Negocio. Luego revisaremos las practicas Gerenciales que todo Gerente de TI debe aplicar para su adecuada gestión y luego aprenderemos a auditar el Gobierno y la Gestión de TI. 1
GOBIERNO CORPORATIVO Y GOBIERNO DE TI
1.1 Gobierno Corporativo El Gobierno Corporativo (Corporate Governace) es un conjunto de buenas prácticas que deben ser seguidos por una compañía para alinear los objetivos de los accionistas o a los propietarios (en Perú normalmente una familia que controla una empresa) la dirección y la administración de la empresa, a través de la definición y separación de roles estratégicos, operativos, de vigilancia y gestión. Estas prácticas están orientadas a lograr una trasparencia sobre los riesgos de una empresa, protegiendo a los inversionistas o a los propietarios evitando actos ilícitos o fraudulentos (Recuerde el Caso Enron). El Gobierno corporativo responde a la pregunta: ¿Qquien controla la empresa y porque? Las buenas prácticas de Gobierno Corporativo nacen como respuesta a la Crisis de los inversionistas (alineando los intereses de todas las partes dentro de una Compañía. En Perú, la Superintendencia de Valores, precisa en documento Código de Buen para las Sociedades Peruanas del queMercado : “La adopción de prácticas deelbuen gobierno corporativo porGobierno parte deCorporativo las sociedades, promueve un clima de respeto a los derechos de los accionistas y de los inversionistas en general; contribuye a generar valor, solidez y eficiencia en las sociedades; trae consigo una mejor administración de los riesgos a los cuales se encuentran expuestas; facilita el acceso al mercado de capitales; lleva a una reducción del costo de capital, así como a un mayor y mejor acceso a fuentes de financiamiento y de inversión a largo plazo; entre otras ventajas. Asimismo, la experiencia ha demostrado que en la medida que exista mayor transparencia e información, mayor es la confianza que desarrollan los inversionistas en los mercados. Las prácticas de buen gobierno corporativo ayudan a mitigar las fallas que existen en los mercados financieros por la asimetría de información”. Asimismo, el citado documento indica que el Gobierno Corporativo se divide en cinco pilares: • Derechos de los accionistas; • Junta General de Accionistas; • El Directorio y la Alta Gerencia; • Riesgos y cumplimiento; y • Transparencia de la Información.
Si te interesa aprender más sobre Gobierno Corporativo, puedes descargar el Código de Buenas Prácticas de Gobierno Corporativo para las sociedades peruanas. Lo puedes encontrar en: http://www.smv.gob.pe/Uploads/CodBGC2013%20_2_.pdf 1.2 Gobierno de TI Del concepto de Gobierno Corporativo se desprende el concepto de Gobierno de Tecnologías de Información.
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
ISACA define al Gobierno de TI como “el liderazgo, estructuras y procesos organizacionales que garantizan que la TI de la empresa sostiene y extiende las estrategias y objetivos organizacionales”. Es decir que el área de TI debe estar 100% alineado a los objetivos del negocio y eso es responsabilidad de la Gerencia de TI. Históricamente las áreas de TI se han visto como áreas de “Soporte Técnico”. El área de TI debe sacudirse de esta forma de ser percibida y ser una área que ofrece servicios que otorgan valor al negocio, ya que la forma cómo las T.I son aplicadas tendrá un impacto inmenso en si las compañías lograrán su visión, misión o metas estratégicas. Es más, TI tiene la obligación de aportar valor al negocio. Al implementar Gobierno de TI, la gerencia general y la gerencia de TI dan el impulso para que TI cumpla con los objetivos de la compañía. Para ello el Gerente de TI debe cambiar la forma como la TI ejecuta, permitiendo la trasparencia y control del área de TI y gestionando los riesgos relacionados con la tecnología. Los Gerentes de TI exitosos entienden y manejan los riesgos relacionados con la implementación de nuevas tecnologías.
Figura 8. Gobierno Corporativo y Gobierno de TI. Fuente: ISACA.
1.3 Implementación del Gobierno de TI. Para Implementar el Gobierno de TI existen 2 marcos de referencia principales. Evidentemente, el primer marco es el Cobit5 (Recuerde que el CobiT5 permite implementar Gobierno y Gestión de TI). El segundo marco es la norma ISO/ IEC 38500 “Corporate Governance of Information technology” que es un conjunto de principios para que la Gerencia pueda evaluar, dirigir y monitorizar el uso de las TI en una compañía. 2
PRACTICAS GERENCIALES DE GESTIÓN DE TI
2.1 Planeamiento de TI 2.1.1 Plan Estratégico Empresarial (PEE). Las compañías para lograr sus objetivos primero deben pasar por un procesos de definición mediante un Planeamiento Estratégico Empresarial (PEE) en el cual se define la visión, la misión, los Objetivos y las estrategias de Negocio. Normalmente, estos planes son formulados en reuniones de los más altos directivos de la compañía (entre los que debería participar el Gerente de TI) y definen el Plan del negocio a un horizonte de 5 años como máximo. Es muy común encontrar Objetivos como ampliación de las ventas, ampliación de la participación del mercado, expansión a otros países, regiones, reducción de costos,lanzamiento de nuevos productos o servicios,entre otros. 2.1.2 Plan Estratégico de Tecnología de Información. El Planeamiento de Tecnologías de Información se debe realizar poniendo el foco del plan en coherencia con el Plan Estratégico Empresarial, que vimos en la Unidad anterior.
49
50
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
Cuando hablamos de Planeamiento de TI, los Gerentes de TI se preocupan de hacer un Plan a largo Plazo, para definir como las TI impactaran en el Negocio. Este plan se refleja en el llamado PETI, el cual es el acrónimo de Planeamiento Estratégico de TI, que es un documento en el cual se plasma la visión, misión, objetivos de TI, el alineamiento de los objetivos de TI con el negocio, y en función a ello, las metas y proyectos del área de TI. Usualmente el PETI es formulado con un alcance de tres años de duración, ya que es imposible prever que nuevas tecnologías aparecerán en los siguientes años. Como recordará el Gobierno de TI tiene que ver con la definición de Objetivos de TI. A continuación presentaremos una tabla conteniendo ejemplos de alineamiento de TI con el Negocio. Tabla 2 Ejemplos de Alineamiento de TI con el Negocio O B J E TI V O DN E EGOC I O
Aumentar en 30% las ventas Mejorar la rentabilidad en 8% Abrir oficinas en 3 nuevos países
O B J ET I V O DTEI
Implementar un Sistema de ventas basado en tecnologías móviles. Implementar un Sistema de Consolidación financiera Ampliar la infraestructura tecnológica para el soporta de las nuevas oficinas
Como se puede apreciar, los Objetivos de TI siempre deben estar orientados al logro de los objetivos del negocio. Si un área de TI no está orientado a ese logro, los objetivos de TI serán puramente técnicos y no necesariamente los intereses de TI coincidirán con los intereses del negocio, lo cual puede ser fatal para el negocio. Cuando los intereses de TI no coinciden con los intereses del Negocio, el Negocio percibe que TI no da valor, dando como resultado que nadie entiende que es lo que se hace en TI y eso aumenta la percepción de que TI solo está para “arreglar teclados y corregir la impresora”, es decir el área de TI se convierte en un área de Soporte Técnico. 2.1.3 Comité de Sistemas Otro de los mecanismos de Planeamiento muy utilizados es el Comité de Sistemas. Este Comité de Sistemas es una mejor práctica de la industria, en la cual de manera periódica (por ejemplo, trimestral) se reúnen la Alta Gerencia con los Gerentes de la Compañía para supervisar el logro de los objetivos y el desempeño del área de TI. Evidentemente, el Gerente de TI participa de estas reuniones de Alto Nivel en la cual se revisan los objetivos de TI y los proyectos y se repriorizan los proyectos en función a las necesidades de la compañía. Un ejemplo de conformación de un Comité de Sistemas podría ser: Presidente, Vicepresidente de Finanzas, Vicepresidente de TI, Gerente de Marketing, Gerente de Ventas, Gerente de Producción, entre otros. 2.2 Normatividad Una práctica importante para el Gerente de TI para optimizar su gestión es contar con la Normatividad adecuada. Para ello, el Gerente de TI debe preocuparse que exista el árbol normativo adecuado. Un árbol Normativo consta de: 2.2.1 Políticas. Una política es una declaración de una intención o comportamiento de una compañía sobre un determinado tema.
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
Por ejemplo veamos esta política sobre respaldos: “La compañía respaldará la información crítica de manera periódica”. Como se puede apreciar, la política declara la intención de la compañía, en este caso declara la intención de respaldar. La política no dice que se va a respaldar ni cómo se va a respaldar. 2.2.2 Normas. Una Norma es el segundo peldaño en el Árbol Normativo. Una Norma es como una Ley, es decir tiene que cumplirse obligatoriamente. El objetivo de una Norma es hacer cumplir una Política. Por ejemplo veamos la siguiente Norma: “Todos los días a las 10pm se realizará el respaldo de información de las Bases de Datos de los Sistemas Críticos de la Compañía”. Como se puede apreciar la Norma obliga a que se realice un backup a las 10 de la noche de las Bases de datos de los sistemas Críticos. La Norma es vinculante y está orientada a cumplir la Política, en este caso la política de respaldo de información. 2.2.3 Procedimientos Un Procedimiento es un conjunto de pasos generales que se siguen para lograr un determinado resultado. El objetivo de un procedimiento es hacer cumplir una Norma. Un ejemplo de un procedimiento podría ser: Procedimiento de respaldo de información a. Identificar las Bases de datos a respaldar
b. Ejecutar el respaldo en disco c. Verificar si el respaldo se encuentra correctamente ejecutado d. Copiar el respaldo de disco a cintas e. Verificar las cintas f. Guardar las cintas en lugar seguro 2.2.4 Instructivos Un instructivo es el último peldaño en el Árbol Normativo. El instructivo es similar al procedimiento, pero a diferencia del procedimiento, contiene el conjunto de pasos detallados para lograr un determinado resultado. El procedimiento contiene instrucciones los pasos generales, mientras que el yinstructivo contiene losde pasos detallados. El instructivo puede contener o comandos de sistema puede ir acompañado pantallazos. A continuación podemos ver un ejemplo de instructivo: Instructivo de Instalación de Software de respaldo. Elaboradopor:
Revisadopor:
Aprobadopor:
FechadeEmisión:
51
52
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
1. PROPÓSITO Instalación de la solución para realizar copias de seguridad y recuperación de archivos en los equipos de la compañía. 2. ALCANCE Inicia con la ejecución de la consola de administración de RESPALDO AUTOMÁTICO DE INFORMACIÓN y finaliza con el registro del monitoreo en el formato asociado correspondiente. 3. DESCRIPCIÓN DE ACTIVIDADES 3.1 Para encontrar los instaladores de RESPALDO AUTOMÁTICO DE INFORMACIÓN para equipos Windows realizamos la combinación de teclas Windows + R se mostrara la ventana Buscar. En el cuadro escribimos la ruta \\SERVIDOR08 , por ultimo aceptamos como indica la secuencia de la Figura1.
Figura 1
3.2 Ingresamos a la carpeta instaladores como se muestra en la Figura2.
Figura 2
3.3 Una vez dentro ingresamos a la carpeta Utilitarios y Otros haciendo doble click como se muestra en la Figura3
Figura 3
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
3.4 Hacer click al archivo Setup.exe para comenzar la instalación del RESPALDO AUTOMÁTICO DE INFORMACIÓN
Figura 4
Como se puede apreciar, el instructivo es muy detallado y puede contener pantallazos para que el usuario pueda seguirlo y cumplir con los pasos indicados.
2.3 Practicas Gerenciales de RRHH El Gerente de TI enfocado en que se logren los objetivos de TI alineados con los objetivos del Negocio, debe preocuparse de contar con los mejores profesionales. Son las personas las que hacen que las cosas sucedan y son las personas el factor determinante para el logro de los objetivos. Para ello el gerente de TI debe recurrir a las mejores prácticas relacionadas a la gente. 2.3.1 Prácticas de contratación. El gerente de TI debe asegurarse de que el área de RRHH cuente con mecanismos de contratación eficientes que filtrarán al mejor candidato posible. a) Verificación de Experiencia Profesional. Es imprescindible que se verifique el CV de los candidatos. Algunos candidatos tienden a “inflar” sus CVs. Hay que llamar a todos los referidos y a los jefes anteriores de los candidatos para confirmar la veracidad de la experiencia profesional. b) Verificación de Logros Académicos. También hay que revisar si los grados, títulos y certificaciones de los candidatos son veraces. Cuantas veces se han visto casos que incluso han salido a la luz pública, de gente que dice tener una maestría o doctorado sin tenerlo. c) Verificación de Antecedentes. A cada uno de los candidatos se les debe solicitar que presenten sus antecedentes penales, policiales y judiciales. Un profesional serio no debería tener este tipo de antecedentes. d) Verificación domiciliaria. La verificación domiciliara es importante para conocer el ambiente donde viven los candidatos y si este ambiente podría ser riesgoso. Por ejm. se suele contratar a una compañía para realizar las verificaciones domiciliarias. e) Verificación crediticia. verificación es importante ya que un candidato con deudas podría originar un riesgo para laLacompañía. Su crediticia in candidato no honra sus deudas o está atravesando problemas financieros, podría ser tentado a cometer un acto ilícito. Por ejm. se debe consultar a las centrales de riesgo crediticias como Experian o Infocorp. f) Prueba del polígrafo. En algunos casos, algunos puestos críticos para el área de IT podrían requerir de una prueba del polígrafo(detector de mentiras). 2.3.2 Prácticas de retención de talento. Una vez que tenemos el mejor profesional, un reto mayo es retenerlo en la Compañía. Los profesionales talentosos siempre están buscando retos que valgan la pena.
53
54
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
Para la retención, el Gerente de TI debe definir: a) Línea de carrera. El profesional debe conocer cuál es la línea de carrera en la compañía. El no contar con una línea de carrera srcina que los trabajadores se aburran y busquen nuevas oportunidades fuera de la Compañía. b) Recompensa. Los mejores profesionales siempre esperan estar bien recompensados. No solo se trata del monto mensual sino de conocer los márgenes de Utilidades y bonos que la compañía le puede proporcionar. c) Clima Laboral. Otro aspecto importante es el clima laboral. El profesional talentoso espera que la compañía sea un lugar donde sea fácil trabajar, que su jefe le de libertad, que se reconozcan sus logros. 2.3.3 Segregación de Funciones. La segregación de funciones es una práctica importante para prevenir actos ilícitos o fraudulentos. Cuando existe segregación de funciones un trabajador no puede controlar un proceso o transacción de manera completa. Cuando una persona controla un proceso completo, hay mucha probabilidad de que esa persona cometa un acto ilegal tarde o temprano. Al controlar un proceso completo, la persona se podría ver tentada de hacer “trampa”. Veamos un ejemplo: Suponga que Ud. es programador de la Municipalidad del distrito donde vive. Ud tiene acceso a los programas fuentes del Sistema Informático. En esta municipalidad aplican la práctica de segregación de funciones por lo que Ud. no tiene acceso a la Base de Datos. ¿Qué podría pasar si Ud. tuviese acceso a la Base de Datos? ¿Qué le impediría que acceda a la tabla de Arbitrios y “pagar” los arbitrios de su casa?. Lo único que lo detendría es su ética. Pero, ¿Qué pasaría si un vecino le dice que le da s/. 300 si le borra toda la deuda? Para evitar estas (y muchas otras situaciones), el gerente de TI debe preocuparse que exista segregación de funciones en su área. 2.3.4 Prácticas de terminación laboral. El Gerente de TI debe tener definidos los procedimientos de cese de su personal. La mejor práctica indica que se deben cortar inmediatamente los accesos a todos los recursos informáticos una vez que una persona se retira de la compañía. Esto aplica para todos los trabajadores de la compañía. Es posible que un trabajador “se retire mal” de la compañía, es decir que se le detecte en un acto ilegal o tenga un problema laboral que exija que se retire inmediatamente de la compañía y se le retiren también inmediatamente todos los accesos. 2.4 Tercerización La tercerización es una de las mega-tendencias tecnológicas y los Gerentes de TI deben aprovechar muy bien esta oportunidad. La tercerización tiene que ver con pasar a una compañía especialista actividades que no están directamente relacionadas con la misión del negocio (algunos autores le llaman el core del negocio). En ese contexto, muchas actividades de TI pueden ser tercerizadas. Se puede tercerizar el Soporte Técnico, el desarrollo de software, la gestión de la infraestructura tecnológica, entre otros. Incluso en Perú hay algunos casos en donde se ha tercerizado la gran matoria de TI e incluso hay un par de compañías que han tercerizado todo TI! Entre las ventajas de tecerizar, se tiene que al tercerizar el Gerente de TI “reduce puntos de stress”, es decir, tiene menos cosas de las que preocuparse, ya que ha contratado a una empresa especializada para que se ocupe de un determinado tema. Asimismo, la tercerización permite concentrase en las cosas importantes (como por ejemplo apuntar al logro de los objetivos de TI) y no “desenfocarse” en temas que no son importantes. También se dice a menudo que la tercerización reduce costos, pero no siempre es así. A veces incluso puede salir más caro. Uno de los aspectos más importantes que el Gerente de T.I. debe tener en cuenta al momento de tercerizar es que el servicio que contratemos sea de mejor calidad que haciéndolo internamente. Es decir no tiene sentido, contratar a un
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
proveedor especializado para que haga las cosas “peor” que nosotros. En ese sentido, para garantizar que el servicio prestado sea de calidad, el Gerente de TI debe exigir a todos los terceros que firmen un Service Level Agreement (SLA) o Acuerdo de Nivel de Servicio (ANS), por sus siglas en español. Un SLA es un documento en el cual el proveedor se compromete a garantizar un determinado nivel de servicio. En caso de que el proveedor no cumpla con dicho nivel, le aplicaremos una penalidad. Por ejemplo, si contratamos un proveedor para que nos gestione la infraestructura tecnológica compuesta por servidores, switches y routers, deberíamos exigir que estos aparatos siempre estén funcionado, de tal manera que no haya cortes en el servicio. En un mundo ideal, el SLA debería ser de 100% lo que significa que los aparatos siempre estarán funcionando. Sin emabrgo, esto no es así. Si e proveedor nos ofrece un SLA de 99.95% de disponibilidad al año, esto significaría que nosotros toleraríamos cortes al año que representan como máximo el 0.05%. El 0.05% de 365 días son 18 días. Esto es inaceptable para una compañía. En cambio, el proveedor nos ofrece un SLA de 99.99%, esto significa que toleraríamos un corte de 3.65 dias. Dependiendo del tipo de compañía, esto podría ser inaceptable. Si el proveedor nos ofrece un SLA de 99.999%, esto significa que toleraríamos un corte de 8 horas al año. Mientras mejor es el SLA, mejor será el servicio y evidentemente, el servicio se encarece ya que el proveedor tendrá que invertir más en sistemas de contingencia. 2.5 Capacidad y planeación del crecimiento Otro importante aspecto que un Gerente debe gestionar es velar que la tecnología siempre responda a las necesidades del Negocio. Por ejemplo nunca debería suceder que nos quedemos sin espacio de disco duro, ni que los usuarios se queden sin ancho de banda o que el CPU del Servidor de Archivos esté al 90% de utilización. Para evitar esto, hay que estar continuamente monitoreando la capacidad de la tecnología y adelantarse a posibles circunstancias y tomar decisiones de renovar la tecnología o ampliar la capacidad. Ampliar la capacidad significa adquirir más GB de disco si nos estamos quedando sin espacio. También podría significar adquirir más memoria RAM si la memoria está quedando corta. Esto debe hacerse de manera planificada Veamos un ejemplo. Tenemos una compañía que experimenta un importante incremento en ventas en el mes de mayo. SI el Gerente de T.I. realiza un proceso de monitoreo de la capacidad, el grafico de utilización de memoria se vería de la siguiente manera:
Figura 9. Ejemplo de Uso de Memoria RAM. Fuente: Elaboración propia.
Como se puede observar en el ejemplo, el uso de la memoria va aumentando desde mayo hasta julio y que de seguir así nos quedaremos sin memoria en el mes de setiembre.
55
56
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
Por otro lado, la gestión de la capacidad también tiene que ver con no comprar más de lo necesario. Imagine que compramos un nuevo servidor con 32GB de RAM. Se instala el software y el software consume 8 GB casi de manera consistente. ¿Qué pasaría con los otros 24GB no utilizados? Pues son capital muerto, es decir son soles (o dólares) que gastamos y no utilizamos. 2.6 Satisfacción de usuarios. El Gerente de TI debe estar comprometido en lograr la satisfacción de los usuarios con los servicios que TI entrega. La forma más efectiva de saber cuál es la percepción de nuestros usuarios es… preguntándoles! Para ello, el Gerente de de los TI debe realizar de satisfacción periódicas grado de satisfacción usuarios con elencuestas servicio ofrecido por el área de TI. para saber de primera mano cual es el A continuación, presentaremos un ejemplo de encuesta:
Figura 10. Ejemplo de encuesta. Fuente: Elaboración propia.
2.7 Benchmarking. El benchmarking es una técnica de mejora continua. Consiste en comparar una materia o un proceso que se realiza dentro de la compañía y hacer la comparación entre como lo hacemos nosotros y como lo hace una compañía reconocida del país, de la región o mundial. En función a la comparación, se pueden muchas oportunidades demejora para que un Gerente deTI mejore su gestión. En el Perú esta no es una práctica muy establecida debido a que las compañías no comparten información entre ellas. Pero en otros países como en Estados Unidos, es normal que las compañías comparten su información. Dado que el modelo en Estados Unidos es que las compañías están basadas en accionistas, por la transparencia del Gobierno Corporativo, comparten mucha información la cual puede ser aprovechada para hacer benchmarking. 2.8 Gestión de cambios El área de TI maneja por su propia naturaleza muchos Sistemas. La infraestructura tecnológica, los sistemas informáticos son complejos sistemas que están funcionando en la Compañía. En su definición más simple, un Sistema es un conjunto de partes interrelacionadas y que interactúan con el propósito de lograr un objetivo, En este orden de ideas, un cambio a alguna parte de un sistema podría afectar al Sistema en su conjunto. Es muy frecuente escuchar a los usuarios decir que: “Los del área de TI o Sistemas cuando corrigen alguna cosa malogran otra cosa”. Estas situaciones se srcinan cuando se realizan cambios a los sistemas y estos cambios impactan en alguna otra parte, lo cual impacta a los usuarios de dicho Sistema.
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
Para responder a este reto, los Gerentes de TI deben implementar un Comité de Control de Cambios, en el cual se analicen los cambios a realizar, se revisen los riesgos, los impactos y se autoricen los cambios, y se tenga un plan de retorno a la situación anterior, en caso de que las cosas salgan mal. Esto significa que no se deben introducir cambios a los Sistemas sin un proceso formal. Lo que el gerente de TI debe promover son procedimientos estrictos de control de cambios y que todo cambio planificado se plasme en el Request for Change (RFC), que es el documento donde se deben registrar los cambios para su revisión por el Comité de Cambio (Change Advisory Board CAB por sus siglas en ingles). Veamos un ejemplo de un RFC:
Requerimiento para Cambio Fecha de 28-10-2015 Ingreso: Fecha de liberación:
Código RFC: Estado: En Proceso
Iniciador del Cambio:
Nombre: Apellidos:
Luis____________ Iberico__________
Correo: Área:
Tel.:
a@compañia.com____ Seguridad IT_________________
Descripción del Cambio (Razón de Negocio e Impacto) Detalle del Cambio – Estado Actual y Estado después del cambio Modificación en la configuración de la consola de administración de antivirus, dónde se deshabilitará la opción para que un usuario (con privilegios de administrador) pueda agregar excepciones desde el cliente antivirus instalado en su equipo. Beneficios de aplicar el cambio: Se soluciona una vulnerabilidad, denegando al usuario la posibilidad de agregar excepciones desde el cliente antivirus para ejecutar algún tipo de software
malicioso. Riesgo de no aplicar el cambio: La vulnerabilidad sigue vigente. Impacto en el Negocio: No S e r v i c i o s I m p a c ta d o s : Servicio
C o m p o n e n t e s I m p a c ta d o s : Antivirus Symantec de Perú.
Urgencia
Emergencia (Mismo Día) X Alta (Inmediata) o
O Media (Hasta 2 ventanas)
Baja (Mínimo 2 ventanas) o
Impacto o Alto
Impacto Alto ia c n e g r U
Me di o
Bajo
Alta
1
2
3
Media
2
3
3
Baja
3
4
4
o Bajo Prioridad = Urgencia x Impacto 1: Emergencia 2: Alta 3: Significante 4: Baja ó Estándar Consideraciones de Interrupción de Servicio:
X Medio
57
58
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
N.A Atributos del Despliegue: O ¿Se requiere el reinicio del Sistema? O ¿Se requiere el reinicio del servicio? X ¿El despliegue es automatizado? Ubicación de Planes de Liberación, Despliegue, Pruebas y Rollback: Insertar la ruta correspondiente de la ubicación de estos archivos según aplique. o Plan de liberación. Incluye los resultados de la evaluación de Software/ Hardware y el mecanismo de liberación. o Plan de Despliqegue. Incluye el Cronograma de distribución de paquetes. o Plan de Pruebas. Incluye los requerimientos mínimos de Pase o indicadores de falla en la prueba. Deben ser revisados antes del pase a producción.
Figura 11. Ejemplo de un RFC. Fuente: Elaboración propia.
2.9 Gestión Financiera Una de las principales preocupaciones de un Gerente de TI es optimizar los recursos. Es decir hacer más cosas con menos presupuesto. El Gerente de TI debe preocuparse de que exista un presupuesto, y que éste responda a las necesidades del Negocio. Asimismo. El Gerente de TI debe preocuparse por que los gastos de tecnología se carguen no solamente a TI, sino que se carguen contablemente a quienes utilizan la tecnología. Veamos un ejemplo. Considere que un Gerente de TI de una compañía que tiene 500 usuarios necesita comprar un nuevo switch para la red. En primer lugar, esta compra debería estar en el presupuesto. Si está en el presupuesto, entonces nos deberían aprobar la compra del Switch sin mayores problemas. Ahora la pregunta es: ¿Qué área debe asumir el gasto del Switch?. ¿El área de T.I.? Si le preguntamos a un usuario, nos responderá: Claro! Si es tecnología! Lo debe pagar T.I. !!! Ahora repensemos: ¿Quién o quienes utilizan el switch? ¿Es solo el área de TI? Por supuesto que no. El switch es utilizado por los usuarios de todas las áreas. Entonces, si lo utilizan todas las áreas, ¿Por qué solo lo debe pagar T.I.? Si no hay una adecuada gestión financiera, el Switch lo pagará contablemente el centro de Costos del área de T.I. El problema de esto es que si toda la tecnología que una compañía adquiere, se carga al Centro de Costos del área de T.I., terminaremos con que el área de T.I. es una de las áreas más gastadoras de toda la compañía. Muchas de las compañías cuando compran tecnología cargan todo el gasto de la tecnología al área de T.I. Es labor del gerente de T.I. educar a los ejecutivos de alto nivel de la compañía que si bien T.I. hace la adquisición, pero la utilización es de todas las áreas de la compañía y por tanto se debe cargar contablemente a todas las áreas de manera proporcional, el consumo del switch. El gerente de T.I. debe contar un presupuesto interno y comunicar a las demás áreas del presupuesto que deben considerar en sus presupuestos por la parte que les toca de los gastos de tecnología. 3
AUDITORIA AL GOBIERNO Y A LA GESTIÓN DE TI
3.1 La Auditoria Para auditar el Gobierno y la Gestión de TI, el Auditor debe conocer los conceptos de Gobierno y gestión de TI; así como las prácticas gerenciales presentadas en este tema. El Auditor debe recabar la documentación de Gobierno y Gestión, tal como planes, actas, presupuestos, contratos, reunirse con el Gerente de T.I. y los profesionales que le reportan al Gerente de T.I.
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
Con toda esta información y de acuerdo al Plan de Auditoria, el Auditor de Sistemas se enfocará en encontrar situaciones que puedan srcinar riesgos. 3.2 Situaciones que podría srcinar riesgos. A continuación presentaremos situaciones que generan riesgo: a) Planeamiento Estratégico - Falta de Plan Estratégico - Desactualización del Plan Estratégico - El Plan Estratégico de Sistemas no está alineado con los objetivos del negocio b) Comité de Sistemas - No Existe un Comité de Sistemas - Existe el Comité y no existen Actas de los Acuerdos c) Normatividad - No existe normatividad internad del área de T.I. - Existen algunos procedimientos, pero no hay normas - Existen algunas normas pero no hay políticas - Los documentos normativos están desactualizados d) Prácticas de Recursos Humanos - No existen prácticas de contratación de personal de T.I. - No existen prácticas de retención del talento - No se hace revisión de desempeño - No se hace segregación de funciones e) Gestión de la capacidad - No se monitorean la capacidad de los diversos recursos informáticos - Si se monitorea, no se toman acciones cuando los - Existen demasiados recursos informáticos f) Satisfacción de usuarios - No se mide la satisfacción de usuarios - No se toma acción sobre las encuestas realizadas. g) Benchmarking - No se realiza procesos de benchmarking
59
60
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
- No existe un proceso de mejora de los proceso de T.I. h) Gestión de cambios - Los cambios se realizan sin autorización - No se realiza un análisis de los impactos de los cambios - Si sucede un error, los usuarios son los que pagan las consecuencias. i) Gestión Financiera - No existe presupuestos de TI - Los presupuestos de las áreas no consideran los gastos de tecnología - Todos los gastos de tecnología son cargados a TI
LECTURA SELECCIONADA N.° 1: Leer artículo: De gerente de TI a CIO, una evolución necesaria en el Perú Santana Ormeño, M. (2011). De gerente de TI a CIO, una evolución necesaria en el Perú. Disponible en http://bit. ly/2bdRZE5
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
TEMA N.° 2: CONTINUIDAD DE NEGOCIO Y RECUPERACIÓN DE DESASTRES
INTRODUCCIÓN Este tema está enfocado en como efectuar una Auditoria de Sistemas a la Continuidad de Negocio y Recuperación de Desastres. 1
GESTIÓN DE LA CONTINUIDAD DE NEGOCIO 1.1 La dependencia de las compañías hacia la tecnología. A medida que las compañías utilizan más y más la tecnología, se vuelven más dependientes de ella. Casi todos los procesos de una compañía están soportados por tecnología. Aquí cabe preguntarse: Si las compañías son más dependientes de la tecnología ¿Qué pasaría con la compañía si la tecnología falla de manera prolongada? ¿Qué le puede pasar a una compañía si sus sistemas informáticos son interrumpidos por la ocurrencia de un desastre? Eso fue precisamente lo que sucedió el día 11 de setiembre del 2001 a muchas compañías. Ese día 2 aviones chocaron contra las dos torres gemelas en la ciudad de Nueva York en Estados Unidos, destruyendo ambos edificios. Ud. se ha preguntado qué pasó con las compañías que funcionaban en ambas torres. ¿Ese día fue el último día de las compañías? O podría ser que, ¿algunas compañías lograron sobrevivir a semejante desastre? La respuesta a esta interrogante es la Continuidad de Negocio y Recuperación de Desastres. La diferencia entre que una compañía cierre sus puertas o que logre superar un desastre es si ha implementado procesos de Continuidad de Negocio y Recuperación de Desastres. 1.2 Gestión de la Continuidad de Negocio. La Gestión de la Continuidad de Negocio es un proceso que le permite a una Compañía estar preparada ante la ocurrencia de un desastre, identificando potenciales impactos de amenazas a la compañía y proveyendo una estructura flexible y una capacidad de efectiva respuesta para continuar con las operaciones de la compañía. 1.3 Estándares internacionales. Para implementar este proceso, a nivel mundial existen marcos de referencia para la gestión de la Continuidad de Negocio. La principal norma es la norma ISO 22301:2012 Seguridad de la sociedad – Sistemas de gestión de la continuidad del negocio y se ha posicionado como el marco de referencia para gestionar la continuidad del negocio en una organización, para disminuir la posibilidad de ocurrencia de un incidente que impacte prolongadamente a una compañía y, en caso de producirse, que la compañía esté preparada para responder en forma adecuada y, de esa forma, reducir drásticamente el daño potencial de ese incidente. También existen otras normas realacionadas a la Continuidad de negocio tales como la NFPA 1600:2007 Standard on Disaster / Emergency Management & Business Continuit y la ISO/PAS 22399:2007 Incident Preparedness & Organizational Continuity.
61
62
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
1.4 Desastres Los desastres son interrupciones que ocasionan que una compañía quede inoperativa por un periodo de tiempo que impacte adversamente sus operaciones. Estas interrupciones obligan a la compañía a tomar acciones para recuperar el estado operativo en el que estaba antes del desastre. El srcen de los desastres puede ser: a) Naturales. Como por ejemplo terremotos, tsunamis, inundaciones, huaicos, huracanes, etc. b) Tecnológicos. Entre este tipo de desastres tenemos apagones, malware, fallas en la infraestructura, etc. c) Humanos. Por ejemplo un incendio provocado por un atentado, una huelga, entre otros. Ejemplos de desastres abundan. A nivel mundial tenemos, solo por citar algunos ejemplos: el derrumbe de las torres gemelas en Nueva York, el tsunami en el sudeste asiático, la epidemia SARS, el apagón a gran escala en el Noreste de USA y Canadá, los huracanes Katrina y Sandy, los terremotos en Japón, el desastre nuclear en Fukushima, etc. El Perú no es ajeno a los desastres. Por ejemplo tenemos al Fenómeno del Niño que causa lluvias torrenciales e inundaciones cada cierto número de años. Seguramente Ud. recuerda el terremoto en Pisco el año 2007. Ese terremoto afectó a muchas compañías entre las cuales figuran empresas de telecomunicaciones que al verse afectadas, afectaron a sus clientes. A continuación presentaremos unas vistas de cómo quedo la torre de una compañía de telecomunicaciones que comunicaba Ica con Lima
Figura 12. Situación de la torre de comunicaciones de la compañía Nextel en el terremoto de Pisco. Fuente: Nextel.
Figura 13. Vista lateral de la torre de comunicaciones de la compañía Nextel en el terremoto de Pisco. Fuente: Nextel.
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
63
Un desastre puede interrumpir las operaciones de una Compañía, lo que nos obliga a tomar acciones para estar preparados. 2
PLANEACIÓN A LA CONTINUIDAD DE NEGOCIO Y RECUPERACIÓN DE DESASTRES
Para hacer frente a los desastres, las compañías deben estar preparadas. El objetivo de la continuidad del negocio / recuperación de desastres es habilitar a un negocio para que continúe brindando sus servicios críticos en caso de desastre y que pueda sobrevivir a una interrupción por un desastre en sus operaciones y en sus sistemas de información. Repasemos el párrafo anterior. El objetivo no es evitar el desastre. No es posible evitar un desastre. ¿Cómo podríamos evitar que suceda un terremoto? ¿Cómo podríamos evitar la ocurrencia del fenómeno del niño? Lo que si puede hacer una compañía es estar preparada para recuperarse del desastre, es decir volver al estado en el que estaba antes de la ocurrencia del desastre. Esto es similar a un resorte. ¿Qué sucede si Ud. alarga un resorte? El resorte es flexible y se alarga. Ahora, ¿Qué pasa si suelta el reporte? El resorte vuelve a su estado anterior. Esto sucede por la propiedad de la resilencia del reporte. ¿Se imagina si las compañías fueran resilentes? Es decir si sucede un desastre, la compañía rápidamente (cual resorte) podrían volver a su estado normal. La Continuidad de Negocio ayuda a las compañías a volverse resilentes. 2.1 Componentes del BCP. Un Plan de Continuidad Negocios o Business Continuity Plan (BCP) es un plan que formula una compañía para estar preparada ante un desastre. Consta de varios planes, entre los que destacan 2 planes: a) Plan de Continuidad de Operaciones. Este plan es ejecutado por las áreas usuarias para continuar con la operación de los procesos críticos. Es decir, los procesos que no deben para en una compañía. Aquí las áreas para ejecutar sus procesos podrían usar sistemas stand-alone, hojas de cálculo o incluso procedimientos manuales a papel y lápiz para continuar con las operaciones críticas. b) Plan de Recuperación de Desastres. También conocido como Disaster Recovery Plan (DRP). Este plan es ejecutado por el área de T.I. y tiene como objetivo recuperar los recursos informáticos que soportan los procesos críticos de una compañía. Ambos planes se deben ejecutar en paralelo. Es decir, mientras las áreas usuarias trabajan en la continuidad de sus operaciones críticas (sin los sistemas informáticos), el personal de T.I. se enfoca en volver a la operatividad los recursos informáticos ejecutando el DRP. 2.2 Fases del BCP El plan de continuidad de Negocio y recuperación de desastres consta de 4 fases: a) Análisis de Impacto de negocio. Esta fase también conocida como Business Impact Analysis (BIA) está enfocada en identificar los procesos críticos de negocio, Es decir, hay que seleccionar de todos los procesos de la compañía a los procesos que no deben parar ya que afectarían severamente a la compañía. Estos procesos son los llamados procesos críticos. En esta fase también se identifican lasmétricas de tiempo de recuperación comoson el Recovery Point Objective (RPO), el RecoveryTime Objective. (RTO), el Maximum Tolerable Downtime (MTD) y el Work Recovery Time (WRT). – El RPO es la pérdida aceptable de datos en el caso de una interrupción de las operaciones. Ello indica el punto más anticipado en el tiempo al cual es aceptable recuperar los datos (ej. 4 horas). Esta métrica sirve
64
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
para definir la frecuencia de los respaldos (backups). Mientras más pequeño el RPO más esfuerzo y dinero se invertirá en los respaldos. – El RTO es el tiempo improductivo aceptable en el caso de una inte rrupción de las operaciones. Ello indica el punto más lejano en el tiempo en el que las operaciones de negocio deben retomarse después del desastre. Por ejemplo si una compañía puede tolerar 3 horas entonces su RTO es de 4 horas. El RTO puede ser calculado para cada proceso crítico del negocio identificado en el BIA. Mientras más pequeño el RTO más esfuerzo y dinero se invertirá en la estrategia de recuperación. – El MTD es el Tiempo durante el cual un proceso puede estar inoperante hasta que la empresa empiece a tener pérdidas y colapse. – El WRT es el Tiempo entre la recuperación del sistema y la normalización del procesamiento. Es el tiempo invertido en buscar datos perdidos y realizar reparaciones. En la siguiente figura se aprecian la relación entre los distintos indicadores:
Figura 14. Relación entre los tiempos de la recuperación de desastres. Fuente: Elaboración propia.
b) Estrategias de recuperación. Una vez que se han definido los procesos críticos de negocio y las métricas de recuperación, el siguiente paso es seleccionar una de las estrategias de recuperación. En T.I es imposible hablar de recuperación, si es que no se tiene un Centro de Datos de Respaldo. Existen 5 estrategias de recuperación: – Alta También como HighdeAvalilability (HA).enEsta estrategia es utilizada el RTODisponibilidad. es muy pequeño. Se trata conocida de tener un Centro Datos replicado tiempo real. Esto significacuando que si un dato es grabado en una Base de Datos en el Centro de Datos principal automáticamente se graba una copia en el Centro de Datos de Respaldo. – Hot Site. Consiste en tener un Centro de Datos alterno similar al Centro de Datos principal pero sin la replicación de los datos en tiempo real. – Warm Site. Es un Centro de Datos con equipamiento parcial o inferiores al Centro de Datos principal. Por ejemplo si una compañía hace renovación tecnológica de servidores, los servidores antiguoes pueden ser enviados al Centro de Datos Warm Site.
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
– Cold Site. Más que un Centro de dat os es una ubicación con la infraestructura básica (electricidad, cableado de datos) para soportar la recuperación, la cual se puede realizar trayendo los equipos necesarios para realizar la recuperación. – Acuerdo reciproco. Esta es una estra tegia a utilizar cuando la compañía no cuenta con recursos para implementar un centro de Respaldo. El Acuerdo indica que la compañía A puede utilizar al Centro de Datos de la compañía B en caso de un desastre y viceversa. Este acuerdo se puede firmar con una compañía “amiga” y que tenga una infraestructura informática similar a la nuestra. Ejemplo de ello podría ser compañías de un mismo grupo empresarial o en compañías del Estado. – Sitios Móviles: Esta es una estrategia en la cual se tien e un Centro de Datos móvil, el cual puede ser transportado a un lugar determinado que necesite un Centro de Respaldo. Por ejemplo podría ser útil en una mina o en caso de eventos deportivos. La siguiente figura ilustra un Sitio Móvil.
Figura 15. Ejemplo de Centro de Datos Móvil. Fuente: APC.
La selección de una estrategia depende del RTO, pero también del costo del Centro de Datos de recuperación. c) Desarrollo del Plan. Una definida la estrategia de recuperación Aquívez se deben considerar los siguientes puntos:ya se puede pasar a formular el Plan de Recuperación de Desastres. – Procedimientos de preparación antes de un desastre – Procedimientos de eva cuación – Procedimientos para declarar un desastre – Las circunstancias bajo las cuales se debe declarar un desastre. – La identificación de responsabilidades en el plan – La identificación de las personas responsables de cada función en el plan – La identificación de los diversos recursos requeridos para la recuperación y operación continua de la organización – Los Números de teléfonos y direcciones del personal crítico, de los proveedores, de los agentes de las compañías de seguros. – La explicación paso por paso de las etapas de recuperación. Asimismo, en el plan se definen los equipos que están involucrados en los procesos de Continuidad y recuperación de Desastres. A continuación se muestran los posibles equipos que se forman para – Equipo de acción ante emergencias – Equipo de evaluación de daños – Equipo administrador de la emergencia
65
66
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
– Equipo de almacenamiento alterno (Off-site) – Equipo de software – Equipo de aplicaciones – Equipo de seguridad – Equipo de operaciones de emergencia – Equipo de recuperación de la red – Equipo de comunicaciones – Equipo de Transportes – Equipo de hardware de usuario – Equipo de preparación de datos y registros – Equipo de soporte administrativo – Equipo de suministros – Equipo de salvamentos – Equipo de reubicación – Equipo de coordinación – Equipo de asuntos legales – Equipo de prueba de recuperación – Equipo de entrenamiento Como se puede apreciar en el plan se formulan los puntos necesarios para la continuidad y la recuperación. d) Pruebas y Actualización Una vez culminado el plan, este debe ser probado para saber si realmente funciona y saber si nos va a servir cuando suceda un desastre. En ese contexto, el plan debe ser probado. La dificultad reside en como probamos la ocurrencia de un desastre. En T.I. normalmente se realiza la prueba, cortando el suministro eléctrico al centro de Datos. Los resultados de las pruebas deben ser documentadas, y las mejoras detectadas deben ser incorporadas al plan. Es una buena práctica que al menos 2 veces al año se realicen las pruebas al plan. Finalmente se debe actualizar el Plan. El Gerente de T.I debe exigir que el Plan este permanentemente actualizado. El plan se debe actualizar cuando: – Cambios en la organización – Desarrollo o adquisición de nuevos recursos /aplicaciones – Cambios en la estrateg ia del negocio pueden alterar la importancia de las aplicaciones críticas o considerar como criticas aplicaciones adicionales.
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
– Los cambios en el software o ambiente de hardware No sirve de nada embarcarnos en la formulación del Plan para que cuando suceda el desastre nos demos con la sorpresa que esta desactualizado y no nos ayuda en la recuperación 3
AUDITORIA A LA CONTINUIDAD DE NEGOCIO
3.1 La Auditoria ISACA recomienda que para auditar la Continuidad de Negocio y Recuperación de Desastres, se debe verificar: • Entender y evaluar la estrategia de continuidad de negocios y su conexión a los objetivos de la Compañía • Revisar el BIA para asegurar que reflejan las prioridades de negocios • Evaluar el BCP para determinar si es eficaz. • Evaluar el almacenamiento de los respaldos • Evaluar la habilidad del personal para responder efectivamente en situaciones de emergencia • Revisión de los recursos informáticos incluidos en el plan • Determinar si todas las aplicaciones críticas han sido identificadas • Revisión de los equipos de continuidad de negocios • Verificar si el BCP apoya a la estrategia de continuidad de negocios • Evaluar la eficacia de los procedimientos para la ejecución del BCP • Evaluar los procedimientos de actualización • Evaluar los planes y si estos están escritos de manera sencilla y si son fáciles de entender • Pruebas del plan • Verificar que el plan este mantenido
3.2 Situaciones que podría srcinar riesgos. A continuación presentaremos situaciones que generan riesgo: a) Continuidad de Negocio. – No existencia de una estrategia de Continuidad de Negocio – Existencia de Plan de Recuperación de Desastres pero no del Plan de Continuidad de Operaciones. b) Análisis de Impacto – No determinación de procesos críticos – No determinación de los recursos informáticos críticos que soportan los procesos críticos – Definición incorrecta de las métricas: RPO y RTO
67
68
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
c) Estrategia de recuperación – Selección de estrategia que no guarda coherencia con el RTO – Centro de Datos no preparado d) Desarrollo del plan – Plan incompleto – Personal no entrenado en las actividades de recuperación – e)
Pruebas y Actualización
– Falta de realización de pruebas – Pruebas realizadas pero mejoras no incluidas en el Plan – Plan desactualizado
LECTURA SELECCIONADA N.° 2 Leer artículo: Lecciones aprendidas para la recuperación de desastres tras el 9/11. Mearian, L. (2011). Lecciones aprendidas para la recuperación de desastres tras el 9/11 [Sitio Web]. Disponible en: http://www.pcworld.com.mx/Articulos/18319.html,
ACTIVIDAD N.° 2 Participa en el Foro de discusión sobre las “Prácticas gerenciales en el área de Sistemas”.
INSTRUCCIONES
Revisa las prácticas gerenciales del área de Sistemas expuestas en el tema 1. Formula un ensayo sobre si está de acuerdo o no con las prácticas gerenciales mencionadas. Asimismo, plantea nuevas prácticas gerenciales que a su juicio deben ser revisadas por un Auditor de Sistemas.
TAREA ACADEMICA N.° 1 Esta actividad puede consultarla en su Aula virtual.
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
GLOSARIO DE LA UNIDAD II BCP. Acrónimo de Business Continuity Plan. Proceso de la Compañia que se formula para estar preparado ante la ocurrencia de un desastre que pueda afectar prolongada y adversamente los objetivos de una compañia. BIA. Acrónimo de Business Impact Analysis. Es una fase del proceso de Continuidad de Negocio en donde se identifican los procesos críticos de negocio y se definen las métricas de recuperación. Centro de Datos. También conocido como Data Center. Anteriormente conocido como Centro de Cómputo. Es la ubicación física donde residen la Infraestructura tecnológica como Servidores, dispositivos de red, equipos de comunicación que soportan los procesos de una compañía. Comité de Sistemas. Comité conformado por los Gerentes de Alto Nivel de una Compañía que se encargan de dar seguimiento al alineamiento de TI con los objetivos de la Compañía. DRP. Acronimo de Disaster Recovery Plan. Es el Plan seguido por el área de TI después de un desastre, para recuperar los recursos informáticos críticos. PEE. Acronimo de Plan Estratégico Empresarial. Es el Plan en donde una compañía define su visión, misión, objetivos y estrategias de negocio. PETI. Acronimo de Plan Estratégico de Tecnologías de Información. Es el plan que el área de TI sigue donde define su visión, misión, objetivos y estrategias, para apoyar en el cumplimiento del PEE. Proceso crítico. Proceso de la compañía que no debe parar ya que de hacerlo afectaría adversamente los objetivos de la Compañía. RTO. Acronimo de Recovery Time Objective. Es el tiempo improductivo aceptable en el caso de una interrupción de las operaciones. RPO. Acronimo de Recovery Point Objective. El RPO es la pérdida aceptable de datos en el caso de una interrupción de las operaciones Stand-Alone. Equipo informático (PC o laptop) que no cuenta con acceso a la red, f uncionando de manera individual.
BIBLIOGRAFÍA DE LA UNIDAD II Information systems audit and control association. (2016). CISA Re-view Manual. Chicago: ISACA.
69
70
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
AUTOEVALUACIÓN DE LA UNIDAD II 1. Ud. esta auditando la gestión de proyectos de un área de Sistemas e identifica que la lista de espera de proyectos es mayor a 6 meses. Esto srcina conflictos entre las distintas áreas para lograr que Sistemas priorice sus proyectos ¿Cuál es el mecanismo más eficaz que Ud. recomendaría como auditor para atender y priorizar las distintas necesidades de las áreas usuarias? A) Gestión de Proyectos B) Plan Estratégico C) Comité de Sistemas D) Evaluación de desempeño
2. Ud. esta auditando los temas relacionados a la gestión del personal de un área de sistemas de una empresa pública y encuentra que los gerentes de las áreas de desarrollo, mantenimiento y soporte técnico, son familiares directos del Gerente de Sistemas. Ud. encuentra que el principal riesgo de esto es: A) Demasiada confianza entre el personal B) Denuncias por nepotismo C) Fuga de Información D) Denuncias por malos manejos
3. ¿Cuál de las siguientes no es necesariamente una ventaja de la tercerización? A) Enfocarse en el core del negocio B) Perder experticia especializada C) Reducir costos D) Mejorar los Acuerdos de Nivel de Servicio (SLA)
4. Un programador trabaja en el área de soporte de aplicaciones. En esta área, el personal da soporte a las aplicaciones e interactúa directamente con los usuarios de las diversas aplicaciones. Para dar soporte oportuno, se realiza diariamente una copia de la BD de producción a la BD de soporte. ¿Cuál es el principal riesgo de esta situación? A) Falla del Sistema de Información B) Fuga de Información C) Modificación de registros en la Base de Datos D) Eliminación de registros de la Base de Datos
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIÓN DE TI
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
5. Ud. encuentra que todos los gastos de tecnología son cargados al Centro de Costos del área de Sistemas. Esta situación coloca al área de sistemas como el área que más gasta de la empresa ¿Cuál de las siguientes recomendaría un Auditor para una eficaz gestión financiera de IT? A) Reducir los costos de hardware y software B) Trasladar los gastos relacionados al uso de tecnología a las áreas usuarias C) Realizar múltiples versiones de presupuestos D) Comprar un software con mantenimiento a 3 años para lograr economía de escala
6. Ud. está realizando una auditoria a la planeación del área de sistemas. En ese sentido, Ud. solicita al Gerente de Sistemas una copia del Plan Estratégico de Tecnología de Información (PETI). La principal preocupación del auditor al revisar este documento es que el PETI debe: A) Orientarse al logro de los objetivos de la empresa B) Reducir eficientemente los costos C) Contar con la lista de proyectos de sistemas D) Contar con un análisis FODA E) Orientarse a soportar el aumento de las ventas de la empresa
7. ¿Cuál de las siguientes afirmaciones es verdad en relación al Recovery Time Objective (RTO) y el Recovery Point Objective (RPO)? A) EL RPO y el RTO mientras más pequeños es más caro. B) EL RPO y el RTO mientras más pequeños es más barato C) El RPO y RTO deben ser iguales D) El RPO siempre debe ser mayor al RTO
8. Ud. esta auditando el Plan de Continuidad de Negocios de Supermercados Kong y está revisando el Plan para determinar si se realizó una adecuada selección de la estrategia de recuperación. ¿Cuál de los siguientes sería el criterio principal para la determinación de una estrategia de recuperación? A) Recovery Point Objective (RPO) B) Recovery Time Objective (RTO) C) Dispinibilidad de los backups D) Disaster Recovery Plan (DRP)
9. Ud. está revisando la documentación del Plan de Continuidad de Negocio de la compañía minera AntraxMina. ¿Cuál de las siguientes no sería un documento a considerar en la revisión: A) Disaster Recovery Plan (DRP) B) Políticas de Seguridad
71
72
C) Business Impact Analysis (BIA) D) Plan de Continuidad de Operaciones (PCO)
10. En el contexto de la continuidad de negocio, ¿Cuál de los siguientes no es considerado un desastre? A) Un terremoto B) Desastres naturales como por ejemplo el fenómeno del niño C) Infección de un spyware D) Error del administrador como por ejm. el borrado de una BBDD crítica.
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
UNIDAD III: AUDITORÍA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE
UNIDAD III: AUDITORÍA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE
DIAGRAMA DE PRESENTACIÓN DE LA UNIDAD III CONTENIDOS
EJEMPLOS
AUTOEVALUACIÓN
ACTIVIDADES
BIBLIOGRAFÍA
ORGANIZACIÓN DE LOS APRENDIZAJES C O N O C I MI EN TO S
5° Videoclase (Video conferencia) Tema N.° 1: Etapas del ciclo de vida de Desarrollo de Software 1. Etapas del ciclo de vida 2. Controles de entrada, procesamiento y salida en el Software Tema N.° 2: Mantenimiento de Sistemas 1. Procedimiento de control de cambios Lectura seleccionada 1: Título: Ciclo de Vida del Software. disponible en: http://static.ccm2.net/es.ccm.net/ contents/pdf/ciclo-de-vida-del-software-223k8u3gm.pdf 6° Videoclase Tema N.° 3: Aplicaciones de Negocio 1. Medición, análisis y mejora 2. Seguimiento y medición 3. Control del producto No conforme 4. Análisis de datos. Mejora Tema N.° 4: Auditoria al ciclo de vida 1. Auditoría a ciclo de vida de desarrollo 2. Auditoría al mantenimiento de Sistemas Lectura seleccionada 2: Título: ¿Qué es big data?. Disponible en: https://www.ibm.com/developerworks/ssa/ local/im/que-es-big-data/ Autoevaluación Nº 3
P R O C ED I MI EN TO S
1. Identifica los riesgos de cada una de las fases del ciclo de vida de desarrollo de sistemas. 2. Identifica las metodologías y prácticas de pruebas relacionadas con el desarrollo de sistemas de información. 3. Identifica los procedimientos de cambios en los sistemas 4. Aplica los controles en el software. Actividad N.° 3 Participan en el Foro de discusión sobre las “riesgos en el desarrollo de software”.
1. Identifica los principales componentes de las Aplicaciones de Negocio 2. Identifica los riesgos de las Aplicaciones 3. Formula hallazgos de auditoria de Sistemas sobre el ciclo de vida y el mantenimiento de sistemas. Control de Lectura Nº 2 Evaluación escrita de los temas N.° 1,2,3, y 4 , más los contenidos de las lecturas seleccionadas 1 y 2 de la Unidad III.
A C T I TU D E S
1. Valora la importancia de la ejecución de la auditoria de sistemas. 2. Se auto valora por su aprendizaje de las técnicas de auditoria de sistemas. 3. Asume el compro-miso de revisar los contenidos del manual. 4. Valora la importancia de la auditoria de sistemas para el mejora-miento de una empresa y para las actividades o procesos
a realizar. 5. Participa activamente en el desarrollo de las actividades de la asignatura.
73
74
UNIDAD III: AUDITORÍA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE
TEMA N.° 1: ETAPAS DEL CICLO DE VIDA
INTRODUCCIÓN En este tema abordaremos el amplio mundo del desarrollo del software. Las compañías gastan cientos de miles de dólares en los procesos de desarrollo del software y es conocido que todo desarrollo de software conlleva riesgos, los cuales deben ser revisados adecuadamente por los Auditores de Sistemas. También abordaremos el mantenimiento de Sistemas y los procedimientos que los Auditores toman en cuenta para asegurar que los cambios al software existente no introduzcan nuevos riesgos a las compañías. 1
CICLO DE VIDA DE DESARROLLO DE SOFTWARE
1.1 Etapas del Ciclo de Vida Tradicional Muchas compañías utilizan el Ciclo de Vida tradicional para el desarrollo del software. Este ciclo de vida ha sido utilizado durante muchos años y es muy probable que un Auditor de Sistemas se tope con este ciclo de vida. El Ciclo de Vida tradicional consta de fases secuenciales, tal como se muestra en la figura 1.
Figura .16. Etapas genéricas del Ciclo de Vida de Desarrollo de Software.
Como se puede apreciar en la figura 1, el Ciclo de Vida considera actividades de adquisición de software. Ud. podría preguntarse qué hace la adquisición en un ciclo de vida de desarrollo. Esto es lógico ya que mucho del software ya se encuentra escrito y podría ser muy ventajoso adquirir software en lugar de construirlo.
UNIDAD III: AUDITORÍA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
A continuación, daremos una revisada a las fases del Ciclo de Vida: 1.2 Estudio de Factibilidad El estudio de factibilidad es la primera etapa de un ciclo de vida de desarrollo de software. En esta etapa se realizan las siguientes actividades: • Definir los beneficios tangibles e intangibles del futuro sistema. Los beneficios tangibles siempre están relaciona-
dos a dinero e incluyen ahorro de costos, incremento de las ventas, reducción de personal (suena feo, pero es un beneficio tangible), entre otros. Los beneficios intangibles incluyen mejora en los procesos, rapidez en la entrega de productos o servicios, etc. • Determinar el costo y tiempo aproximado para implementar el sistema. Se debe tener una idea de cuánto costaría
y cuánto tiempo podría tomar implementar la solución. Una buena práctica seria formular un Request for Information (RFI) y enviarlo a proveedores. Este documento solicita a los proveedores que indiquen las capacidades que tienen sus sistemas y nos permite tener una idea inicial de que existe en el mercado y cuánto tiempo y dinero costaría. • Escribir el Business Case (Caso de Negocio). El Business Case es un documento importante en el que se deben defi-
nir las alternativas existentes para implementar el sistema. Por ejemplo un Business Case podría tener 4 alternativas: – Mejorar el software existente – Desarrollar un nuevo software – Adquirir el software del proveedor A – Adquirir el software del proveedor B Dado que se tienen alternativas, se puede tomar una decisión de que alternativa seguir. Recuerde que tomar una decisión es seleccionar una alternativa entre varias alternativas posibles. • Determinar si es necesario desarrollar o adquirir
1.3 Requerimientos El análisis de requerimientos es la etapa más importante del ciclo de vida (Alguien dijo curso de Ingeniería de Requerimientos). Dado que el software a construir es intangible (no se puede tocar, no se puede sentir), no es lo mismo construir software que construir un tangible como por ejemplo un edificio. Muchos de los proyectos de desarrollo de software fracasan por que no se logra un entendimiento claro de los requerimientos de los usuarios, por lo que es vital la participación de los usuarios. En esta etapa se realizan las siguientes actividades: • Detallar el problema o necesidad que requiere solución. • Identificar y consultar a todos los interesados para identificar sus requerimientos. • Identificar los requerimientos funcionales y no funcionales (de calidad, de seguridad, etc.). • Convertir los requerimientos de los usuarios en requerimientos de sistemas. • Analizar los requerimientos para detectar y corregir conflictos y determinar prioridades. • Verificar que los requerimientos están completos, consistentes, probables y rastreables. • Determinar si se va a desarrollar el sistema o adquirir un sistema ya existente.
75
76
UNIDAD III: AUDITORÍA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE
1.4 Diseño En caso de que se decida desarrollar, entonces la siguiente fase será la de diseño. La fase de diseño solo puede hacerse después de que se tenga definidos claramente los requerimientos. En esta fase es muy común utilizar algún lenguaje de modelado de software tal como el Unified Modeling Language (UML) para diseñar, especificar, desarrollar y documentar un sistema. En esta etapa se deben formular las siguientes actividades: • Especificaciones de los componentes del Sistema • Especificaciones de las interfaces del Sistema • Especificaciones de los programas • Especificaciones de los datos
La fase de diseño es equivalente a realizar un plano en la construcción de un edificio. El plano indica cómo será el edificio. De manera similar en la fase de diseño se construyen los planos para realizar un software. El plano no puede estar cambiando por lo que es imprescindible implementar un procedimiento de control de cambios para prevenir que se creen nuevos requerimientos o se modifiquen los requerimientos sin control. 1.5 Adquisición del Software En caso de que se decida no desarrollar, entonces la siguiente fase después de la fase de Requerimientos es la fase de Adquisición del software. Al igual que la fase de Diseño, la adquisición de software solo puede ocurrir después de cerrar la fase de requerimientos, ya que no podemos adquirir un software sin saber lo que necesitamos. En esta etapa básicamente se prepara el Request For Proposal ( RFP). El RFP es un documento que contiene todos los requerimientos funcionales y no funcionales que necesitamos adquirir. Asimismo, el RFP contiene los requerimientos técnicos, operacionales y de soporte por parte del proveedor. El RFP es enviado a todos los proveedores para que puedan enviar sus propuestas. Una vez que se tienen las propuestas se debe comparar las propuestas y seleccionar la propuesta más conveniente. Es común que las propuestas sean evaluadas en función a su peso técnico y económico. Por ejemplo la evaluación técnica puede pesar 70-80% y la evaluación económica puede pesar 20 % - 30 %. Una vez declarado ganador, se debe firmar el contrato con el proveedor, el cual debe tener las penalidades adecuadas, en caso de un incumplimiento por parte del proveedor. 1.6 Desarrollo Esta fase es la continuación de la fase de Diseño. Con los documentos de especificaciones de diseño, se realiza la codificación utilizando diversos métodos, técnicas y lenguajes de programación. Es muy común que los desarrolladores utilicen ambientes integrados de desarrollo integrado (IDE) que facilitan la programación del código fuente. En esta etapa se debe considerar las pruebas que garanticen la calidad del software construido. No se puede conceptualizar desarrollo sin pruebas. Las pruebas son inherentes al desarrollo (por ese motivo no existe una fase de pruebas). Una pregunta que se debe hacer en esta fase es: ¿Cuánto tiempo se le debe dedicar a las pruebas? ¿Cuál es la relación optima de tiempo entre el desarrollo y las pruebas? Por ejemplo si tomo 1 mes para codificar, ¿Cuánto tiempo se debe estimar para las pruebas? Muchas compañías le dedican el 20% a la codificación y el 80% del tiempo a las pruebas. Eso significa que si se estima un mes para la codificación, se debería tener 4 meses de codificación. Ahora le pregunto ¿Ud. considera que esta bien la relación 20%–80% ¿ Está un poco exagerada? ¿Será esta la práctica de los desarrollos de software en el país? Lo cierto es cada equipo de desarrollo tiene sus propios estándares. Pero, no dedicarle suficiente tiempo a las pruebas hace que muchos proyectos de desarrollo de software no logran la suficiente calidad, y eso genera muchos riesgos en el ciclo de vida.
UNIDAD III: AUDITORÍA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
Entre las pruebas que se deben considerar se tiene: •
Prueba unitaria. Consiste en probar un único programa. Esta es la prueba que los desarrolladores normalmente
realizan cuando verifican sus programas. •
Prueba de interface o de integración. Esta prueba verica que la información uya correctamente entre varios
componentes del software. •
Prueba del sistema. Las pruebas de sistema indican si diversos componentes de un Sistema funcionan de manera
colectiva. • Pruebas de recuperación. Verifican que el software funcione adecuadamente después de una falla de hardware o
software.
• Pruebas de seguridad. Verifican la seguridad de un software. • Pruebas de estrés/volumen. Verifican la performance de un software con grandes volúmenes de datos. • Pruebas de volumen. Determina el número máximo de transacciones que un software puede procesar. • Pruebas de Stress. Determina el número máximo de usuarios / servicios que un software puede procesar. • Pruebas de rendimiento. Compara el rendimiento de un software a otros sistemas equivalentes usando benchmarks
definidos. • Pruebas de aceptación final – User Acceptance Test(UAT). Esta prueba se da en la fase de implementación, donde
el usuario aprueba la funcionalidad de un sistema. Existe un conjunto grande de pruebas. Otro tipo de pruebas incluyen: •
Alfa y beta. Esta prueba es utilizada por los fabricantes de software. La prueba Alfa es una primera prueba interna
y el software podría no estar completamente terminado. La prueba Beta es una prueba con el software terminado y enviada a un grupo de usuarios externos para que prueben el software en condiciones reales. •
Piloto. Esta es una prueba para probar una parte especíca de un sistema.
•
Caja blanca. Evalúa la efectividad del código fuente de un sistema.
•
Caja negra. Evalúa la efectividad funcional de un sistema.
•
Función/validación. Evalúa la funcionalidad de un sistema contra los requerimientos para vericar que se esté
construyendo e software de acuerdo a los requerimientos. •
Regresión. Esta prueba está orientada a probar nuevamente funcionalidades cuando se introducen cambios o co-
rrecciones a un sistema. Esta prueba verifica que no hayan impactos no deseados en otras partes del software. •
Paralela. Esta prueba consiste en probar dos sistemas, normalmente el viejo sistema y el nuevo sistema para com-
parar los resultados. •
Sociabilidad. Esta prueba consiste en vericar que un cambio en un software no afecta a otros sistemas. Es decir
que el sistema “es amigo” de los demás sistemas y no genera conflictos con los otros sistemas. Todas las pruebas deben ser planificadas y se debe realizar un Plan de pruebas. Las pruebas deben ejecutarse y documentar los resultados de las pruebas. Los errores y fallas deben ser incorporados en el desarrollo. 1.7 Configuración La fase de Configuración es la fase que continua después de la adquisición del software (en caso que se decidió adquirir un software). En esta etapa se adecua el software para que funcione según los requerimientos de la Compañía.
77
78
UNIDAD III: AUDITORÍA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE
Normalmente esto se basa en cambiar los parámetros del software evitando así tener que hacer cambios en el código fuente del sistema a adquirir. Para ello el software a adquirir debería ser lo suficientemente flexible para permitir configurar y personalizar el software. En esta fase, cabe la pena preguntarse: ¿Hay que adecuar el software a la compañía o adecuar la compañía al software? En líneas generales esta pregunta genera muchas y acaloradas discusiones. En mi opinión cuando se adquiere un software, este software ya fue implementado decenas, cientos o incluso miles de veces en compañías anteriores, por lo que el software trae muchas buenas prácticas. No siempre la forma como opera una compañía es la mejor y hacer que el software se adecue a la compañía podría generar automatización de procesos no optimizados, por lo que de preferencia la compañía debería adecuarse al software. De esa manera el software se utilizaría en su versión estándar y fortalecería el soporte del fabricante del software. Asimismo, es una práctica normal de las compañías construir interfaces entre el software adquirido con los software existentes. 1.8 Implementación En la fase de implementación se establece y la operación efectiva del nuevo sistema. Antes de la implementación, el usuario ha aceptado la funcionalidad del sistema a través de la prueba de aceptación del usuario final (UAT). 1.9 Revisión Post-Implementación Normalmente los proyectos de desarrollo de sistemas de información culminan en la fase de Implementación. Sin embargo es vital que se considere la fase de Revisión de Post-Implementación. Esta revisión es una oportunidad no aprovechada por el área de T.I. para demostrar los beneficios que el Software brinda a la Alta Dirección de la Compañía. Los beneficios se presentaron en la etapa de Estudio de factibilidad. Nosotros, lo de T.I. presentamos un business case con la opciones para que nos aprueben el proyecto. Sin embargo, una vez que el proyecto es autorizado, comenzamos a trabajar y al finalizar el software nunca nos preocupamos por dar a conocer los beneficios (tangibles e intangibles) que se lograron. Una vez que culminamos un software nos dedicamos a construir el siguiente software y nunca nos damos un tiempo para medir los resultados de nuestro sistema. Mientras más presentemos los resultados logrados, más fácil será conseguir recursos para el siguiente proyecto. Sin embargo, si entregamos un software y no “vendemos” los logros resultantes, perdemos una excelente oportunidad para demostrar los beneficios que el software logro. En esta fase se deben considerar las siguientes actividades: •
Evaluar si el sistema es adecuado
•
Evaluar los costos/benecios o el Retorno sobre Inversión (ROI) proyectados.
•
Elaborar recomendaciones de los aspectos inadecuados que se dieron en el proyecto de desarrollo.
•
Obtener las lecciones aprendidas que serán aplicadas en los siguientes proyectos.
El Ciclo de vida de desarrollo de software tradicional no es el único. Algunos autores manifiestan que el ciclo de vida de desarrollo del software tradicional no es apropiado para procesos de desarrollo de software con poco tiempo para entregar el software. En ese sentido, existen procesos de desarrollo de software incremental e iterativo que se componen de tareasen pequeñas repetitivas. procesos lo constituyen el desarrollo el desarrollo espiral yetapas el desarrollo ágil. Ejemplo De estos de 3, el procesoiterativos más popular es el desarrollo ágil conevolucionario, el framework scrum como referente. 2
CONTROLES DE ENTRADA, PROCESAMIENTO Y SALIDA
El software que desarrollamos debe ser a “prueba de balas”. Eso significa que adicional a que debe cumplir con los requerimientos funcionales y no funcionales, debe garantizarse que el Sistema no permita el ingreso de datos incorrectos, que los procesos sean exactos y proteger los reportes emitidos por el Sistema.
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
UNIDAD III: AUDITORÍA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE
2.1. Controles de Entrada Para evitar que se ingresen datos incorrectos, incompletos o inconsistentes, los formularios de entrada de datos deben tener controles de validación. ISACA recomienda que se consideren los siguientes controles para validar los datos: Tabla 3 Lista de controles de validación de entrada de datos. N O.
P A R Á M E TR O
DESCRI PC I ÓN
1.
Verificación de limite
Un dato no debe ser menor a, o mayor a un determinado valor. Ea decir debe estar dentro de un límite. Por ejemplo el monto total de una factura de una compañía que vende autos no puede ser menor que USD 7,000.
2.
Verificación de rango
Un dato debe estar dentro de un rango de valores predeterminados. Por ejemplo la edad de una persona debe estar entre 18 y 100 años.
3.
Verificación de validez
Verificación de la validez de un dato en conformidad con valores predeterminados. Por ejm. el campo estado civil puede aceptar los valores C, S, V, o D.
4.
Verificación de razonabilidad
El dato es comparado para determinar límites razonables o tasas de ocurrencia predeterminadas. Por ejm. La edad de una persona no puede ser mayor a 100 años.
5.
Verificación de coincidencia
Los datos ingresados deben coincidir con valores almacenados en una tabla. Por ejm. códigos Postales
6.
Dígito de control
Un valor numérico calculado por un algoritmo y que permite asegurar la integridad de un dato. Este control es efectivo para detectar la transposición de los caracteres de un campo. Por ejm. La verificación del RUC debe ser realizada con el algoritmo Modulo 11 modificado (El ejemplo aplica para Perú).
7.
Verificación de obligatoriedad
Un campo debe contener datos válidos, según el tipo de campo que se está ingresando.
8.
Verificación de datos duplicados
Una transacción nueva es comparada con transacciones anteriores para asegurar que no hay sido introducida previamente. Por ejm. Un pago de una factura a proveedores se compara con pagos anteriores de la misma factura para asegurar que el pago no este duplicado.
9.
Relaciones con otros campos
Un campo depende de un valor en otro campo. Por ejm: si se selecciona Cliente Persona Natural, entonces se debe validar que el campo RUC empiece por 10. (El ejemplo aplica para Perú).
2.2. Controles de procesamiento Los controles de procesamiento están orientados a garantizar que los cálculos de los algoritmos internos del Sistema sean correctos, asegurando la exactitud de los datos acumulados por los diversos procesos internos en un Sistema. Ejemplo de un control de procesamiento lo constituye una verificación del cálculo de un algoritmo, usando otro mecanismo de cálculo para verificar el resultado. Por ejemplo verificando que el resultado de un cálculo con una comprobación a través de una sentencia SELECT. Considere el sgte. Algoritmo: suma = 0 While i < = 10 Suma = suma + valor [i] endwhile Una manera de comprobar el resultado es verificando la suma con el comando SELECT:
79
80
UNIDAD III: AUDITORÍA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE
SELECT SUM (valor) from tabla where elemento < = 10 Existen muchas formas de verificar los cálculos dentro de un Sistema de Información. Por ejemplo: • Rutinas de recalculo después de que los cálculos han sido ejecutados • Comprobar los totales cada vez que se inicia una nueva rutina. • Controles programados para detectar inconsistencias. • Verificaciones de límite o rango, similares a los controles que vimos en la entrada de datos.
2.3. Controles de Salida Los controles de Salida están orientados a proveer que los datos entregados a los usuarios serán presentados, formateados y entregados en una forma consistente y segura. Los controles de salida a implementar en un Sistema de información incluyen: • Generación automatizada de Instrumentos Negociables, Formularios y Firmas. Si el Sistema emite acciones, che-
ques, warrants,o cualquier otro instrumento negociable, se debe asegurar que dichos reportes no sean modificados. Por ejemplo si se emite un cheque se debe emitir astericos antes y des pues de la cifra: ****1,315.00***** Otro ejemplo seria no imprimir una Tarjeta de Crédito completa. Podría reemplazarse partes de la tarjeta de crédito con asteriscos. • Manejo de Errores en las Salidas. El Sistema debe tener controles para evitar que no se emita un y que ningún re-
porte se pierda. Por ejemplo controlar las numeraciones de la facturas. También se deben seguir controles de salida físicos. Todos los controles en un Sistema Informático se pueden venir abajo si es que al imprimirse un reporte con información sensible no se toman las medidas físicas necesarias para proteger la información impresa. Entre las medidas físicas a considerar tenemos por ejemplo: • Registro y Almacenamiento de Formularios Negociables, Sensitivos y Críticos en un Lugar Seguro. Este control
evitara la sustracción o robo de reportes que contengan valores. • Distribución de Reportes. Los reportes críticos deben ser distribuidos de manera segura. Por ejemplo si es un estado
de cuenta, debe ensobrarse. Ahora existen maquinas que imprimen y ensobran automáticamente. • Retención de Reportes. Los reportes con información sensible que pierdan su vigencia deben ser destruidos. La
destrucción debe considerar las leyes y regulaciones sobre retención de documentos que pudiesen existir. • Verificación de Recibo de los Reportes. En caso de que se entreguen reportes a determinadas personas, siempre es
preferible hacerlas firmar un acuse de recibo de que han recibido el reporte. En resumen, los controles deben existir durante el ingreso, el procesamiento y la salida de los sistemas de información. Un error muy común que cometen los desarrolladores de software es considerar únicamente controles de entrada. Ahora ya sabemos que se deben considerar todos los controles posibles dentro de un sistema de información.
UNIDAD III: AUDITORÍA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
TEMA N.° 2: MANTENIMIENTO DE SISTEMAS
INTRODUCCIÓN Una vez que un Sistema de Información está funcionando (en producción), el Sistema sufre muchos cambios debido a la demanda de los usuarios. En un mundo ideal, los usuarios solicitan cambios que mejoran las funcionalidades del Sistema de Información. Sin embargo, también se pueden dar cambios para corregir funcionalidades defectuosas del Sistema de Información. Desde el punto de vista de Auditoria, los cambios no deben introducir nuevos riesgos. 1
MANTENIMIENTO DE SISTEMAS
Las estadísticas indican que el Mantenimiento de Sistemas representa aproximadamente el 80% del ciclo de la vida útil de un Sistema de Información. Esto significa que los costos y tiempo consumidos en el proceso de ciclo de vida de desarrollo del Sistema de Información representa solamente el 20%. Los fabricantes de software saben que el negocio está en el mantenimiento de software más que en el desarrollo de software. Cuando un sistema de información está en funcionamiento, se requieren de nuevas funcionalidades, upgrades, y mejoras que son parte del mantenimiento de sistemas. 2
PROCEDIMIENTO DE CONTROL DE CAMBIOS.
Cuando se realiza un cambio a un Sistema de Información, éste podría afectar adversamente el funcionamiento de un Sistema. Es por ello que cualquier cambio debe ser minuciosamente analizado a través de un proceso de control de Cambios. El Control de Cambios es uno de los procesos de ITIL (Information technology Infrastructure Library). Básicamente este proceso trata de que un cambio pase por un proceso de autorización y revisión antes de su implementación para verificar que el cambio no introduce riesgos ni impactos no deseados. En una compañía donde no existe un proceso de control de cambios, cada persona de IT hace cambios directamente a los sistemas. Esto no solo aplica para el equipo de desarrollo de software. Por ejemplo la gente de redes podría agregar nuevos segmentos de red, o cambios en las redes o routers; la gente de Base de Datos podría modificar objetos dentro de una Base de Datos, la gente de Servidores realizar cambios en la configuración de uno o más servidores. Como se podrá intuir, un cambio en un componente podría afectar a otros componentes de la Infraestructura e impactar adversamente en el servicio ofrecido por IT. Entonces, queda claro que se necesita un proceso de control de cambios en el cual todo cambio requiere de una serie de actividades y controles hasta que el cambio finalmente pasa a producción. A continuación presentaremos un conjunto de pasos a seguir (se asume que se trata de una empresa grande) a) El usuario solicita un cambio a través de una solicitud de cambio (En inglés Request for Change RFC). b) El líder del área evalúa la necesidad del cambio. c) El líder aprueba la necesidad del cambio. d) El Gerente del área autoriza el cambio (y el costo). e) El área de Desarrollo de Software recibe la solicitud de cambio. f) El área de Desarrollo dimensiona el tiempo y costo del cambio. g) El Analista de Sistemas escribe la especificación en base a la solicitud de cambio.
81
82
UNIDAD III: AUDITORÍA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE
h) El programador escribe los cambios en el código fuente. i) El Analista de Calidad de Software evalúa los cambios. j) El usuario revisa la funcionalidad k) El usuario firma el User Aceptation test (UAT) autorizando el cambio Este proceso de control de cambios puede variar en función al tamaño de la compañía, a la formalidad de los procesos de la compañía, a la cantidad de personas que laboran en el área de Sistemas, a la segregación de funciones del área, entre otros. 3
IMPLANTACIÓN DE CAMBIOS
Una vez que el cambio es aprobado por el usuario (o por la Gerencia del usuario), el cambio está listo para ser pasado al ambiente de producción. El usuario obtiene por fin su cambio! 4
DOCUMENTACIÓN
Para asegurar el mantenimiento futuro del sistema, toda documentación relevante debe ser actualizada. Un error muy común es que los cambios no son acompañados de la correspondiente documentación. Debido a que los cambios en un sistema se necesitan “para ayer”, es común sacrificar la documentación. El mantener un sistema sin la documentación actualizada introduce riesgos de que los cambios se demoren un mayor tiempo, ya que el programador necesita entender el código fuente. 5
CAMBIOS DE EMERGENCIA.
Imagine una situación donde un Sistema de Información falle y se necesite corregir este error inmediatamente. En este caso, sería muy engorroso seguir el procedimiento de control de cambios del punto 1.1 y seguir todos los pasos, obteniendo todas las autorizaciones y cumplir con todos los controles requeridos. En una situación de emergencia, es posible que los programadores puedan tener acceso tanto a la Base de Datos como al repositorio de los programas fuente del ambiente de producción de manera controlada. Muchas compañías por ejemplo disponen de unos sobres cerrados y lacrados, los cuales solamente serán abiertos cuando se tenga un caso de emergencia. Dentro de los sobres se tienen usuarios y contraseñas, las cuales podrán ser utilizadas por un programador para corregir una situación en un programa o en una Base de Datos. Evidentemente estos usuarios y contraseñas tienen una caducidad muy corta y son sujetos a pistas de auditoria, de tal manera que se pueda rastrear todos los cambios realizados en esta situación de emergencia. 6
RAZONES POR LAS QUE SUCEDEN LOS CAMBIOS NO AUTORIZADOS
Un cambio no autorizado a un sistema de información puede srcinarse por varias razones: • El programador tiene acceso a las carpetas de producción que contiene los programas, incluyendo el código fuente • • • • • •
y el código objeto. El usuario responsable de la aplicación no estaba al tanto del cambio (el usuario no firmó la solicitud de cambio (RFC) No existe un procedimiento formal. El Gerente que debía autorizar no firmó la solicitud de cambio aprobando el inicio de los trabajos. El usuario solicitante no firmó el formulario de aceptación de cambio (UAT). El código fuente modificado no fue revisado adecuadamente. El programador puso un código extra para beneficio personal (es decir, cometió fraude).
UNIDAD III: AUDITORÍA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
LECTURA SELECCIONADA N.° 1: Leer el artículo: Ciclo de Vida del Software. Kioskea.net (2014). Ciclo de Vida del Software. [Sitio Web]. Disponible en: http://static.ccm2.net/es.ccm.net/contents/pdf/ciclo-de-vida-del-software-223-k8u3gm.pdf
ACTIVIDAD N.° 3 Participan en el Foro de discusión sobre los “Riesgos de desarrollo de software”.
INSTRUCCIONES
1. Revisa los temas 1 y 2 y la lectura seleccionada. 2. Lee las instrucciones en el Aula Virtual. 3. Participa en el foro de discusión sobre los riesgos de desarrollo de software.
83
84
UNIDAD III: AUDITORÍA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE
TEMA N.° 3: APLICACIONES DE NEGOCIO
INTRODUCCIÓN Este tema está enfocado en analizar algunas Aplicaciones de Negocio verticales comunes que comúnmente son revisadas por los Auditores de Sistemas; así como el Big Data que se convertirá sin ninguna duda en el modelo de sistemas de información utilizados para la toma de decisiones en las organizaciones. 1
APLICACIONES DE NEGOCIO VERTICALES
Se conoce como Aplicaciones de negocio verticales a aquellas Aplicaciones que no son de uso general y que más bien son utilizadas por una industria especifica o para un solo propósito. A continuación revisaremos algunas de las aplicaciones de negocio verticales más utilizadas. 1.1 Comercio Electrónico (E-Commerce) El E-Commerce se refiere a la venta y compra de productos o servicios a través de Internet, lo cual da a los vendedores y clientes una inmensa oportunidad para vender a nivel global y para comprar a un precio asequible. El E-Commerce es parte del E-Business. Existen muchos modelos de E-Commerce. Entre los más populares tenemos: • Business-To-Consumer (B2C). En este modelo la compañía que vende se relaciona directamente con miles o inclu-
so millones clientes. El líder de este sector es www.amazon.com quien reinventa este sector con cientos de innovaciones. • Business-To-Business (B2B). En este modelo las compañías pueden integrar procesos directamente. Ejemplo de
procesos que se pueden integrar son pedidos al proveedor, pagos al proveedor, reclamos, servicio post-venta, entre otros. • Business-To-Employee(B2E). La compañía pone a disposición de sus empleados realizar transacciones directas como
por ejemplo solicitar un préstamo, cambiar el AFP, solicitar una carta para una Embajada, imprimir boletas de pago y certificados varios. • Business-To-Government(B2G). Este modelo permite a las compañías realizar trámites y pagar directamente los
impuestos ante el Gobierno. Como se puede apreciar, el comercio electrónico tiene muchas ventajas. Sin embargo también hay que considerar los riesgos del comercio electrónico, entre los que tenemos: • Confidencialidad. Para poder realizar transacciones electrónicas, los clientes deben suministrar información perso-
nal que podría incluir tarjetas de crédito que de perderse podrían afectar a los clientes y ser víctimas de fraude. De hecho este riesgo ha sucedido varias veces. Basta buscar en Internet los ataques a la compañía Target. Puede ver un pequeño video en: https://www.youtube.com/watch?v=lqu_Bx4Uf5w • Integridad. Alguna vez le ha pasado o ha escuchado que se está procesando una transacción electrónica y no termi-
na y el sistema “se cuelga”, con lo que el usuario no sabe si la transacción terminó o debe volver a hacerla. Si vuelve a realizarla, se podría comprar “doble”. Por otro lado, que sucede si los criminales informáticos modifican o borran los datos. A esto se refiere el riesgo a la integridad de los datos. • Disponibilidad. Uno de los grandes riesgos para una compañía de comercio electrónico es estar fuera de línea, es
decir no estar disponible. Esto aparte de hacer perder dinero a la compañía, podría espantar a los clientes y hacerles perder la confianza en el sitio. • Traslado del poder a los clientes. Este es el riesgo más importante de un sitio de comercio electrónico. Los clientes
UNIDAD III: AUDITORÍA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
están cada vez más informados y la competencia esta aun click de distancia y los clientes ahora son cada vez menos leales a las marcas. 1.2 Electronic Data Interchange (EDI) El intercambio Electrónico de Datos es un estándar en la cual los sistemas de información de diferentes empresas conversan directamente entre ellos, sin necesidad de intervención humana. Imagine la siguiente situación: Trabajamos en un gran supermercado, el cual tiene cientos (o incluso miles) de proveedores. La tarea de emitir órdenes de Compra para comprar a los proveedores los diversos productos a medida que se van agotando de los stocks deuna las diversas tiendas requerirá de unregistrar ejércitolos de artículos gente en yellas área de Compras. Por cada proveedor, tenemos que emitir Orden de Compra y debemos cantidades a comprar en la Orden y luego emitir la orden. Una vez emitida la Orden habrá que enviarla por correo electrónico al proveedor. El proveedor una vez recibida la Orden, ingresara los datos de la Orden de Compra en su Sistema de Ventas y en función a ello, emitirá una factura y una guía de remisión para que despachen los productos que estamos adquiriendo. En el proceso descrito existen dos compañías (el supermercado y el proveedor) en el cual ambos cuenta con sistemas de información pero la transferencia de datos es a través de correo electrónico. Entonces, ¿no sería mejor que los sistemas conversasen? Es aquí donde entra EDI. EDI es un estándar que permite a sistemas comunicarse entre sí. Para que dos sistemas se comuniquen entre si se necesita que hablen un mismo protocolo de comunicación. Eso es precisamente EDI. Entre los beneficios de implementar EDI se tiene: • Menos papeleo • Menos errores durante el intercambio de información • Mejor flujo de información, de base de datos a base de datos y de compañía a compañía • No se necesita introducir los datos en la manera repetitiva • Menos demoras en la comunicación • Mejores procesos de facturación y de pago
Evidentemente, la naturaleza crítica de muchas transacciones (órdenes de Compra, facturas y pagos), requiere protección de las transmisiones. Por ello, los sistemas EDI cuentan con mecanismos de protección, tales como: • Normas para indicar que el formato y el contenido del mensaje son válidos • Controles para asegurar que la aplicación de traducción convierte correctamente las transmisiones estándar para
el software de aplicación • Procedimientos para determinar que los mensajes son solamente de partes autorizadas • Canales de transmisión directos o dedicados entre las partes • Los datos deben estar encriptados usando algoritmos acordados por las partes involucradas • Registro en un log de cada transacción entrante • Uso de totales de control al recibo de las transacciones • El intercambio de totales de control de las transacciones enviados y recibidos entre los socios comerciales en inter-
valos predeterminados.
85
86
UNIDAD III: AUDITORÍA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE
1.3 Sistemas de Punto de Venta–Point of Sale(POS) Cuando hemos ido al supermercado y formado la fila para pagar nuestras compras. Algunas personas pagan con tarjeta en lugar de efectivo. Esto se puede hacer a través de los Sistemas de Punto de Venta (POS) que permiten a diversas compañías, aceptar pagos electrónicos por ventas en tiempo real. A través de los sistemas POS los clientes pueden pagar sus compras a través del uso de tarjetas de crédito y de débito en 24x7. Los POS pueden estar conectados a lectores magnéticos, lectores de chip, códigos de barra, entre otros. Desde el punto de vista de riesgo, es importante identificar y analizar cómo estos sistemas guardan la información que procesan, tales como el número de la tarjeta, y la información personal de los tarjetahabientes; así como las medidas de seguridad en la transmisión de la información. En el Perú empresas como Visanet y Procesos MC permiten el uso de tarjetas Visa, MasterCard, Dinners, Discover, Union Pay, American Express e incluso tarjetas privadas de tiendas tales como Ripley, Saga Falabella, CrediScotia, Financiera Uno, entre otros. 1.4 Sistemas de Dinero Electrónico. El objetivo de los sistemas de dinero electrónico es emular el dinero en efectivo. Un emisor hace esto mediante la creación de certificados digitales, que luego son comprados por los usuarios que los depositan en una fecha posterior. Algunas de las ventajas de los sistemas de dinero electrónico son: • Se ahorra tiempo y dinero ya que se puede realizar todas las operaciones de dinero electrónico en cualquier mo-
mento y en cualquier lugar. • No se necesita usar billetes ni monedas, tarjeta de crédito y/o débito. • No se requiere tener saldo, ni internet en el dispositivo celular.
Recientemente en el Perú se ha implementado el Sistema BIM, con el cual se puede realizar transacciones con dinero electrónico en lugar de cargar efectivo para mandar y recibir plata, a través del uso de cualquier celular. Puedes obtener más información en www.mibim.pe 1.5 Big data Uno de las Aplicaciones que más van a impactar a las compañías en el futuro cercano es el Big Data. Es sabido que una persona promedio el día de hoy genera más datos en un solo día, que una persona en el siglo XIV en toda su vida. Esta explosión de información, llevándolo al contexto de las empresas es más evidente que nunca. Las compañías generan terabytes (e incluso petabytes) de información cada año y no necesariamente se aprovecha toda esa información. Si las compañías pudiesen aprovechar la cuantiosa información que poseen, estarían en posición de tomar mejores decisiones de negocio. Anteriormente, la toma de decisiones se hacían sobre los sistemas de Business Intelligence, pero que tenían el problema de que demoraban mucho en cargar la data proveniente de los sistemas transaccionales. Con el pasar del tiempo, aparecieron los sistemas de computación en memoria (in-memory Computing) que permiten computar millones de datos en la memoria del computador, eliminado la necesidad de cargar los datos desde otros sistemas de información. Si Ud. desea ahondar en este fascinante tema, le invito a leer la lectura seleccionada de esta semana titulada: ¿Qué es Big data? Si bien, es una lectura tomada de un sitio de un proveedor, en este caso IBM, la lectura ofrece una fuente interesante y rápida forma de profundizar los conocimientos de Big Data. Otra fuente de información que recomiendo, la puede encontrar en el sitio”The human face of big data”. http:// humanfaceofbigdata.com .
UNIDAD III: AUDITORÍA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
Este sitio (del mismo nombre del famoso libro de big data) contiene excelentes videos y ejemplos de la inmensa cantidad de datos al que nos enfrentamos. Asimismo un ejemplo práctico del big data lo puede encontrar en: https://www.youtube.com/watch?v=d9NJt4DBb-I
87
88
UNIDAD III: AUDITORÍA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE
TEMA N.° 4: AUDITORIA AL CICLO DE VIDA
INTRODUCCIÓN Este tema está enfocado en como efectuar una Auditoria de Sistemas al Ciclo de Vida de Desarrollo de Software y al Mantenimiento de los Sistemas de Información. 1
AUDITORIA AL CICLO DE VIDA 1.1 Tareas del Auditor. En líneas generales, el Auditor de Sistemas debe efectuar las siguientes tares: • Identificar los componentes significativos o importantes en la aplicación y el flujo de las transacciones a través del
sistema. • Identificar las fortalezas de control de la aplicación y evaluar el impacto de las debilidades de control para desarro-
llar una estrategia de prueba, mediante el análisis de la información acumulada. • Probar los controles para asegurar su funcionalidad y su eficacia.
1.2 Documentación a solicitar. • Documentos de la metodología de ciclo de vida. Esto dará un entendimiento al Auditor de la robustez de los pro-
cesos de construcción de desarrollo de software. • Documentos de requerimientos. Esto permitirá entender cuáles fueron los requerimientos • Especificaciones de diseño funcional. Revisando este documento se tiene el conocimiento de la Aplicación. • Request for Change (RFC). Este documento permitirá conocer que cambios se realizaron y si estos contaron con
la autorización respectiva y debería poder cruzarse el documento de cambio con los cambios en el código fuente. • Manuales de usuario. Con este documento se entiende como el usuario utiliza la aplicación. Es muy común que
este documento este desactualizado. 1.3 Situaciones que podría srcinar riesgos en el Ciclo de Vida de Desarrollo de Software. A continuación presentaremos situaciones que generan riesgo: b) Estudio de factibilidad. • Costos y beneficios no verificables. • Falta de razonabilidad en la solución propuesta. • No existencia de estudios de factibilidad. • Falta de Business Case • Falta de aprobación para el proyecto
c) Requerimientos. • Existencia de requerimientos incompletos.
UNIDAD III: AUDITORÍA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
• Existencia de requerimientos muy genéricos. • Falta de identificación de los interesados y sus requerimientos. • Falta de requerimientos no funcionales
d) Diseño • Falta de utilización de un lenguaje de modelado de software. • Falta de Especificaciones de los componentes del Sistema • Falta de Especificaciones de las interfaces del Sistema • Falta de Especificaciones de los programas • Falta de Especificaciones de los datos
e) Adquisición de Software • Falta de un RFP • RFP incompleto • RFP formulado para hacer ganar a un único proveedor. • RFP no enviado a todos los proveedores. • No existencia de evaluaciones de proveedores. • Falta de contratos • Contratos sin penalidades.
f) Desarrollo • Desarrollo sin tener en cuentas las especificaciones. • Falta de pruebas. • Pruebas incompletas. • No corrección de los resultados de las pruebas.
g) Configuración • Falta de documentación en la configuración. • No adecuación de los procesos de la compañía a las mejores prácticas del software. • Automatización de procesos inconsistentes. • Falta de control de las interfaces con las aplicaciones existentes.
h) Implementación • Falta de la aceptación del usuario (UAT). • Falta de migración de daros importantes para el Sistema.
89
90
UNIDAD III: AUDITORÍA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE
• Falta de medidas de regresión en caso de falla.
i) Revisión Post-Implementación • Inexistencia de la fase Revisión de Post-Implementación • Falta de demostración de los beneficios que el Software brinda. • Falta de documentación de las lecciones aprendidas. 2
AUDITORIA AL MANTENIMIENTO DE SISTEMAS
2.1 Tareas del Auditor. En líneas generales, el Auditor de Sistemas debe efectuar las siguientes tares: • Identificar si existe un flujo de aprobación de cambios. • Identificar si todos los cambios están autorizados.
2.2 Documentación a solicitar. • Request for Change (RFC). Este documento permitirá conocer que cambios se realizaron y si estos contaron con
la autorización respectiva y debería poder cruzarse el documento de cambio con los cambios en el código fuente. • Manuales de usuario actualizados. Con este documento se verifica si los cambios se ven reflejados en la documen-
tación. 2.3 Situaciones que podría srcinar riesgos en el Mantenimiento del Software. A continuación presentaremos situaciones que generan riesgo: • Inexistencia de un proceso de control de cambios. • La inexistencia de un flujo de aprobaciones para los cambios. • Falta de priorización y seguimiento del sistema de cambio de los requerimientos del usuario • Inexistencia de procedimientos de cambio de emergencia • Inexistencia de sobres de emergencia. • Inexistencia de registros de control de cambios • Inexistencia de restricciones de acceso de seguridad sobre las carpetas de producción donde se encuentra los ob-
jetos fuente y ejecutables • Existencia de cambios sin documentación.
Además, el auditor de SI debe revisar el proceso global de gestión del cambio de la compañía, para identificar posibles mejoras en el tiempo de respuesta y la satisfacción de los usuarios con el proceso de cambio.
LECTURA SELECCIONADA N.° 2: Leer artículo: ¿Qué es Big Data?. ¿Qué es Big Data?. [Sitio Web]. Disponible en: https://www.ibm.com/developerworks/ssa/local/im/que-es-big-data/, X Y (20xy).
UNIDAD III: AUDITORÍA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
CONTROL DE LECTURA Nº 2 Esta actividad puede consultarla en su Aula virtual.
GLOSARIO DE LA UNIDAD III Big data: Se refiere a la disciplina de recolección, almacenamiento, búsqueda, compartición, análisis, y visualización de grandes cantidades de información. Business Case: Es un documento que se debe presentar ante un decisor para que apruebe un Proyecto. El Business case contiene las alternativas para que el decisor tome la alternativa más conveniente. IDE: Acrónimo de Integrated Development Environment. En español, Entorno de Desarrollo Integrado, es un software que facilita el desarrollo de software, contando con un editor de código fuente, herramientas de construcción automáticas y un depurador. La mayoría de los IDE tienen auto-completado inteligente de código y algunos cuentan con un compilador, un intérprete, o ambos. ITIL: Acrónimo de Information technology Infrastructure Library. En español Biblioteca de Infraestructura de Tecnología de Información. Es una práctica reconocida para la gestión de los servicios ofrecidos por las IT. Dentro de ITIL se encuentra el proceso de Gestión de Cambios. RFC: Acrónimo de Request for Change. En español Solicitud de Cambio, es un documento utilizado en el proceso de Gestión de cambios, donde se documenta un cambio que es requerido. RFI: Acrónimo de Request for Information. En español Solicitud de Información, es un documento que permite recoger información de las capacidades y características de un software de un proveedor. Normalmente se utiliza para sondear el mercado. RFP: Acrónimo de Request for Proposal. En español Solicitud de Propuesta, es un documento que solicita a los proveedores que presenten sus propuestas para adquirir un determinado bien o servicio. Este documento normalmente se solicita dentro de un proceso de licitación. También es conocido como “especificaciones técnicas”. SDLC: Acrónimo de Software Develepment Life Cycle. En español, Ciclo de vida de desarrollo de software, es un proceso de la Ingeniería de Software para creación de desarrollo y/o adquisición de software. UAT: Acrónimo de User Aceptation Test. En español, prueba de aceptación de usuario, es una prueba en la que el usuario valida que el software cumple con los requerimientos solicitado, y autoriza a ponerlo en funcionamiento. UML: Acrónimo de Unified Model Language. En español, Lenguaje Unificado de Modelado, es un lenguaje grafico utilizado para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un “plano” del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y reciclaje de componentes.
BIBLIOGRAFÍA DE LA UNIDAD III Information systems audit and control association. (2016). CISA Re-view Manual. Chicago: ISACA.
91
92
UNIDAD III: AUDITORÍA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE
AUTOEVALUACIÓN DE LA UNIDAD III 1. Ud. esta auditando los resultados de un servicio de Hacking ético a las aplicaciones de una compañía y encuentra que el hacker fue contratado para realizar pruebas de caja blanca. Esta prueba verifica: A) Los controles de validación B) El código fuente C) El proceso de ciclo de vida de la aplicación D) La aceptación del usuario a la aplicación 2. ¿En cuál de las siguientes fases del ciclo de vida de desarrollo de software se lleva a cabo la prueba de Aceptación de Usuario (UAT)? A) Adquisición B) Configuración C) Implementación D)Post-Implementación 3. Ud. esta auditando la validación del ingreso de datos de un nuevo sitio de redes sociales que tiene el potencial de destronar a Facebook. Al revisar el sitio, Ud. encuentra que para el registro de nuevos usuarios, el sistema solicita el correo sola una vez y no dos veces como lo hacen todas las redes sociales. ¿Cuál de las siguientes validaciones Ud. recomendaría? A) Chequeo de razonabilidad B) Prueba de sociabilidad C) Validación de llave D) Chequeo de relaciones lógicas 4. Ud. esta auditando el proceso de mantenimiento de software y encentra que en el presente año el principal sistema de información ha tenido 18 cambios. ¿Cuál de las siguientes sería una evidencia que Ud. solicitaría como parte de la revisión? A) Metodología de ciclo de vida de desarrollo de sistemas B) Pruebas de caja negra C) Formato de solicitud de cambios aprobado D)Caso de Negocio (Business Case) 5. Ud. esta por auditar el Sistema de Compras de Supermercados Chong y encuentra que el sistema realiza un Intercambio Electrónico de Datos basado en el estándar EDI. El Sistema de Compras se conecta con los sistemas de información de los proveedores. Al respecto, ¿cuál de los siguientes NO seria su principal preocupación? A) Que las transacciones no sean autorizadas B) Que las transacciones no se dupliquen C) El ciclo de vida de desarrollo de sistemas D)El Protocolo utilizado para el intercambio
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
6. Ud. es parte del equipo de Auditoria al sitio de comercio electrónico de la librería más importante del mundo: Barnes and Noble.com. ¿Cuál de los siguientes NO seria parte de la auditoria?, A) Revisión de los mecanismos de extracción de datos para las estadísticas del sitio B) Revisión de los controles de los mecanismos de pago del sitio C) Revisión de los controles de autenticación de usuarios del sitio D)Revisión de los controles de disponibilidad del sitio 7. Ud. esta auditando el proceso ciclo de vida de desarrollo de software compañía(Business de lácteos Glorita, y el área de Sistemas le informa que ha de presentado al gerente Financiero, un casodedelanegocios Case) relacionado a la implementación de un nuevo Sistema de Recursos Empresariales (ERP) al gerente. El área de Sistemas presento el caso de negocio al gerente Financiero para: A) Cerrar el proyecto B) Validar los beneficios del proyecto post cierre C) Tomar una decisión de si va o no va el proyecto. D) Determinar si se cumplieron los casos de uso. 8. La prueba en que se determina que un software no altere o dañe los software que ya se encuentran corriendo es la: A) Prueba de caja blanca B) Prueba de regresión C) Prueba de caja negra D) Prueba de sociabilidad 9. En cual fase del ciclo de vida de desarrollo de sistemas se toma la decisión de desarrollar o adquirir el software A) Diseño B) Adquisición C) Ingeniería de requerimientos D) Estudio de Factibilidad E) Implementación 10. Ud. está revisando una RFP (Request For Purposal) ¿Cuál es la fase del ciclo de vida que está auditando? A) Estudio de Factibilidad B) Pruebas C) Adquisición D) Configuración
93
94
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
UNIDAD IV: AUDITORÍA A LA SEGURIDAD DE LA INFORMACIÓN
UNIDAD IV: AUDITORÍA A LA SEGURIDAD DE LA INFORMACIÓN
DIAGRAMA DE PRESENTACIÓN DE LA UNIDAD IV CONTENIDOS
EJEMPLOS
AUTOEVALUACIÓN
ACTIVIDADES
BIBLIOGRAFÍA
ORGANIZACIÓN DE LOS APRENDIZAJES C O N O C I MI EN TO S
7° Videoclase (Video conferencia) Tema N.° 1: Seguridad de la información 1. Seguridad de la información 2. Seguridad informática Tema N.° 2: Controles de seguridad I
P R O C ED I MI EN TO S
1. Identifica los riesgos relacionados a la seguridad de la información 2. Identifica los riesgos relacionados a la seguridad informática 3. Participa en la redacción de observaciones relacionadas a la Gestión de Accesos y Criptografía.
1. Gestión de accesos 2. Criptografía Lectura seleccionada 1 Aplicación de la criptografía. Disponible en: https://www.icai.es/contenidos/publicaciones/anales_get.php?id=1235 8° Videoclase Tema N.° 3: Controles de Seguridad II 1. Dispositivos de Seguridad Internet 2. Seguridad Cloud 3. Seguridad Móviles Tema N.° 4: Auditoría a la Seguridad de la Información 1. Auditoría a la seguridad de la información 2. Auditoría a los controles de seguridad. Lectura seleccionada 2: Seguridad en dispositivos móviles: ¿Qué pautas debes seguir?. Disponible en: http:// hipertextual.com/archivo/2013/12/seguridad-dispositivos-moviles-consejos/ Autoevaluación de la unidad IV
Actividad N.° 4 Elabora un ensayo sobre cuando utilizar los diversos tipos de criptografía.
1. Identifica los riesgos relacionados al Internet 2. Identifica los riesgos relacionados al Cloud 3. Identifica los riesgos relacionados a los dispositivos móviles 4. Participa en la redacción de observaciones relacionadas a la seguridad de la información, poniendo énfasis en la recomendación de controles. Tarea Académica Nº 2 Elabora un informe de auditoría de controles de seguridad del caso “Auditoria de una empresa regional”.
A C T I TU D E S
1. Valora la importancia de la ejecución de la auditoria de sistemas. 2. Se auto valora por su aprendizaje de las técnicas de auditoria de sistemas. 3. Asume el compro-miso de revisar los contenidos del manual. 4. Valora la importancia de la auditoria de sistemas para el mejora-miento de una empresa y para las actividades o procesos a realizar. 5. Participa activamente en el desarrollo de las actividades de la asignatura.
95
96
UNIDAD IV: AUDITORÍA A LA SEGURIDAD DE LA INFORMACIÓN
TEMA N.° 1: SEGURIDAD DE LA INFORMACIÓN
INTRODUCCIÓN En este tema revisaremos los conceptos fundamentales sobre la seguridad de la información. 1
SEGURIDAD DE LA INFORMACIÓN
1.1 ¿Qué es la Seguridad de la Información? En su definición más simple la Seguridad es la ausencia de riesgo. Esto quiere decir que la Seguridad es un estado. Hoy puedo estar seguro y mañana no estarlo; o al revés, hoy no estarlo y mañana estar seguro. La Seguridad de la Información es la disciplina orientada a proteger la información de las compañías. La información de las compañías tiene valor y por ello requiere ser protegida. Esto tiene un significado relevante ya que la información es intangible, es decir que está en la memoria de un computador, en una Base de Datos, en una carpeta compartida, en la nube, en un dispositivo móvil. En cualquiera de estos requiere de protección del intangible. La seguridad de la Información tiene 3 objetivos a lograr: a) Confidencialidad. La confidencialidad se refiere a que la información solamente sea accedida por las personas autorizadas. Por ejemplo si un criminal informático logra acceder a información de muestra compañía, se vería afectada la Confidencialidad. b) Integridad. La integridad se refiere a que la información permanezca completa e inalterable, es decir que se mantenga exacta tal como fue ingresada. Si por ejemplo un malware encripta la información, es decir la modifica, entonces se afecta la integridad. c) Disponibilidad. Se refiere a que la información esté disponible cuando la persona autorizada la requiere. Este atributo de la seguridad es el más valorado por los usuarios. Imagine un dia lunes a primera hora y que los usuarios se encuentren con que “no hay sistema” debido a un ataque informático. 1.2 Factores Críticos de éxito Para que una iniciativa de Seguridad de la Información tenga éxito en una organización, se deben asegurar que los siguientes factores se logren: a) Compromiso de la Alta Gerencia. Se debe convencer a la Gerencia de la necesidad de proteger la información de la compañía. En ese sentido, hay que lograr el respaldo de la Gerencia antes de implementar las medidas de seguridad de la información. Si no se cuenta con el espaldarazo de la gerencia, la iniciativa de seguridad perderá fuerza y no podrá lograrse. b) Políticas, Normas tema normativo lo vimos encon la Unidad cuandonormas vimos ely procedimientos tema de las prácticas gerenciales de IT. ySeProcedimientos. debe contar conEste un árbol todas lasII, políticas, de seguridad de la información. c) Organización. Las actividades de seguridad requieren de un área organizada para que se encargue de todos los temas. Asimismo, se necesita que todos los usuarios tengan responsabilidades por la seguridad de la información en la compañía donde laboran. d) Educación. Los usuarios deben ser capacitados en los temas relevantes de Seguridad de la Información. Temas como riesgos, amenazas, uso aceptable de información y consideraciones que deben ser tomadas, son los temas que deben ser considerados en las capacitaciones de seguridad de la información. Se debe considerar capacitar a los usuarios al menos una vez al año.
UNIDAD IV: AUDITORÍA A LA SEGURIDAD DE LA INFORMACIÓN
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
e) Monitoreo. La ejecución de un monitoreo continuo y en tiempo real del cumplimiento de los controles y de la normatividad de seguridad de la información es una actividad vital para la seguridad de la información. f) Manejo de Incidentes. Tarde o temprano van a suceder incidentes de seguridad de la información. Esto es una realidad a pesar de todos los controles de seguridad de la información que el dinero pueda comprar y se implementen en una compañía. El responsable de Seguridad de la Información es el llamado a lograr a que estos Factores Críticos de Éxito se cumplan. De estos factores dependen si va a tener éxito o no en su gestión. 1.3 Inventario de Activos de Información Existe una máxima en Seguridad de la información: No se puede proteger lo que no se sabe que uno tiene. Es por ello que uno de los puntos cruciales de seguridad de la información radica en contar con un inventario exhaustivo de los activos de información. En este inventario no interesa si el activo es de propiedad de la compañía. Es decir se deben considerar los activos de información que sean de propiedad de terceros y que contengan información de la compañía. Si está conectado a la red, debe ser considerado en el inventario. En un inventario de Activos de Información se deben considerar: • Sistemas de Información • Base de Datos • Media • Licencias • Interfaces • Servidores • PCs / Laptops • Disp. móviles • Periféricos • Equipos de comunicación • Equipos de Protección eléctrica • Contratos • Documentación • Personal
97
98
UNIDAD IV: AUDITORÍA A LA SEGURIDAD DE LA INFORMACIÓN
2
SEGURIDAD INFORMÁTICA
2.4 La Seguridad de la Información y la Seguridad Informática. De primera impresión, la Seguridad de la Información podría confundirse con la Seguridad Informática. De hecho muchos profesionales, usan el término indistintamente. Sin embargo, es preciso acotar que la Seguridad Informática es un subconjunto de la disciplina de la Seguridad de la Información. Según Jeimy J.de Cano, la SeguridadelInformática, es la queantivirus, “se encargaría de las implementaciones de la protección la información, despliegue de lasdisciplina tecnologías firewalls, detección de intrusos,técnicas detección de anomalías, correlación de eventos, atención de incidentes, entre otros elementos, que—articulados con prácticas de gobierno de tecnología de información—establecen la forma de actuar y asegurar las situaciones de fallas parciales o totales, cuando la información es el activo que se encuentra en riesgo.” Entonces se puede decir que la Seguridad Informática trabaja en una capa operativa con algunos temas tácticos para proteger la información de una compañía. Por su lado, el mismo autor refiere que la Seguridad de la Información “es la disciplina que nos habla de los riesgos, de las amenazas, de los análisis de escenarios, de las buenas prácticas y esquemas normativos, que nos exigen niveles de aseguramiento de procesos y tecnologías para elevar el nivel de confianza en la creación, uso, almacenamiento, transmisión, recuperación y disposición final de la información.” Esto significa que la Seguridad de la Información trasciende al área de TI, ya que la información podría estar en medios tecnológicos como no tecnológicos. Es decir que la Seguridad de la Información se encarga de la protección de la información en todas sus manifestaciones. En ese sentido, la Seguridad de la Información es la capa estratégica orientada a proteger la información. En resumen, la Seguridad de la Información es un concepto más amplio y abarca la Seguridad Informática.
UNIDAD IV: AUDITORÍA A LA SEGURIDAD DE LA INFORMACIÓN
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
TEMA N.° 2: CONTROLES DE SEGURIDAD I
INTRODUCCIÓN En este tema vamos a revisar 2 controles importantes de Seguridad de la Información: La Gestión de Accesos y la Criptografía. 1
GESTIÓN DE ACCESOS
La Gestión de Accesos es un control preventivo que permite que no se acceda a la a la información por parte de usuarios no autorizados. La Gestión de Accesos está relacionada a la Confidencialidad de la Información. 1.1 Acceso. Empecemos por lo primero: definiendo lo que es el Acceso. Acceso es el flujo de información entre un sujeto y un objeto. Un sujeto puede ser una persona, una aplicación, una interface, etc. Por su lado, un objeto puede ser una Base de datos, un programa, una impresora. El acceso a la información dentro de una compañía no puede darse sin ningún tipo de control. El acceso a la información se debe otorgar solamente a las personas estrictamente necesarias. El criterio fundamental para otorgar accesos a los diversos activos es la Necesidad de Saber (Need-to-Know). Veamos 3 ejemplos para entender este criterio: •
-¿Un vigilante para realizar sus funciones necesitará acceso a los Estados Financieros de la Compañía?
• ¿La Sra. de limpieza para realizar sus funciones necesitara acceso a la planilla de la compañía?
• ¿El administrador de la Red para realizar sus funciones necesitará tener acceso a la Contabilidad de la compañía?
En los 3 casos presentados, ¿Qué debería suceder si alguno de estas personas solicita acceso? Evidentemente, el acceso a la información debería ser rechazado. A eso se refiere la necesidad de Saber. Este criterio precisa que los accesos a los activos de información deben ser otorgados a aquellas personas que para el desenvolvimiento de sus funciones requieren de dicho acceso. Ahora, vayamos un paso más allá. ¿Qué sucede con el Gerente General o dueño de la Compañía? ¿Necesitara tener acceso a todo la información de la compañía? La respuesta es NO. El gerente General debería tener acceso solamente a aquella información que necesite para realizar sus funciones de Gerente General. La necesidad de Saber no es fácil de implementar en las organizaciones. En muchas compañías se otorga acceso a todo aquel que lo pide o se otorga acceso a los compañeros o amigos de la oficina. Todas las compañías deberían comprender este criterio fundamental y aplicarlo. 1.2 Fases del control de Accesos El Control de accesos se implementa en los sistemas de información en 3 fases. a) Identificación b) Autenticación c) Autorización A continuación veremos las fases en detalle.
99
100
UNIDAD IV: AUDITORÍA A LA SEGURIDAD DE LA INFORMACIÓN
a) Identificación La identificación se da cuando el Sistema nos pide nuestra cuenta de usuario. Esta cuenta de usuario puede recibe varios nombres: user id, login, logon id, etc. Dadas las amenazas a las que está expuesta la información, es evidente que no basta con identificarnos ante un Sistema para acceder a la información. Los Sistemas de Control de Acceso siempre requieren que se verifique la identidad del usuario. b) Autenticación. La autenticación es el segundo paso y consiste en asegurar que el usuario demuestre que es quien dice ser. La autenticación se logra a través de 3 preguntas: ¿Qué es lo que se? ¿Qué es lo que tengo? ¿Qué es lo que soy? b.1 Autenticación sabiendo algo. La pregunta ¿Qué es lo que se? es la más popular y se responde a través de contraseñas. Es decir, los usuarios saben sus contraseñas. El reto de una contraseña es que cumpla 2 criterios de forma simultáneamente: Que la contraseña sea fácil de recordar (para el usuario) Que la contraseña sea difícil de adivinar (para cualquier atacante) Por ejemplo, la contraseña: “%%3sat5050599??##”, es una contraseña difícil de adivinar, pero no es fácil de recordar, por lo que no cumple los 2 criterios simultáneamente. Existen 2 técnicas recomendadas para recordar contraseñas y que permiten cumplir ambos criterios. La técnica del Acróstico: Por ejemplo considere la frase: “Más vale pájaro en mano que ciento volando”. Si aplicamos la técnica del acróstico, es decir tomamos la primera letra de cada palabra de la frase nos daría la contraseña: “Mvpemq100v”. La segunda técnica es la de usar una frase que sea familiar. Considere la siguiente frase corta: “si se puede”. Agregando símbolos a la frase nos daría la contraseña: Si##se##puede Esta técnica también es recomendada por el analista de la NSA, Edward Snowden. El indica que se use una contraseña en base a una frase. Textualmente Snowden da un ejemplo de contraseña: “margaretthatcheris110%SEXY”. Esta contraseña se deriva de la frase: Margaret Thatcher es 110% sexy. Puede encontrar más información de las recomendaciones de Edward Snowden en: http://www .20minutos.es/no ticia/2429957 /0/edward-snowden/seis-co nsejos/contrasenas-seg uras-internet/#xtor=AD-15&xts=467263
UNIDAD IV: AUDITORÍA A LA SEGURIDAD DE LA INFORMACIÓN
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
b.2 Autenticación teniendo algo. Otra forma de autenticación (menos popular) es la de autenticación teniendo algo. Por ejemplo: un token, una tarjeta de coordenadas o un chip. En la siguiente figura se tiene un ejemplo de tarjeta de coordenadas:
Figura 20. Tarjeta de coordenadas usada en la autenticación. Fuente: zonabancos.com
El Sistema antes de permitir una transacción importante, nos solicita que ingresemos una determinada coordenada. Por ejemplo B6. El usuario no sabe el código, simplemente lo tiene. b.3 Autenticación siendo algo. Esta pregunta responde la biometría. El el Sistema dato biométrico para a lavenas persona. Esto puede serselogrado concon la huella dactilar, análisispide del ingresar iris, de launretina, la geometría de autenticar la mano. Las del dorso, etc. c) Autorización La última fase del control de Acceso es la Autorización y se refiere a que permisos (también llamados privilegios) tiene un usuario cuando ingresa al Sistema. En función a la Autorización un determinado usuario puede insertar, modificar o incluso eliminar registros en una determinada transacción. c.1 Sistema de Control de Accesos Todos los conceptos revisados se implementan en los Sistemas de Control de Acceso. Un sistema de Control de Acceso debe cumplir las siguientes funciones: •
Identicación y autenticación en base a una o más factores.
•
Restricción de logon IDs a terminales y horarios especícos
•
Gestión de la Autenticación a través de la creación o modicación de perles de usuario
•
Crear responsabilidades y auditabilidad individual a través de registro de los eventos en una bitácora
•
Reportes de Accesos
101
102
UNIDAD IV: AUDITORÍA A LA SEGURIDAD DE LA INFORMACIÓN
2
CRIPTOGRAFÍA
2.3 Definición La criptografía es otra técnica utilizada para preservar la confidencialidad de la Información. La criptografía permite convertir un texto plano (técnicamente se llama plain text) que requiere ser transmitido, a un texto ilegible (técnicamente se le llama cypher text) que no puede ser entendido si es que alguien captura el texto durante la transmisión. La criptografía tiene 3 elementos: •
El algoritmo criptográco. Siempre se debe utilizar un algoritmo público ya que este algoritmo es considerado
robusto. •
La llave. La llave se reere a una cadena de bits que se introduce al algoritmo. La llave constituye el elemento se-
creto. Es por ello que se dice que la fortaleza de la criptografía reside en la seguridad de la llave. •
La longitud de la llave. Mientras más larga la longitud de la cadena de bits, más segura estará la llave. Dado que la
llave es una cadena de bits, es sujeta a un ataque de fuerza bruta en donde el atacante intentará romper la criptografía intentando todas las combinaciones posibles de llave. 2.4 Tipos de Criptografía Existen 3 tipos de criptografía: a) Criptografía simétrica. También conocida como criptografía de clave privada. b) Criptografía asimétrica. También conocida como criptografía de clave pública. c) Funciones hash. Es una criptografía de una sola dirección. Es decir, se puede encriptar, pero no se puede desencriptar. A continuación, revisaremos las características de cada una de las criptografías. a.1 Criptografía simétrica. La criptografía asimétrica es una criptografía que permite encriptar y desencriptar utilizando una misma llave. Esto significa que la misma llave que se utiliza para encriptar, es usada para desencriptar. El algoritmo de criptografía simétrica más popular es el algoritmo AES (Advanced Encription System). Este algoritmo permite longitudes de llave de 128, 192 o 256 bits. (EL día de hoy se considera que longitudes de llave de 128 bits son seguras). El algoritmo AES está basado en el algorimo Rijndael (Se pronuncia Ring Doll) que ganó un concurso de criptografía convocado por la NIST en el año 2001. Puede encontrar más información en: https://es.wikipedia.org/wiki/Advanced_Encryption_Standard Por otro lado, puede ver un video de esta criptografía en: https://www.youtube.com/watch?v=46Pwz2V-t8Q El problema de la criptografía simétrica es la distribución de la llave. Dado que, con la misma llave que se encripta se desencripta, entonces se necesita un mecanismo seguro para enviar la llave al destinatario.
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
UNIDAD IV: AUDITORÍA A LA SEGURIDAD DE LA INFORMACIÓN
Por ejemplo si encriptamos un documento, enviamos el documento encriptado al destinatario, pero, ¿cómo haríamos para hacerle llegar la llave? Para resolver este problema, en los años 70 se inventó la criptografía asimétrica. b.1 Criptografía asimétrica La criptografía asimétrica requiere de dos llaves para cada usuario o Sistema. Una llave es usada para encriptar y la otra llave es usada para desencriptar. Una de las llaves es la llave privada (que debe conservarse secreta) y la otra llave es la llave publica (por lo tanto no requiere ser secreta, sino todo lo contrario, podría estar publicada en cualquier directorio). Con esto se evita, que se tenga que distribuir la llave secreta. El algoritmo de criptografía asimétrica más popular es el algoritmo RSA (El nombre del algoritmo está basado en las iniciales de sus 3 creadores: Rivest, Shamiry Adleman). Este algoritmo permite longitudes de llave de 1024, 2048 y 3072 bits. El día de hoy no se utiliza llaves de 1024 bits. Puedes ver detalles del algoritmo en: https://www.youtube.com/watch?v=On1clzor4x4 c.1 Funciones hash Un tercer tipo de criptografía es la función hash. Se trata de una función de una sola vía, es decir en un solo sentido. Se utiliza para encriptar pero no para desencriptar. La función hash es una función muy sensible. Esto significa que un pequeño cambio en el texto plano srcinará un resultado completamente diferente. El resultado de una función Hash es llamado MD (Message Digest) o resumen del mensaje. Este resultado siempre es de una longitud fija sin importar la longitud del mensaje srcinal. El algoritmo Hash más utilizado es el SHA-II (también llamado SHA-256). Esta criptografía es más utilizada para garantizar la integridad (más que la confidencialidad). Para probar cómo funciona, ingrese a hashgenerator.de y ponga un texto, hagale anos cambios y observe como el Message Digest cambia dramáticamente. 2.5 Comparación de las tres criptografías Las 3 criptografías se utilizan en diversas situaciones. A continuación presentaremos un cuadro resumen de las 3 criptografías: Tabla 4 Cuadro Comparativo Criptografías. AT R I B U TO
llavesdeNro.
C R I P T O G R A F Í AS I M É TR I C A
1
2
Algoritmo Log de llave
C R I P T O G R A F Í AA S I M ÉT R I C A
F U N C I Ó NH A S H
1
AES
RSA
128, 192, 156
2048. 3072
SHA-II 256
Performance
Rápido
Pequeños
N/A
Volúmenes de información
Grandes
Pequeños
N/A
Fuente: Elaboración propia.
103
104
UNIDAD IV: AUDITORÍA A LA SEGURIDAD DE LA INFORMACIÓN
2.6 Aplicaciones La Criptografía tiene una serie de aplicaciones. • Firma Digital. Este algoritmo emula la firma humana en transacciones digitales. Utiliza la criptografía asimétrica y
la función Hash. • Transport Layer Security (TLS). Este protocolo encripta la comunicación entre un Browser y un Servidor Web. Este
protocolo reemplazo al protocolo Secure sockets layer (SSL). • IP security (IPSec). Es un protocolo asegurar el flujo de paquetes, garantizar la autenticación mutua y establecer
parámetros criptográficos. Es muy utilizado en las implementaciones de VPN (Virtual Private Network). • Secure Shell (SSH). Es un protocolo que permite el login y servicios de red a sistemas remotos. • Secure multipurpose Internet mail extensions (S/MIME). Es un estándar para la protección de correos electróni-
cos. • 3D Secure. Es un protocolo basado en XML para otorgar seguridad en las transacciones de tarjeta de débito y de
crédito. Si te interesa el tema de la criptografía, le recomiendo la película El Código Enigma donde se cuenta la historia de cómo se logró romper la criptografía de la maquina alemana que encriptaba los mensajes de guerra durante la Segunda Guerra Mundial.
LECTURA SELECCIONADA Nº 1: Leer artículo: Aplicaciones de la Criptografía. Delgado, V., & Palacios, R. (2006). Aplicaciones prácticas de la criptografía. Anales de Mecánica y Electricidad. Disponible en: http://bit.ly/2bcFvh1
ACTIVIDAD N.° 4 Participan en el Foro de discusión subiendo un ensayo sobre cuando utilizar los diversos tipos de criptografía. INSTRUCCIONES 1. Revisa los temas 1 y 2 y la lectura seleccionada. 2. Lee las instrucciones en el Aula Virtual. 3. Elabora un ensayo sobre cuando utilizar los diversos tipos de criptografía y súbelo al aula virtual. 4. Participa en el foro de discusión, emitiendo tu opinión sobre el trabajo de un compañero, como mínimo.
UNIDAD IV: AUDITORÍA A LA SEGURIDAD DE LA INFORMACIÓN
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
TEMA N.° 3: CONTROLES DE SEGURIDAD II
INTRODUCCIÓN Este tema está enfocado en los controles a implementar tanto en la Seguridad de Internet, como en el cloud y los móviles. 1
SEGURIDAD EN INTERNET
La Seguridad de Internet tiene que ver con los controles a implementar por las compañías para protegerse de las amenazas provenientes de Internet. En Internet hay una diversidad de personas entre las que resaltan: •
Crackers. Más conocidos como los criminal hackers. Son personas con conocimientos tecnológicos (no necesariamente muy sofisticados) que realizan actividades ilegales como ingresar a los sistemas de información para robar información con el fin de obtener un beneficio económico. Hay que diferenciar el cracker del hacker. El hacker no es un criminal. Es una persona con altos conocimientos tecnológicos y que averiguan como ingresar a un determinado objetivo. Esta más orientado con la satisfacción personal que con el lucro haciendo actividades ilegales, como es el caso del cracker. Sin embargo, la persona común no distingue entre ambos. En realidad cracker y hacker son opuestos.
•
Lammers. Los lammers son aquellas personas que tienen limitaciones en su capacidad técnica y que se hacen pasar como hackers. Es decir, presumen de sus habilidades técnicas, a pesar de que no las tienen. Los hackers utilizan este término como un insulto para la persona que se “alucina” hacker pero que lo único que hace es utilizar programas de fácil manejo para intentar “hackear” un objetivo.
•
Wannabies. Los Wannabies son aquellas personas que están en proceso de hacerse hackers. Podría tratarse de novatos con altos conocimientos técnicos pero que aún no son reconocidos por la comunidad hacker. Etas personas perseveran estudiando y aprendiendo las diversas técnicas de ingreso a los sistemas.
•
Script-Kidies. Los Script-Kiddies son personas sin conocimientos técnicos avanzados y que se dedica a utilizar programas y scripts desarrollados por otros para atacar sistemas. Son como los lammers.
•
Samurai. Los Samirai son personas con alta capacidad téncia y que son llamados por una compañía para investigar fallos de seguridad
•
Competencia. Se refiere a cualquiera de los anteriores y que es contratada por la competencia para acceder a los sistemas de una determinada compañía. En Latinoamerica existe un espionaje industrial en aumento y las compañías deben protegerse de la competencia.
Las compañías para defenderse de las amenazas de Internet, implementan controles, los cuales veremos a continuación. 1.1 Firewalls El Firewall es considerado como el control primario de defensa de las compañías. El firewall puede ser visto como una garita de peaje. En función a ciertas reglas permite o no el acceso entre 2 redes. Los firewalls pueden ser implementados en hardware o software, o en una combinación de ambos El firewall también puede ser usado al interno para proteger algunas partes de la red que solo deben ser accedidas, por ejemplo la red donde se encuentren los servidores. Existen varias tecnologías de firewall entre las que destacan:
105
106
UNIDAD IV: AUDITORÍA A LA SEGURIDAD DE LA INFORMACIÓN
• Filtrado de paquetes. Este tipo de firewall filtra cada paquete tomando únicamente la información contenida en
el paquete en sí, utilizando generalmente una combinación del emisor del paquete y la dirección de destino, su protocolo, y, en el tráfico TCP y UDP, el número de puerto. Este tipo de Firewalls fue el primer tipo, y actualmente no es muy utilizado. • Aplicación. Este tipo de Firewall es usado con los servidores proxy. En esta situación no se da una trasferencia de
datos de forma directa entre redes, porque existe un monitoreo de la información. • Stateful Inspection. Este tipo de firewall realiza un seguimiento del estado de las conexiones de red (TCP, UDP) que
cruzan a través de él, dejando pasar solo a los paquetes que coincidan con una conexión activa conocida. Cuando se implementa un firewall, una buena práctica es seguir la guía de la NIST SP 800-41. Puede ubicar la norma en el siguiente link: http://csrc.nist.gov/publications/nistpubs/800-41-Rev1/sp800-41-rev1.pdf Otro punto digno de mencionar lo constituyen los firewalls de Nueva Generación (NGFW). Estos Firewalls son capaces de entender las aplicaciones Web 2.0 (Facebook, Dropbox, Youtube, etc) y también se conectan con los sistemas LDAP y con ello conocen a los usuarios de la red. La compañía palo Alto invento este concepto y se está apoderando rápidamente del mercado de Firewalls. Una descripción de este tema lo puede ubicar en: http://media.paloaltonetworks.com/documents/Firewall_Feature_Overview-spanish.pdf 1.2 IDS El Sistema IDS es un sistema que intenta detectar anomalías. Existen 2 tipos de IDS, que son completamente diferentes: a) IDS basado en red (NIDS). Cuando se implementa en la red, el IDS analiza el tráfico de la red (o parte de ella), inspeccionado los paquetes en busca de situaciones anómalas. Un NIDS es un control que complementa a los firewalls. Una analogía para comprender el NIDS son los controles antes de abordar un avión. Cuando Ud. quiere abordar un avión hay una persona que se encarga de verificar si el boarding pass coincide con su documento de identidad. Si todo esta OK, Ud. Es autorizado a seguir. Este control es como el Firewall. Luego de que Ud. ha pasado, se tiene que pasar por el control de rayos X. Ud. tiene que quitarse cualquier cosa que porte y sus cosas pasan por la máquina de rayos X. Los rayos X verifican el contenido que Ud. porta. Este control es el IDS. Un punto importante cuando se implemente un NIDS es donde se coloca el IDS. Dado que cada paquete de datos es examinado, poner un IDS puede significar una degradación en la performance de la red. b) IDS basado en host (HIDS). Un Sistema HIDS es un control que se instala en un Servidor o en una PC. El HIDS protege el Servidor protege los archivos críticos del Sistema ante cambios no autorizados. Veamos un ejemplo. Si un servidor cuenta con un HIDS e ingresa un malware a dicho Servidor, cuando el malware intenta agregar o cambiar una llave en el regedit, el HIDS toma este cambio como una situación anómala y detiene el intento. 2
SEGURIDAD DEL CLOUD
1.1 Cloud Computing Una de las mega tendencias en TI indudablemente es la adopción del Cloud Computing. Mucho se ha escrito del Cloud y existe algo de confusión en este tema. Las definiciones oficiales de Cloud se encuentran en la guía NIST SP 800-145. La guía la puede ubicar en: http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf
UNIDAD IV: AUDITORÍA A LA SEGURIDAD DE LA INFORMACIÓN
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
Según esta guía, el Cloud es un “modelo para habilitar el acceso de red de forma continua, conveniente y bajo demanda a un conjunto de recursos de computación configurables que puedan ser rápidamente provisionados y lanzados con un mínimo esfuerzo de gestión e interacción con el proveedor de servicio”. Asimismo la guía define 5 características que debe cumplir toda solución para ser considerada Cloud: • Auto-servicio por demanda • Acceso amplio desde la red • Pooling de recursos • Rápida elasticidad • Servicio medido
Un video de lo que es el Cloud lo puede encontrar en: https://www.youtube.com/watch?v=0xPENqtDVXU 2.5 Riesgos en el Cloud. El Cloud no está exento de riesgos. Entre los principales riesgos de negocio tenemos: • Pérdida de control. La compañía pierde control de las soluciones tecnológicas, toda vez que un proveedor se en-
carga del servicio. • Mayor relevancia del proveedor. Coherente con el punto anterior, el proveedor al controlar el servicio tiene mayor
ventaja para negociar con el cliente. • Menor visibilidad del destino de los datos. En el cloud no deberían interesar al cliente donde están sus datos. Sin
embargo, algunos países exigen que los datos no salgan de sus territorios. • Ambigüedad de responsabilidades. Ante la ocurrencia de un problema, el proveedor y el cliente podrían verse
enfrentados debido a una evasión de las responsabilidades. • •Adaptación de usuarios al nuevo modelo. Cambiar el modo de trabajar de los usuarios hacia una solución 100%
web podría srcinar un rechazo inicial por parte de los usuarios. • Movilidad y BYOD. Los datos al estar en la nube, permiten que estos sean accedidos desde cualquier lugar del
mundo, y no solo desde la red corporativa. Esto srcina riesgos de protección de la información cuando es accedida desde los dispositivos móviles tanto de propiedad de la compañía como de los propios usuarios. • Incapacidad de medir cumplimiento. El modelo de Cloud se basa en la medición. Esto srcina riesgos en el cliente
para saber si la medición es la adecuada. • Falla de la Nube. En caso de falla en la Nube, la compañía se quedaría sin servicio. El Internet se convierte en un
recurso crítico. Sin Internet no hay acceso a la solución. En relación a los riesgos de seguridad de la información, la principal organización que investiga estos temas es la Cloud Security Alliance. Su sitio web es: https://cloudsecurityalliance.org/ Esta organización emite todos los años un informe de las amenazas que afectan a los servicios Cloud. El último informe es el informe The Treacherous 12 CSA’s Cloud Computing Top Threats in 2016, en el cual se definen las principales amenazas, las cuales se presentan a continuación: 1. Violaciones de los datos 2. Identidad débil, gestión de accesos y credenciales
107
108
UNIDAD IV: AUDITORÍA A LA SEGURIDAD DE LA INFORMACIÓN
3. APIs inseguras 4. Vulnerabilidades de la Aplicación y del sistema 5. Secuestro de cuentas 6. Empleados del proveedor maliciosos 7. Amenazas persistentes avanzadas (APT) 8. Pérdida de Datos 9. Insuficiente Due Diligence 10. Abuso y Uso nefasto de servicios en la nube 11. Denegación de Servici 12. Cuestiones tecnología compartida El informe con todo el detalle, lo puede obtener en: https://downloa ds.cloudsecurityalliance. org/assets/research/top -threats/Treacherous-12_C loud-Computing_TopThreats.pdf
3. SEGURIDAD DE MÓVILES. 3.1 Consumerización de la tecnología Hubo un tiempo en que los usuarios dentro de una compañía le pedían asesoría al área de TI, sobre que tecnología adquirir. El área de TI era el área experta y los usuarios agradecidos seguían los consejos que el área de TI ls daba. Esos son tiempos muy lejanos. El día de hoy estamos viviendo una tendencia en que los usuarios saben tanto de tecnología como el área de TI. Esto es particularmente cierto en el caso de las tecnologías móviles. Incluso, las tecnologías de información llegan primero al consumidor y luego son adoptadas por las compañías. Este fenómeno es conocido como la consumerización de la tecnología. Es por esta razón que los dispositivos móviles están prácticamente al alcance de cualquier persona. Esto enfrenta a las compañías a la decisión de si permitir o no el ingreso de los dispositivos móviles. Las compañías enfrentan el día de hoy estas realidades: • Presión de los usuarios por usar equipos personales en ámbito laboral • Los usuarios tienen mejor tecnología que la prevista por sus empresas • Nuevos riesgos para las empresas
Para enfrentar los desafíos de la consumerización, las compañías tienen 2 estrategias: • COPE (Corporate Owned Personally Enabled). En esta estrategia la compañía adquiere los dispositivos móviles y los entrega a sus trabajadores. Dado que la propiedad de los dispositivos es de la compañía, los dispositivos están sujetos a las políticas y restricciones que la compañía impone. • BYOD (Bring Your Own Device). En esta estrategia la compañía permite a sus trabajadores que traigan sus propios
dispositivos móviles personales y les permite que desde dichos dispositivos se accedan a activos de información de la compañía tales como correo electrónico, Intranet, VPN, acceso a Sistemas internos, entre otros. Esto significa que en un dispositivo personal conviven aplicaciones e información tanto del usuario como de la compañía.
UNIDAD IV: AUDITORÍA A LA SEGURIDAD DE LA INFORMACIÓN
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
3.2 Los riesgos en los móviles Estas nuevas tendencias en las que la información de la compañía reside en los dispositivos móviles generan nuevos riesgos. Entre los riesgos más relevantes tenemos: • Robo o pérdida de dispositivo. Si se pierde el dispositivo móvil, no solo se pierde información personal del usuario,
sino que un tercero podría tener acceso a la información de la compañía. • Fuga de datos. Si la compañía no implementa controles, un usuario podría sacar información de la compañía sin
ningún tipo de restricción. • Acceso no autorizado. Un dispositivo móvil no protegido puede ser accedido ante un descuido del usuario y la
información de la compañía podría ser accedida de manera no autorizada.
• Propagación de malware. Los dispositivos móviles son ahora otro canal de propagación del malware. El malware
está presente en todas las plataformas. Los riesgos presentados son solo algunos de los riesgos a los que se enfrentan los dispositivos móviles. Puede ver un video sobre este tema (en inglés) en: http://www.youtube.com/watch?v=iJUwz2b64Sw A continuación haremos un rápido repaso de las diversas plataformas móviles: a) iOS. El SO de Apple es considerada la plataforma más segura debido a que toda App es revisada por Apple antes de ser publicada en el Apple Store. Esto permite con un cierto grado de confiabilidad que las Apps publicadas en el App Store son seguras. A pesar de los controles, los criminales informativos se las han arreglado para meter malware en algunas Apps. Puede ver un detalle de esto en: http://www.lavanguardia.com/tecnolog ia/moviles-dispositivos/iphone-ipad/20150925/54 436836215/apple-a ppsmalware.html b) Android. La plataforma móvil de Google es considerada una de las más inseguras debido a que no cuenta con los controles que Apple exige. Los diversos estudios indican que esta es la plataforma móvil preferida para la distribución del malware y la generación de Apps maliciosas, precisamente por que Google no controla las Apps publicadas en Google Play. A favor de Android se puede decir que diversos especialistas consideran que el diseño del Sistema Operativo Android es seguro. El riesgo no está en el Sistema operativo, sino que radica en los privilegios que los usuarios otorgan a las diversas Apps que se descargan. c) Windows Mobile. Antes conocido como Windows Phone. La plataforma móvil de Windows no es precisamente la más popular. Al igual que Apple, Microsoft revisa cada App antes de ser publicada en la tienda. Windows Mobile “carga con la mochila” de ser un producto Windows y por tanto expuesto al malware de la plataforma Windows. Dado que Windows Mobile no es tan popular no hay tanto malware como en otras plataformas moviles.
109
110
UNIDAD IV: AUDITORÍA A LA SEGURIDAD DE LA INFORMACIÓN
TEMA N.° 4: AUDITORIA A LA SEGURIDAD DE LA INFORMACIÓN
INTRODUCCIÓN Este tema está enfocado en como efectuar una Auditoria de Sistemas a la Seguridad de la información. 1
AUDITORIA A LA SEGURIDAD DE LA INFORMACIÓN
1.1 Tareas del Auditor. En líneas generales, el Auditor de Sistemas debe efectuar las siguientes tareas cuando revisa la Seguridad de la Información: • Revisión de políticas, procedimientos y estándares escritos de seguridad de la información. • Revisar la ejecución de charlas de concientización de Seguridad a todo el personal. • Revisar la existencia de Inventarios de Activos de Información y la existencia de Propietarios para los Activos. • Revisar la existencia de procesos periódicos de Análisis de Riesgo de seguridad de la información. • Revisión de controles para minimizar riesgos en cada uno de los Activos de Información a través de la existencia de
Baselines de seguridad.
2
AUDITORIA A LOS CONTROLES DE SEGURIDAD.
A continuación presentaremos las principales tareas que realiza el Auditor de Sistemas cuando audita los controles de seguridad. 2.1 Auditoria a los accesos. Es muy común para los auditores encontrar accesos vigentes de usuarios que ya no laboran o de cuentas que ya no se utilizan. En ese sentido el Auditor realiza las siguientes revisiones: • Revisión de usuarios vigentes y cesados. Lo que se trata de encontrar es accesos de usuarios ya cesados y que siguen
vigentes en los sistemas. • Revisión de cuentas genéricas / de servicio. Aquí se trata de identificar si todas las cuentas genéricas tienen un pro-
pietario, si están vigentes. Por las cuentas de servicio se revisa si es que siguen vigentes. • Revisión de Privilegios. Se revisa los permisos que tienen los usuarios dentro de un determinado Sistema. El propie-
tario debe validar si los permisos están vigentes. • Revisión de autorizaciones para el acceso. Se revisa que todo acceso cuente con su autorización correspondiente
por parte del propietario del Activo de información 2.2 Auditoria a la Criptografía. • Revisión de gestión de llaves. El auditor revisa el ciclo de vida de las llaves criptográficas: ¿Cómo se crean? ¿Quién
las crea? ¿Cómo se almacenan? ¿Qué controles existen para proteger las llaves? • Fortaleza de los algoritmos criptográficos. El auditor revisa los algoritmos utilizados en las diversas implementacio-
nes para verificar su vigencia y robustez.
UNIDAD IV: AUDITORÍA A LA SEGURIDAD DE LA INFORMACIÓN
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
Así por ejemplo una página muy usada por los Auditores es https://www.ssllabs.com/ssltest. Esta página permite revisar la robustez de los algoritmos criptográficos y del certificado digital de una página web. 2.3 Auditoria a los Controles de Seguridad Internet, Cloud y Móviles A nivel de los controles de Internet se ejecutan las siguientes revisiones: • Revisar el diagrama de red, en busca de debilidades en la red. • Revisar reglas del Firewall. Se revisan las reglas para encontrar inconsistencias o reglas demasiado genéricas que
permiten accesos indebidos. • Revisar reglas del IDS/IPS. Se revisan las reglas en busca de debilidades en las reglas de detección de anomalías. • Revisar la actualización de los dispositivos de Seguridad. El Auditor revisa que los diversos dispositivos se encuen-
tren con las versiones vigentes y con los parches correspondientes. A nivel de Cloud, como es evidente no se puede auditar a los proveedores de Cloud. En ese contexto se revisan si se han implementado los controles ofrecidos por la solución Cloud. Asimismo se revisan los Contratos y si los SLAs ofrecidos por el proveedor Cloud se cumplen. Finalmente a nivel de los dispositivos móviles se revisan que en los móviles COPE y BYOD se tengan implementados controles para asegurar la confidencialidad de la información contenida en dichos móviles. Así por ejemplo, el Auditor revisa que la compañía tenga alguna solución de control como por ejemplo MDM (Mobile Device Management).
111
112
UNIDAD IV: AUDITORÍA A LA SEGURIDAD DE LA INFORMACIÓN
LECTURA SELECCIONADA Nº 2: Leer artículo: Seguridad en dispositivos móviles: ¿qué pautas debes seguir?. Velasco, J. (2013). Seguridad en dispositivos móviles: ¿qué pautas debes seguir?. Disponible en http://bit.ly/2bxHOZZ
TAREA ACADEMICA Nº 2 Esta actividad puede consultarla en su Aula virtual.
GLOSARIO DE LA UNIDAD IV Activo de información. Recurso informático que trata información. Puede ser una Base de datos, un Sistema, un Servidor, etc. BYOD. Acrónimo de Bring Your Own Device. Es una estrategia utilizada por las compañías para permitir a los usuarios traer sus propios dispositivos y conectarlos a la red de la Compañía. COPE. Acrónimo de Corporate Owned personally Enabled. Es una estrategia usada por las compañías para entregar a sus trabajadores dispositivos móviles. Cuenta de Servicio. Es una cuenta utilizada por un Sistema de Información o dispositivo de red para comunicarse con otro sistema o dispositivo. La cuenta de Servicio no es utilizada por ningún usuario. Cuenta genérica. Es una cuenta utilizada para un usuario para un propósito específico pero que no cuenta con sus nombres y apellidos. Toda cuenta genérica debe contar con un Propietario. Propietario. Responsable de otorgar acceso a un Activo de información.
BIBLIOGRAFÍA DE LA UNIDAD IV Information systems audit and control association. (2016). CISA Re-view Manual. Chicago: ISACA.
UNIDAD IV: AUDITORÍA A LA SEGURIDAD DE LA INFORMACIÓN
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
AUTOEVALUACIÓN DE LA UNIDAD IV
1. Después de 2 meses, la Universidad “Universal”, descubre un hueco de seguridad que permitió a 2 alumnos realizar un ataque informático y acceder y modificar las notas almacenadas en la Base de Datos del Sistema Académico. El descubrimiento fue accidental. En este caso, la Universidad habría podido detectar oportunamente si es que tuviese implementado en la Base de datos: A) Algoritmo criptográfico RSA de Criptografía asimétrica B) Función Hash tipo SHA-II C) Algoritmo criptográfico AES de 128 bits de Criptografía simétrica D) Algoritmo criptográfico AES de 256 bits de Criptografía simétrica 2. En una auditoria a la Infraestructura de red, ¿cuál de los siguientes NO revisaría? A) Topología de la red B) Interconexion de la red C) Revisión del File Server D) Gateway a Internet 3. Ud. Encuentra que el área de IT ha adquirido un Firewall de Nueva Generación y encuentra que el equipo esta dimensionado para soportar hasta 200Mbps de ancho de banda de Internet. Sin embargo, debido a una reciente fusión la Compañía, el trafico esta en 290 Mbps Esta situación srcina el riesgo que hay trafico sin proteger. Su recomendación se enfoca en: A) Adquirir un nuevo equipo para soportar el throughput de la red B) Mejorar la latencia de la red C) Cambiar las tarjetas de red D) No hacer nada, no hay riesgo 4. ¿La autenticación de doble factor es una obligación en cuál de las siguientes situaciones? A) Para conectarse a la red desde las oficinas de la compañía B) Para conectarse a un servidor dentro de la red desde las oficinas de la compañía C) Para conectarse remotamente a través desde un cliente VPN D) Para conectarse a un sitio web público con https ( x ejm de un Banco)
113
114
UNIDAD IV: AUDITORÍA A LA SEGURIDAD DE LA INFORMACIÓN
5. La Ley de Protección de datos obliga a las compañías a proteger los datos que se transmiten sobre la red. Ud. encuentra que una compañía ha aumentado dramáticamente la transmisión de datos con diversos socios de negocios y se transfieren datos personales ¿Cuál de los siguientes algoritmos Ud. recomienda utilizar para proteger la transmisión? A) Advanced Encription System (AES) B) Secure Hash Algorithm (SHA-II) C) Rivest, Shamir, Adleman (RSA) D) Message Digest 5 (MD5) 6. Ud. encuentra que un sistema de información guarda las contraseñas en plano. ¿Cuál de los siguientes algoritmos Ud. recomienda utilizar para almacenar las contraseñas? A) Advanced Encription System (AES) B) Secure Hash Algorithm (SHA-II) C) Rivest, Shamir, Adleman (RSA) D) Message Digest 5 (MD5) 7. ¿En cuál de las siguientes situaciones Ud. recomendaría la implementación de tokens como mecanismo de autenticación? A) Para conectarse a la red desde las oficinas de la compañía B) Para conectarse a un sitio web público sin https ( x ejm de un Banco) C) Para conectarse remotamente a través desde un cliente VPN D) Para conectarse a un sitio web público con https ( x ejm de un Banco) 8. Un auditor encuentra que los usuarios de una empresa trasnacional utilizan sin ningún tipo de restricción aplicaciones personales de almacenamiento en la nube tales como Dropbox, Google Drive, Microsoft One Drive entre otras para almacenar información de la Empresa. Los usuarios que utilizan estos servicios son considerados por el auditor como: A) Amenaza B) Impacto del riesgo C) Falta de control D) Vulnerabilidad
AUDITORÍA DE SISTEMAS MANUAL AUTOFORMATIVO
115
9. ¿Cuál de las siguientes opciones es la que otorga la postura más robusta de seguridad? A) Contraseña + Token B) Biometría + Token C) Contraseña + Tarjeta con chip D) Contraseña + Biometría 10. Ud. requiere configurar un WiFi corporativo basado en la tecnología Cisco. Al configurar el enrutador inalámbrico, el Sistema le presenta varias opciones para configurar la encriptación del tráfico. Al respecto, ¿Cuál de los siguientes algoritmos Ud. seleccionaría? A) 3DES
E
B) AES
ste manual autoformativo es el material didáctico más importante de la C) RSA presente asignatura. Elaborado por el D) SHA-II docente, orienta y facilita el auto aprendizaje de los contenidos y el desarrollo de las actividades propuestas en el sílabo.
muro y las tareas, siempre acompañado de tus docentes y amigos.
Los demás recursos educativos del aula virtual complementan y se derivan del manual. Los
El modelo educativo de la Universidad Continental a distancia es innovador, interactivo e integral, conjugando el conocimiento, la investigación y la innovación. Su estructura, organización y funcionamiento están de acuerdo a los estándares internacionales.
contenidos multimediaaudios, ofrecidos utilizando videos, presentaciones, clases interactivas, se corresponden a los contenidos del presente manual. La educación a distancia en entornos virtuales te permite estudiar desde el lugar donde te encuentres y a la hora que más te convenga. Basta conectarse al Internet, ingresar al campus virtual donde encontrarás todos tus servicios: aulas, videoclases, presentaciones animadas, biblioteca de recursos,
Es innovador, porque desarrolla las mejores prácticas del e-learning universitario global; interactivo, porque proporciona recursos para la comunicación y colaboración síncrona y asíncrona con docentes y estudiantes; e integral, pues articula contenidos, medios y recursos para el aprendizaje permanente y en espacios flexibles. Ahora podrás estar en la universidad en tiempo real sin ir a la universidad.
