Auditoria - de - Sistemas 2016

AUDITORA DE SISTEMAS
Gonzalo Martin Valdivia Benites

Auditora de sistemas. Manual Autoformativo
Gonzalo Martin Valdivia Benites
Primera edicin
Huancayo, mayo de 2016
De esta edicin
Universidad Continental, Modalidad Virtual
Av. San Carlos 1980, Huancayo-Per
Telfono: (51 64) 481-430 anexo 7361
Correo: recursosucvirtual@continental.edu.pe
http://virtual.ucontinental.edu.pe/
Direccin: Emma Barrios Ipenza

Edicin: Eliana Gallardo Echenique
Asistente de edicin: Andrid Poma Acevedo
Asesora didctica: Karine Bernal
Correccin de estilo: Corina Delgado Morales
Diseo y diagramacin: 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 recuperacin de informacin, en ninguna forma ni por ningn
medio sea mecnico, fotoqumico, electrnico, magntico, electro-ptico, por fotocopia, o
cualquier otro medio, sin el permiso previo de la Universidad Continental.
NDICE
INTRODUCCIN 7
COMPETENCIA DE LA ASIGNATURA 8
UNIDADES DIDACTICAS 8
TIEMPO MINIMO DE ESTUDIO 8
UNIDAD I: INTRODUCCIN A LA AUDITORIA DE SISTEMAS 9

DIAGRAMA DE PRESENTACIN DE LA UNIDAD I 9
ORGANIZACIN DE LOS APRENDIZAJES 9
TEMA N. 1: VISIN DE LA AUDITORIA DE SISTEMAS 11
INTRODUCCIN 11
1 Visin de la Auditoria 11
2 Estndares de ISACA 13
3 El riesgo como elemento clave de la Auditoria de Sistemas 15
TEMA N. 2: EL PROCESO DE LA AUDITORIA DE SISTEMAS 17

INTRODUCCIN 17
1 Planeamiento de la Auditoria 17
2 Programa de Auditoria. 18
INTRODUCCIN 23
1 Formulacin de los Hallazgos de Auditoria 23
2 Formulacin de las Recomendaciones 26
3 Formulacin del Informe de Auditoria 26
TEMA N. 4: MARCOS DE REFERENCIA DE AUDITORIA DE SISTEMAS 33

INTRODUCCIN 33
1 Regulaciones Internas 33
2 Regulaciones externas 35
ACTIVIDAD N. 1 42
CONTROL DE LECTURA N 1 42
GLOSARIO DE LA UNIDAD I 43
BIBLIOGRAFA DE LA UNIDAD I 43
AUTOEVALUACIN DE LA UNIDAD I 44
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIN DE TI 47

DIAGRAMA DE PRESENTACIN DE LA UNIDAD II 47
TEMA N. 1: GOBIERNO Y GESTIN DE T.I. 48
INTRODUCCIN 48
1 Gobierno Corporativo y Gobierno de TI 48
2 Practicas Gerenciales de Gestin de TI 49
3 Auditoria al Gobierno y a la Gestin de TI 58
LECTURA SELECCIONADA N. 1: 60
TEMA N. 2: CONTINUIDAD DE NEGOCIO Y RECUPERACIN DE DESASTRES 61
INTRODUCCIN 61
1 Gestin de la Continuidad de Negocio 61
2 Planeacin a la Continuidad de Negocio y Recuperacin de Desastres 63
3 Auditoria a la Continuidad de negocio 67
LECTURA SELECCIONADA N. 2 68
ACTIVIDAD N. 2 68
PARTICIPA EN EL FORO DE DISCUSIN SOBRE LAS PRCTICAS GERENCIALES EN EL REA DE SISTEMAS. 68
TAREA ACADEMICA N. 1 68
GLOSARIO DE LA UNIDAD II 69
BIBLIOGRAFA DE LA UNIDAD II 69
UNIDAD III: AUDITORA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE 73

DIAGRAMA DE PRESENTACIN DE LA UNIDAD III 73
TEMA N. 1: ETAPAS DEL CICLO DE VIDA 74
INTRODUCCIN 74
1 Ciclo de Vida de Desarrollo de Software 74
2 Controles de Entrada, procesamiento y Salida 78
TEMA N. 2: MANTENIMIENTO DE SISTEMAS 81

INTRODUCCIN 81
1 Mantenimiento de Sistemas 81
2 Procedimiento de Control de Cambios. 81
3 Implantacin de cambios 82
4 Documentacin 82
5 Cambios de emergencia. 82
6 Razones por las que suceden los cambios no autorizados 82
ACTIVIDAD N. 3 83
TEMA N. 3: APLICACIONES DE NEGOCIO 84
INTRODUCCIN 84
1 Aplicaciones de Negocio Verticales 84
TEMA N. 4: AUDITORIA AL CICLO DE VIDA 88

INTRODUCCIN 88
1 Auditoria al Ciclo de Vida 88
2 Auditoria al Mantenimiento de Sistemas 90
CONTROL DE LECTURA N 2 91
GLOSARIO DE LA UNIDAD III 91
BIBLIOGRAFA DE LA UNIDAD III 91
AUTOEVALUACIN DE LA UNIDAD III 92
UNIDAD IV: AUDITORA A LA SEGURIDAD DE LA INFORMACIN 95

DIAGRAMA DE PRESENTACIN DE LA UNIDAD IV 95
TEMA N. 1: SEGURIDAD DE LA INFORMACIN 96
INTRODUCCIN 96
1 Seguridad de la Informacin 96
2 Seguridad Informtica 98
TEMA N. 2: CONTROLES DE SEGURIDAD I 99

INTRODUCCIN 99
1 Gestin de Accesos 99
2 Criptografa 102
LECTURA SELECCIONADA N 1: 104

ACTIVIDAD N. 4 104
TEMA N. 3: CONTROLES DE SEGURIDAD II 105
INTRODUCCIN 105
1 Seguridad en Internet 105
2 Seguridad del Cloud 106
3. Seguridad de Mviles. 108
TEMA N. 4: AUDITORIA A LA SEGURIDAD DE LA INFORMACIN 110
INTRODUCCIN 110
1 Auditoria a la Seguridad de la Informacin 110
2 Auditoria a los controles de Seguridad. 110
LECTURA SELECCIONADA N 2: 112

TAREA ACADEMICA N 2 112
GLOSARIO DE LA UNIDAD IV 112
BIBLIOGRAFA DE LA UNIDAD IV 112
AUTOEVALUACIN DE LA UNIDAD IV 113
Auditora de sistemas
MANUAL AUTOFORMATIVO 7
INTRODUCCIN
B
ienvenido al curso de Auditoria de Sistemas! Gobierno y gestin de TI, las Practicas Gerenciales de
En este curso Ud. aprender los conceptos y las Gestin de TI y la forma de ejecucin de Auditorias al
tcnicas ms relevantes para realizar Auditoras Gobierno y a la Gestin de TI.
de Sistemas.
Un punto importante a recalcar en esta Unidad es que
La Auditoria de Sistemas es una de las ramas de Tec- aprenderemos a Auditar los procesos de Continuidad
nologas de Informacin ms importantes, retadoras y de Negocio y Recuperacin de Desastres, como un
excitantes y al mismo tiempo es una de las ramas menos asunto vital para la supervivencia de las organizaciones
conocidas y tambin por qu no decirlo?, la Auditoria que cada dia dependen ms de las T.I.
de Sistemas es una rama muy rentable.
En la Unidad III tendremos la Auditoria al Ciclo de Vida
La asignatura sigue las mejores prcticas de la Infor- de desarrollo de Software. Aqu revisaremos las Etapas
mation Systems Audit and Control Association(ISACA) del ciclo de vida de Desarrollo de Software, as como los
que es la institucin mundial ms importante en Audi- controles que todo software debe implementar. Por otro
toria de Sistemas. lado estudiaremos los procedimientos de Mantenimien-
to de Sistemas y revisaremos algunas aplicaciones de
La asignatura est estructurado en 4 Unidades: Negocio especficas que los Auditores suelen revisar. Al
finalizar esta Unidad revisaremos la Auditoria al Ciclo
La primera Unidad est enfocada en el proceso de Au-
de Vida de Desarrollo de Software y al Mantenimiento
ditoria. En este parte Ud. aprender los conceptos b-
de Software.
sicos y el proceso a seguir para realizar Auditoras de
Sistemas. En la ltima Unidad nos enfocaremos en la Auditoria a
la Seguridad de la Informacin. Revisaremos las tcni-
Tambin Ud. aprender a redactar Hallazgos de Audi-
cas y procedimientos de Seguridad de la Informacin y
toria as como informes de Auditoria, donde expresa
Seguridad Informtica, enfocndonos en temas como
su opinin con respecto a una determinada materia o
encriptacin, control de acceso, seguridad de Internet,
situacin. L finalizar e esta Unidad revisaremos los prin-
Cloud, Mviles, entre otros. Finalizaremos esta Unidad
cipales Marcos de referencia de auditoria tanto naciona-
con la Auditoria a la seguridad de la informacin
les como internacionales que utilizan los Auditores en
la ejecucin de su Auditoria. Espero que el curso sea de su provecho y que el conte-
nido aporte su granito de arena para que lo ayude a Ud.
En la Unidad II revisaremos la Auditoria al Gobierno y
en un profesional ms completo. Y por qu no? Este
Gestin de TI. En esta parte revisaremos el Gobierno
curso puede descubrir que Ud. podra ser un excelente
Corporativo y el Gobierno de TI, las diferencias entre
Auditor de Sistemas.
8
PRESENTACIN DE LA ASIGNATURA
Diagrama Objetivos Inicio
COMPETENCIA DE LA ASIGNATURA
Realizar de manera efectiva procesos de auditora de sistemas a la organizacin, procesos y soluciones tecnolgicas
existentes
Desarrollo en Actividades
las reas deAutoevaluacin
Sistemas, a travs de la identificacin de los riesgos asociados a las tecnologas de informacin
de
encontenidos
las organizaciones de hoy; aplicando los principales estndares, normas, metodologas y mejores prcticas a nivel
mundial en auditoria de sistemas.
UNIDADES DIDACTICAS
Lecturas Glosario
seleccionadas
Bibliografa
UNIDAD I UNIDAD II UNIDAD III UNIDAD IV
Introduccin a la Auditoria de Auditoria al Gobierno y Gestin Auditoria al Ciclo de Vida de Auditoria a la seguridad de la
Sistemas de TI desarrollo de Software informacin
Recordatorio Anotaciones Chat
TIEMPO MINIMO DE ESTUDIO

UNIDAD I UNIDAD II UNIDAD III UNIDAD IV
1era. Semana y 3era. Semana y 5ta. Semana y 7ma. Semana y

2da. Semana 4ta. Semana 6ta. Semana 8va. Semana
16 horas 16 horas 16 horas 16 horas
UNIDAD I: INTRODUCCIN A LA AUDITORIA DE SISTEMAS

Desarrollo Actividades Autoevaluacin
de contenidos
DIAGRAMA DE PRESENTACIN DE LA UNIDAD I

Lecturas Glosario Bibliografa
Diagrama
seleccionadas Objetivos Inicio
CONTENIDOS EJEMPLOS ACTIVIDADES

Desarrollo
Recordatorio Actividades
Anotaciones Autoevaluacin
Chat
de contenidos
AUTOEVALUACIN BIBLIOGRAFA
seleccionadas
ORGANIZACIN DE LOS APRENDIZAJES

CONOCIMIENTOS PROCEDIMIENTOS ACTITUDES
Video de presentacin de la asignatura 1. Infiere los procedimientos de auditora a 1. Valora la importancia de la ejecucin de
Unidad I: Introduccin a la Auditoria de aplicar. la auditoria de sistemas.
Sistemas 2. Participa en la definicin de los controles 2. Se auto valora por su aprendizaje de las
1 Videoclase (Video conferencia) para minimizar riesgos. tcnicas de auditoria de siste-mas.
3. Identifica las diferentes actividades en la 3. Asume el compro-miso de revisar los
ejecucin de la Auditoria contenidos del manual.
Tema N. 1: Tema 1
4. Identifica las diferentes actividades en la 4. Valora la importancia de la auditoria de
1. Visin de la Auditoria planificacin de la Auditoria sistemas para el mejora-miento de una
2. Estndares de ISACA 5. Identifica las diferentes actividades en la empresa y para las actividades o procesos
3. El riesgo como elemento clave de la Audi- ejecucin de la Auditoria a realizar.
toria de Sistemas 5. Participa activa-mente en el desarrollo de
las actividades de la asignatura.
Actividad N. 1
Tema N. 2: El proceso de Auditoria de Participan en el Foro de discusin sobre Los
Sistemas riesgos originados por el uso de las Tecnolo-
1. Planeamiento de Auditoria gas de Informacin en las organizaciones.
2. Programa de Auditoria
Lectura seleccionada 1
Ttulo: Auditoria de Sistemas. Disponible en:
http://www.gerencie.com/auditoria-de-siste-
mas.html
10 UNIDAD I: Introduccin a la Auditoria de Sistemas
2 Videoclase 1. Identifica el riesgo y escribe hallazgos de

auditoria.
Tema N. 3: Hallazgos y observaciones de 2. Analiza y utiliza lo explicado en un caso
Auditoria prctico.
1. Formulacin de los hallazgos de Audito- 3. Identifica los estndares, las directrices y
ria las prcticas relacionadas.
2. Formulacin de recomendaciones para 4. Identifica leyes, regulaciones y estn-dares
minimizar los riesgos identificados relevantes.
3. Formulacin del Informe de Auditoria 5. Utiliza los marcos de referencia en los
hallazgos de auditoria.
Tema N. 4: Marcos de referencia de audi-

toria Control de Lectura N 1
1. Marcos Internacionales: CobiT, Familia Formula Observaciones de Auditoria del
ISO 27001. caso Auditoria de Sistemas en una empresa
regional.
2. Marcos Nacionales: Contralora General
de la Repblica, Superintendencia de
Banca y Seguros.
Lectura seleccionada 2
Ttulo: CobiT5-Introduction-Spanish.
Disponible en: www.isaca.org/COBIT/Docu-
ments/COBIT5-Introduction-Spanish.ppt
Autoevaluacin N 1
UNIDAD I: Introduccin a la Auditoria de Sistemas MANUAL AUTOFORMATIVO 11
TEMA N. 1: VISIN DE LA AUDITORIA DE SISTEMAS
INTRODUCCIN
Este tema est preparado para que tengas tu primer contacto con la Auditoria de Sistemas. En este primer tema toca-
remos los puntos ms importantes de la Auditoria de Sistemas.
1 V
ISIN DE LA AUDITORIA
1.1 Qu es la Auditoria?
La Auditoria es un proceso sistemtico de evaluacin post-mortem y de formacin de opinin sobre una determinada
materia o situacin. Para nuestro caso sobre una materia o situacin relacionada a Tecnologa de Informacin tal
como un Sistema Informtico, una Base de datos, una Infraestructura tecnolgica, unos Servidores, la gestin del Ge-
rente de TI, un proceso de atencin de soporte tcnico a usuarios, etc.
Este proceso es realizado por los Auditores quienes son profesionales que se encargan de realizar la evaluacin y en
funcin su evaluacin forma una opinin sobre dicha materia o situacin.
Aqu vale la pena mencionar que las auditorias tambin pueden ser previas o durante la ejecucin de una determinada
materia o situacin.
1.2 Tipos de Auditoria
Existen muchos tipos de Auditoria. Entre las principales tenemos:
Financieras. En estas Auditorias el Auditor forma una opinin si los estados financieros (balance general, de una
empresa reflejan la realidad financiera de la empresa.
Operacionales. En estas Auditorias Operacionales se forma una opinin de la efectividad de los controles operati-
vos de los procesos de una compaa. Por ejemplo compras, ventas, produccin, etc.
Cumplimiento. En las Auditorias de Cumplimiento, se forma una opinin 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 opinin de la efectividad de los controles tecnolgi-
cos para minimizar los riesgos por el uso de la tecnologa.
Las Auditorias Financieras se realizan al menos una vez al ao. Muchas entidades reguladoras exigen que se realicen
Auditorias Financieras. Por ejemplo la Superintendencia de Mercado de Valores (SMV) exige que se realicen audito-
rias financieras a las compaas que cotizan en la Bolsa. Asimismo la Contralora General de la Republica (CGR) exige
que las Entidades del Estado realicen una auditoria una vez al ao. La Superintendencia de Banca, Seguros y AFP
(SBS) audita que los Bancos e Instituciones Financieras al menos una vez al ao.
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 algn problema en el rea
de TI, o cuando un nuevo Gerente de TI la solicita para tomar conocimiento de la situacin que recibe.
1.3 Auditoria Interna vs. Auditoria Externa.
Las Auditorias pueden ser internas o externas en funcin 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 compaa. En una Auditoria Interna se tiene la ventaja del nivel de profundidad de la auditoria. Dado que
1.3 Auditoria Interna vs. Auditoria Externa.
Las Auditorias pueden ser internas o externas en funcin de quien realiza la
12 Auditoria. As tenemos: UNIDAD I: Introduccin a la Auditoria de Sistemas
Auditoria Interna. Una Auditoria es considerada Interna cuando el Audi-
tor o equipo de Auditoria labora dentro de la misma compaa. En una
Auditoria Interna se tiene la ventaja del nivel de profundidad de la audi-
toria.
los Auditores son Dadotienen
internos que lalos Auditores
ventaja son internos
de conocer el negociotienen
y pueden la realizar
ventaja de conocer
auditoras ms detalladas. Una
el negocio
desventaja podra ser que eny caso
pueden realizar
hubiese auditoras
algn tipo msentre
de relacin detalladas.
el AuditorUna desventaja
y la materia auditada, el Auditor
podra ser que en caso hubiese algn tipo de relacin entre el Auditor y
perdera su independencia.
la materia auditada, el Auditor perdera su independencia.
En Per
En Per los Auditores los laboran
internos Auditores internos
en el rea de laboran
Auditoriaen el rea
Interna. En de Auditoriadel
las Entidades Interna.
Estado laboran en las
Oficinas de ControlEnInterno
las Entidades
(OCI). del Estado laboran en las Oficinas de Control Interno
(OCI).
Auditoria
Auditoria Externa. En esteExterna. En este
caso, el Auditor caso,de
o equipo elAuditoria
Auditor pertenece
o equipoade unaAuditoria
compaa perte-
externa que tiene una
nece por
experiencia amplia a una
habercompaa externacompaas
auditado muchas que tiene deuna experiencia
diversos amplia
rubros. Como una por ha- se tiene que
desventaja
ber auditado
la Auditoria Externa podra sermuchas compaas
menos detallada denormalmente
ya que diversos rubros.
cuentanComocon ununa desven-
periodo de tiempo reducido
(semanas o pocostajameses)
se tiene
paraque la Auditoria
realizar la revisin.Externa podra ser menos detallada ya que
normalmente cuentan con un periodo de tiempo reducido (semanas o
pocos meses) para realizar la revisin.
1.4 Las Big Four.
Cuando1.4una Las Big Four.

empresa requiere realizar una Auditoria Externa, es muy frecuente que las compaas contraten a una de
Cuando
las llamadas Big Four paraunaque
empresa
realicen requiere realizar una Auditoria Externa, es muy fre-
la Auditoria.
cuente que las compaas contraten a una de las llamadas Big Four para que
realicen
Se llama Big Four la Auditoria.
al conjunto de las 4 compaas internacionales ms prestigiosas en el campo de la auditoria, tal como
se muestra enSeel llama
grfico Big
1. Four al conjunto de las 4 compaas internacionales ms pres-
tigiosas en el campo de la auditoria, tal como se muestra en el grfico 1.
Figura 1. Las Big Four.
Grfico
Si te interesa saber ms de estas compaas, N 1 ms
puedes obtener Lasinformacin
Big Four. en las siguientes direcciones:
Si te interesa saber ms de estas compaas, puedes obtener ms informa-

Deloitte: http://www2.deloitte.com/pe/es/services/auditoria.html?icid=top_auditoria
cin en las siguientes direcciones:
Deloitte:
Price Waterhouse Coopers:
http://www2.deloitte.com/pe/es/services/auditoria.html?icid=top_auditoria
Price Waterhouse Coopers:
http://www.pwc.com/pe/es/servicios/assurance.html
http://www.pwc.com/pe/es/servicios/assurance.html
Ernst
Ernst & Young: & Young: http://www.ey.com/PE/es/Services/Assurance
http://www.ey.com/PE/es/Services/Assurance
KPMG: http://www.kpmg.com/pe/es/servicios/audit/paginas/default.aspx
KPMG: http://www.kpmg.com/pe/es/servicios/audit/paginas/default.aspx
1.5 Qu es la Auditoria de Sistemas?

1.5 Qu es la Auditoria de Sistemas?
La Auditoria de Sistemas se refiere a la Auditoria de materias o situaciones
La Auditoria relacionadas a las Tecnologas
de Sistemas se refiere a la Auditoriadede Informacin.
materias o situaciones relacionadas a las Tecnologas de Informa-
cin. El auditor de Sistemas tiene el negocio de encontrar riesgos. Veamos un
ejemplo: Imagina que te contratan como Auditor de Sistemas de una com-
El auditor depaa y altiene
Sistemas hacer la revisin
el negocio de de un Servidor
encontrar riesgos.de Baseun
Veamos deejemplo:
Datos (todava no sa-
Imagina que te contratan como
bes cmo
Auditor de Sistemas se compaa
de una hace, noyte preocupes
al hacer aunde
la revisin por
un eso), encuentras
Servidor de Base de que
Datosdicho Ser-
(todava no sabes cmo se
hace, no te preocupes aun por eso), encuentras que dicho Servidor no cuenta con Antivirus. Tambin encuentras que
la contrasea del super usuario de la Base de datos no ha sido cambiada desde hace 3 aos y encuentras 9 que al Sistema
Operativo nunca se le han instalado parches del fabricante (Imagina que es un Windows Server).
Estas 3 situaciones que encontraste pueden originar riesgos? Se cuenta con los controles adecuados para minimizar
los riesgos? O todo lo contrario? Qu opinin te vas formando de esta situacin? Ese es el trabajo del Auditor de
Sistemas: encontrar situaciones que originan riesgos.
vidor no cuenta con Antivirus. Tambin encuentras que la contrasea del su-
per usuario de la Base de datos no ha sido cambiada desde hace 3 aos y
encuentras que al Sistema Operativo nunca se le han instalado parches del
fabricantea la
UNIDAD I: Introduccin (Imagina
Auditoria que es un Windows Server).
de Sistemas MANUAL AUTOFORMATIVO 13
Estas 3 situaciones que encontraste pueden originar riesgos? Se cuenta
con los controles adecuados para minimizar los riesgos? O todo lo contra-
rio? Qu opinin te vas formando de esta situacin? Ese es el trabajo del
Auditor de Sistemas: encontrar situaciones que originan riesgos.
2 ESTNDARES DE ISACA
2. Estndares de ISACA
2.1 ISACA
2.1 ISACA
Los Auditores de Sistemas estn agrupados en gremios profesionales. A nivel mundial una de las instituciones ms
Los
prestigiosas es Auditores de
la Information Sistemas
System estn
Audit and agrupados
Control en(ISACA).
Association gremios profesionales. A ni-
vel mundial una de las instituciones ms prestigiosas es la Information Sys-
ISACA es unatem Audit and
institucin Control
con Sede Association
en Chicago, (ISACA).
Estados Unidos, que agrupa a los profesionales de auditoria, control,
ISACA
riesgo y gobierno dees TI.una institucin
Te invito con
a que le desSede en Chicago,
un vistazo Estados Unidos,
a esta institucin. que agrupa
Puedes encontrar ms ainformacin en
los profesionales de auditoria, control, riesgo y gobierno de TI. Te invito a
http://www.isaca.org
que le des un vistazo a esta institucin. Puedes encontrar ms informacin
Asimismo ISACAen http://www.isaca.org
es uno de las entidades certificadoras de profesionales ms importantes del mundo. Actualmente,
ISACA ofreceAsimismo ISACAlasescuales
4 certificaciones, uno son:
de las entidades certificadoras de profesionales ms
importantes del mundo. Actualmente, ISACA ofrece 4 certificaciones, las
cualesInformation
CISA (Certified son: Security Auditor)
CISA (Certified Information Security Auditor)
CISM
CISM (Certified (CertifiedSecurity
Information Information
Manager)Security Manager)
CGEIT (Certified in the Governance of Enterprise IT)
CRISC
CGEIT (Certified (Certified
in the in Risk
Governance and Information
of Enterprise IT) Systems Control)
CRISC (Certified in Risk and

Para Auditoria deInformation
Sistemas, Systems Control) la Certificacin que nos sirve es
evidentemente
la CISA. Si a lo largo del curso, descubres que la Auditoria de Sistemas te in-
Para Auditoria de Sistemas,
teresa y ves evidentemente la Certificacin para
que tienes competencias que nos sirve es la CISA.
identificar Si a entonces
riesgos, lo largo deltu
curso, descubres
que la Auditoria de Sistemas
podras ser untefuturo
interesa y ves que
Auditor tienes En
CISA. competencias para identificar
la figura adjunta riesgos,como
te muestro entonces
es tu podras ser
un futuro Auditor CISA. En laCISA:
un certificado figura adjunta te muestro como es un certificado CISA:
Figura 2 Muestra de un Certificado CISA

Figura 2. Muestra de un Certificado CISA.
Encontraras ms informacin de la certificacin CISA en:
Encontraras ms informacin de la certificacin CISA en: http://www.isaca.org/Certification/CISA-Certified-Infor-
http://www.isaca.org/Certification/CISA-Certified-Information-Systems-
mation-Systems-Auditor/Pages/default.aspx
Auditor/Pages/default.aspx
2.2 Estndares de ISACA
ISACA cuenta con un framework de Auditoria de Sistemas denominado A Professional practices Framework for IS
Audit/Assurance, ms conocido como el framework ITAF.
A continuacin, vamos a detallar los estndares ms relevantes para nuestro curso.

10
Estndar 1003 Independencia profesional. El estndar indica textualmente que: Los profesionales de auditora 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 auditora y aseguramiento. Esto significa que no debe haber ninguna relacin entre al Auditor y la
materia que se est auditando. Por ejemplo, imagnate que estas auditando una compaa y tu esposa trabaja para
dicha compaa. En este caso podra afectarse tu independencia. Si encuentras muchos riesgos, el que pueda estar
en riesgo eres tu!. Esprate al llegar a casa!
Estndar 1006 Competencia. Los profesionales de auditora y aseguramiento de SI, junto con otras personas que ayudan en
la asignacin, deben poseer las habilidades y la competencia adecuadas para realizar las asignaciones de auditora y aseguramien-
to de SI y ser profesionalmente aptos para realizar el trabajo requerido. Por ejemplo no podemos hacer una Auditoria de
Sistemas a un cajero automtico sino tenemos la mnima idea de cmo funciona por dentro. En este caso no somos
competentes para realizar la evaluacin.
Estndar 1201 Evaluacin de riesgo en planificacin: La funcin de auditora y aseguramiento de SI debe utilizar un enfo-
que de evaluacin de riesgo adecuado y metodologa de respaldo para desarrollar el plan completo de auditora de SI y determinar
las prioridades para la asignacin efectiva de los recursos de auditora de SI. Como dijimos el riesgo es primordial para el
Auditor de Sistemas. En funcin del riesgo se planifica que auditar y con qu prioridad.
Estndar 1204 Materialidad. Los profesionales de auditora y aseguramiento de SI deben considerar las debilidades potenciales
o ausencias de controles mientras planifican una asignacin y si esas debilidades o ausencias de controles pudieran resultar en
una deficiencia significativa o una debilidad material.
Estndar 1205 Evidencia: Los profesionales de auditora 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, documentacin, pantallazos, etc.
Estndar 1207 irregularidad y Actos irregulares: Los profesionales de auditora y aseguramiento de SI deben considerar el
riesgo de irregularidades y actos ilegales durante la auditoria.
Los profesionales de auditora y aseguramiento de SI deben mantener una actitud de escepticismo profesional durante la asignacin.
Los profesionales de auditora 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 obligacin de obtener la evidencia correspondiente e informarlo, no podemos ignorarlo.
Estndar 1401 Reportes: Los profesionales de auditora y aseguramiento de SI deben proporcionar un reporte para comunicar
los resultados al concluir la auditoria, que incluye:
Identificacin de la empresa, los destinatarios previstos y cualquier restriccin sobre el contenido y la circulacin
Alcance, objetivos de la asignacin, perodo de cobertura y la naturaleza, los plazos y el alcance del trabajo realizado
Hallazgos, conclusiones y recomendaciones de la auditora
Cualquier calificacin o limitacin dentro del alcance que el profesional de auditora y aseguramiento de SI tenga con respecto a
la asignacin
Firma, fecha y distribucin segn los trminos del estatuto de la funcin de auditora o carta de asignacin de auditora. Como
ves, este estndar nos indica caramente cuales son los entregables de la Auditoria de Sistemas.
Estndar 1402 Actividades de Seguimiento: Los profesionales de auditora y aseguramiento de SI deben monitorear infor-
macin relevante para concluir si la direccin ha planeado/tomado la accin oportuna y apropiada para abordar los hallazgos y
las recomendaciones de la auditora reportados. El seguimiento se refiere a revisar que los auditados hayan ejecutado las
recomendaciones de la Auditoria de Sistemas del periodo anterior.
Estos estndares no son los nicos. Una lista completa de los estndares de Auditoria, los puedes encontrar en:
http://www.isaca.org/Knowledge-Center/ITAF-IS-Assurance-Audit-/IS-Audit-and-Assurance/Pages/Stan-
dards-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
3 EL RIESGO COMO ELEMENTO CLAVE DE LA AUDITORIA DE SISTEMAS
3.1 Identificar el riesgo
En la seccin 1.5 vimos un ejemplo de 3 situaciones que originan riesgo. Ahora imagina que haces la revisin y no
encuentras situaciones de riesgo. Es decir, haces la Auditoria y se te escapan estos puntos. Es decir no encuentras las
situaciones que originan los riesgos (que en el ejemplo son muy evidentes). Qu opinin te formaras? 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 definicin de la Norma ISO 13335. El riesgo es la probabilidad que una amenaza se aproveche de una vul-
nerabilidad y nos genera un dao.
Aqu la amenaza es cualquier cosa que tenga el potencial de hacer dao.
La vulnerabilidad es cualquier deficiencia que se tenga.
El dao es el impacto negativo que tenemos si la amenaza se aprovecha de la(s) vulnerabilidad(es). El dao pude ser
econmico, patrimonial, de imagen, etc.
Volvamos a las tres situaciones identificadas del primer ejemplo. Tenemos que:
El Servidor no cuenta con Antivirus.
La contrasea del super usuario de la Base de datos no ha sido cambiada desde hace 3 aos y
Al Sistema Operativo nunca se le han instalado parches del fabricante
Descompongamos la primera situacin en funcin de la definicin del riesgo:
Cul sera la amenaza? Es evidente que lo que nos puede hace dao aqu es el malware.
Cul sera la vulnerabilidad? La propia inexistencia del Antivirus es la vulnerabilidad.
Cul sera el dao? El ingreso de malware podra originar la inutilizacin del servidor, el robo de informacin del
servidor, entre otros.
Ahora, veamos la segunda situacin:
Cul sera la amenaza? Cualquier persona que tenga acceso al servidor y que conozca o adivine la contrasea es con-
siderada una amenaza.
Cul sera la vulnerabilidad? Mantener la misma contrasea es la vulnerabilidad.
Cul sera el dao? El robo o la modificacin de la informacin contenida en el servidor.
Finalmente, veamos la tercera situacin:
Cul sera la amenaza? El malware o los criminales informticos son las amenazas.
Cul sera la vulnerabilidad? El no actualizar los parches del Sistema Operativo
Cul sera el dao? El robo o la modificacin de la informacin contenida en el servidor.
Como vez, en las 3 situaciones se encuentra la amenaza, la vulnerabilidad y el dao.
Los Auditores de Sistemas se enfocan en identificar los riesgos.

3.2 Qu se hace con el riesgo?
Una vez que el riesgo ha sido identificado, el riesgo debe ser tratado.
El trmino 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 podra ser contratar una
pliza 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 origen al riesgo. A esta opcin 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 origen al riesgo. Pero esta accin ha tenido un costo muy
alto. Si bien es cierto que elimine el riesgo de infeccin, tambin 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 trmino
ms 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 funcin es detectar problemas antes de que estos
ocurran. Por ejemplo una pantalla de usuario y contrasea de acceso a un Sistema o la encriptacin de datos sen-
sibles.
Detectivos. Estos controles como su nombre lo indica detectan y reportan la ocurrencia de un incidente, error o
situacin. Por ejemplo un log de auditoria, una alarma o una funcin 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 evalan los Auditores de Sistemas
y los riesgos que se identifican.
TEMA N. 2: EL PROCESO DE LA AUDITORIA DE SISTEMAS
INTRODUCCIN
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 funcin al riesgo y para ello es esencial la planificacin y luego de ella, la ejecucin de la Auditoria.
1 PLANEAMIENTO DE LA AUDITORIA
1.1 Planeamiento de la Auditora de Sistemas
Ahora ya estamos listos para empezar nuestra primera Auditoria. Por dnde empezamos? Pues por el principio. Es
decir, por el Planeamiento. El planeamiento adecuado es el primer paso para efectuar auditoras de TI eficaces.
Cmo 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 despus.
Planeamiento individual. Este planeamiento se debe hacer para cada Auditoria definida en el punto anterior.
Segn ISACA debemos seguir los siguientes pasos para realizar una planificacin de Auditoria.
Comprender el negocio. Esto significa comprender la misin, 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 polticas, 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 logstica de trabajo a la Auditoria.
Por otro lado es imprescindible que el Auditor considere las leyes y regulaciones que aplican a la compaa. Por ejem-
plo 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 compaa de electricidad hay que identificar la regulacin del Orga-
nismo Supervisor de la Inversin en Energa y Minera (OSINERGMIN). Si vamos a auditar una compaa telefnica
la regulacin a identificar ser la de Organismo Supervisor de Inversin Privada en Telecomunicaciones (OSIPTEL).
Debes tener en cuenta que histricamente existen 2 tipos de industria que son altamente regulados: la banca y finanzas
y las compaas de telecomunicaciones.
1.2 Ejemplo de planificacin de Auditoria.
Veamos un ejemplo de la planificacin de manera general. Tenemos que planificar una Auditoria de Sistemas Externa
a una compaa de distribucin de electricidad ubicada en el sur del pas.
Comprender el negocio. Habamos dicho que en este punto se debe comprender la misin, los objetivos, y los pro-
cesos de negocio. Una forma inicial es ingresar a la pgina web de la Compaa. En la seccin Concenos o Quienes
somos o seccin similar del sitio Web se puede obtener la Misin, Visin y alcance de lo que hace la compaa. Por
ejemplo de una rpido recorrido a la pgina Web de nuestra compaa de ejemplo obtuvimos:
Nuestra misin:
Contribuir con el desarrollo de la regin sur, brindando oportunamente productos y servicios elctricos de calidad a
satisfaccin del cliente, con personal comprometido; consolidando de manera sostenida la rentabilidad de la empresa.
Nuestra visin:
Ser reconocidos como la mejor empresa distribuidora de energa elctrica en el pas.
Al revisar la misin se indica que brindan productos y servicios elctricos, los cuales se soportan en el uso de tecnolo-
gas de Informacin, 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) encontrare-
mos mucha informacin que utilizaremos para nuestra planificacin.
Entender los cambios en el entorno de negocios del auditado. Aqu debemos identificar los riesgos a los que est
expuesta la compaa y el riesgo al que est expuesta por el uso de la tecnologa de la informacin. Asimismo se
debe tener un claro conocimiento de las regulaciones que aplican que para este casos seran las de OSINERGMIN.
Identificar la estructura organizacional, as como las polticas, normas, procedimientos que le aplican. Para poder
planificar debemos tomar conocimiento de del Organigrama de la compaa, como funciona la compaa, que pro-
cesos tienen y como operan y tomar conocimiento de todo el conjunto de documentos normativos internos. Este
conjunto de documentos lo constituyen las polticas, las normas, las directivas, los estndares, los procedimientos e
instructivos. Cada compaa es diferente y los nombres de los tipos de documentos podran variar.
Establecer el alcance y los objetivos de la Auditoria. En funcin a los puntos anteriores, ya tenemos una buena
idea de los riesgos de la tecnologa 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 elctricos.
Dirigir la logstica 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 pas hay que trasladar tiles de oficina, personas lo que significa
pasajes, estada, viticos y resolver todos los temas como en donde van a trabajar los auditores, la seguridad de la
ubicacin de los auditores, su equipamiento informtico, su conexin y acceso a la red, entre otros.
2 PROGRAMA DE AUDITORIA.
2.1 Fases para la ejecucin de la Auditoria.
Una vez que hemos planificado la Auditoria, ya estamos listos para ejecutar la Auditoria. Las Auditorias de Sistemas
tpicamente siguen las siguientes fases:
Conocimiento del rea / tema de la auditora.
Planeamiento detallado de la auditora
Revisin preliminar del rea a auditar
Evaluacin del rea/tema a auditar
Verificacin y evaluacin de los controles
Realizacin de Pruebas de cumplimiento
Realizacin de Pruebas sustantivas
Formulacin del Informe comunicando los resultados
Seguimiento
2.2 Evidencia de Auditoria.
Es un requisito que las conclusiones del auditor estn 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 informacin o evidencia
Objetividad de la evidencia
Oportunidad de la evidencia
Asimismo, existen diversas tcnicas para recopilar evidencia
Revisin del organigrama de SI
Revisin de las polticas, las normas y los procedimientos de SI
Revisin de la documentacin de SI
Entrevistas a personal clave
Observacin de los procesos y el desempeo del personal
2.3 Ejemplo de un programa de Auditoria.
A continuacin revisaremos un programa de Auditoria de la compaa Elctrica SuperElectro.

PROGRAMA DE AUDITORIA
I. INTRODUCCION
Naturaleza
La actividad principal de SuperElectro S.A., es la distribucin y comercializacin de energa elctrica, en las unidades de concesin
otorgadas por el Estado Peruano, as como la generacin y transmisin elctrica 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 Elctricas, publicado el 19 de Noviembre de 1992 y modificatorias.
Decreto Supremo N. 009-93-EM Reglamento de la Ley de Concesiones Elctricas, disposiciones, modificatorias y complemen-
tarias.
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 Inversin de Energa OSINERGMIN, 1996.
Ley N. 26887, Ley General de Sociedades, sus modificatorias y ampliatorias
Ley N. 27293, Ley del Sistema Nacional de Inversin Pblica.
Ley N. 28716 Ley de Control Interno de las Entidades del Estado, publicada el 17 de abril del 2006.
Normas de Tecnologas de Informacin y Comunicaciones
Modificacin al Plan de Gestin Corporativa de Tecnologa de Informacin y Comunicaciones para las empresas bajo el mbito
de FONAFE (2009-2011) aprobada mediante Resolucin de Direccin Ejecutiva N 046-2009/DE-FONAFE.
Aprobar el Nuevo Texto de los Lineamientos para el Uso de las Firmas Digitales e Intercambio Electrnico de Documentos-SIED
entre FONAFE y las empresas bajo su mbito, que en el anexo 1 forman parte del presente acuerdo. Resolucin Direccin Ejecu-
tiva N. 027-2011/DE-FONAFE.
Plan de Gestin Corporativa de Tecnologa de Informacin y Comunicaciones para las empresas bajo el mbito de FONAFE
(2008-2011) aprobada mediante Resolucin de Direccin 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.
Estructura del Informe
El informe de Auditoria se ceir a lo dispuesto en las Normas de Auditoria Gubernamental; tanto en lo que se refiere a su estruc-
tura como a su contenido, para lo cual se deber tener en cuenta lo siguiente:
I. Introduccin.
II. Hallazgos.
III. Conclusiones.
IV. Anexos.
I. INTRODUCCION
1. Origen del examen.
2. Naturaleza y objetivos del examen.
3. Alcance del examen.
4. Antecedentes y base Legal de la Empresa.
5. Comunicacin de Hallazgos.
6. Memorndum de Control Interno.
7. Otros aspectos de importancia.
II. HALLAZGOS
Se incluirn hallazgos determinados como consecuencia del trabajo de campo realizado y la aplicacin de los procedimientos de
Auditoria segn nuestro programa de trabajo.
Dichas observaciones sern evaluadas con las respuestas de los hallazgos comunicados a las personas comprendidas en los mismos,
as como la documentacin y evidencia sustentatoria respectiva.
Estarn referidos a asuntos significativos, e incluirn informacin suficiente y competente.
Cada observacin deber redactarse en forma narrativa, teniendo en cuenta para su presentacin los aspectos siguientes:
1) Sumilla.
2) Elementos de la Observacin:
2.a) Condicin.
2.b) Criterio.
2.c) Efecto.
2.d) Causa.
3) Comentarios y/o aclaraciones del personal comprendido en las observaciones.
4) Evaluacin de los comentarios y/o aclaraciones presentados.
Tal como lo dispone las Normas de Auditoria Gubernamental, el contenido del informe revelar cada observacin considerando lo
siguiente:
- Ttulo que utiliza el hecho observado (sumilla).
- La situacin irregular o deficiencia hallada (condicin).
- Las normas transgredidas (criterio).
- Las razones fundamentales por la cual ocurri la condicin 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 carcter 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 supera-
cin de las observaciones o Hallazgos de la evaluacin de la gestin.
V. ANEXOS
Se utilizar los anexos indispensables que competen o amplen la informacin de importancia contenida en el mismo.
La exposicin respecto a la evaluacin del cumplimiento y aplicacin de los controles Tecnolgicos, deber contener comentarios por
cada rea y/o sistema examinado, las cuales se citarn en el informe, incluyendo los aspectos de incidencia.
Adems deber darse una apreciacin crtica sobre el funcionamiento de cada rea y sistema con relacin a la Empresa considerada
en su integridad.
TEMA N. 3: HALLAZGOS DE AUDITORIA DE SISTEMAS
INTRODUCCIN
En esta seccin de la asignatura aprenders a escribir hallazgos de Auditoria de Sistemas tal cual lo hacen los Auditores
de Sistemas profesionales.
1 FORMULACIN DE LOS HALLAZGOS DE AUDITORIA
1.1 Hallazgos de Auditoria
Como ya se mencion, el trabajo del Auditor de Sistemas es identificar situaciones que originan riesgo y recomendar
controles adecuados para su minimizacin.
Cuando el Auditor encuentra una situacin de riesgo, escribe un Hallazgo de Auditoria. A continuacin te presentar
los componentes de un Hallazgo de Auditoria:
Titulo
Descripcin
Riesgo
Recomendacin
El titulo o sumilla presenta de forma precisa el hecho encontrado.
Cada hallazgo tiene 3 prrafos:
La descripcin presenta la situacin o acto irregular que el Auditor detecto.
El riesgo se refiere al dao que se ha originado o podra originarse si el riesgo se materializa.
La recomendacin es el control que el auditor propone para reducir el riesgo.
1.2 Hallazgo de Auditoria en el Sector pblico.
En la Auditoria a una empresa del Estado, se incluyen observaciones determinadas como consecuencia del trabajo de
campo realizado y la aplicacin de los procedimientos de Auditoria segn el programa de auditoria. Las observaciones
estn referidas a asuntos significativos, e incluirn informacin suficiente y competente.
El formato del hallazgo se ampla a 6 prrafos, esto debido a que as lo exige la normatividad de la Contralora General
de la Republica.
Titulo
Condicin
Criterio
Causa
Riesgo
Recomendacin
Conclusin
El Ttulo describe el hecho observado (sumilla).
Cada hallazgo tiene 6 prrafos:
La situacin irregular o deficiencia hallada (condicin).
Las normas transgredidas (criterio).
Las razones fundamentales por la cual ocurri la condicin 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 recomendacin es el control que el auditor propone para reducir el riesgo.
La conclusin es la conclusin del Auditor despus de dar la oportunidad de rplica al auditado.
Las observaciones son evaluadas con las respuestas de los hallazgos comunicados a las personas comprendidas en los
mismos, as como la documentacin 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 informtico de la Entidad cuentan con el Sistema Operativo Windows XP que ya no cuenta con
soporte del fabricante.
De la revisin al parque informtico de la Entidad, se encontr que existen 150 equipos informticos 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 an cuentan con dicho sistema operativo se encuentran vulnerables, ya que el fabricante ya no emite parches
de seguridad. La informacin 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 situacin expone a los equipos con dicho sistema operativo ya que no reciben actualizaciones de software ni parches de seguri-
dad, lo que convierte a dichos equipos en altamente vulnerables a las amenazas informticas tales como virus, gusanos, troyanos,
spyware, rootkits, etc, lo que a su vez, podra originar falta de disponibilidad en dichos equipos y comprometer a los dems equipos
conectados a la red.
Se recomienda que la Gerencia General disponga que la Gerencia de Tecnologa de Informacin y Comunicaciones evale y planifi-
que la renovacin tecnolgica de los equipos vulnerables o en su defecto se programe la migracin del sistema operativo Windows XP
instalado en los equipos de la Entidad a una versin ms reciente y que cuente con el soporte de parches y actualizaciones vigentes.
Se puede apreciar que el Auditor ha escrito el ttulo de la observacin, de tal manera que al leerla no nos quede
duda de que se trata la observacin. Como dijimos, el titulo debe ser lo ms preciso posible.
Luego del ttulo, el primer prrafo pertenece a la descripcin. Aqu el Auditor ha descrito la situacin o debilidad
encontrada que origina riesgo. En este caso encontr 150 equipos con Sistema Operativo cuyo fabricante (Micro-
soft) ya no enva parches ya que esta fuera de soporte.
El segundo prrafo se refiere al riesgo que el auditor identific. En este prrafo se describe claramente el riesgo
identificado, en este caso, los equipos estn expuestos a ataques informticos.
El ltimo prrafo del hallazgo se refiere a la recomendacin del auditor. El auditor recomienda la implementacin
de algn tipo de control para minimizar el riesgo encontrado. En este caso el Auditor recomienda la renovacin de
los equipos o la migracin a un Sistema Operativo ms seguro.
Veamos un segundo ejemplo.
Ejemplo 2:
Se identificaron cuentas de personal cesado que permanecen activas en el Sistema ERP SAP.
Durante la revisin a la vigencia de los accesos en el sistema de informacin SAP, identificamos cuentas de usuarios de personal
cesado, segn el reporte de cese emitido por Recursos Humanos, que permanecen activos en el sistema SAP, tales como:
UNIDAD
CDIGO EMPLEADO NOMBRES FECHA DE CESE MDULO SAP
ORGANIZACIONAL
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 General Ledger
Esta situacin incrementa el riesgo de accesos no autorizados al sistema, mediante el uso de cuentas de personal cesado que se man-
tienen activas, despus 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 desactivacin de dichas cuentas de usuarios en el Sistema SAP y realizar un moni-
toreo continuo sobre las cuentas de usuario de personal cesado.
En este segundo ejemplo, se puede apreciar que el Auditor nuevamente ha escrito el ttulo de la observacin, de
tal manera que al leerla no nos quede duda de que se trata la observacin. El titulo debe ser lo ms preciso posible.
Luego del ttulo, el primer prrafo pertenece a la descripcin. Aqu el auditor debe escribir la situacin encontrada.
El segundo prrafo se refiere al riesgo que el auditor identifico. En este prrafo se describe el riesgo identificado.
El ltimo prrafo del hallazgo se refiere a la recomendacin del auditor. El auditor recomienda la implementacin
de algn 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 revisin al Centro de Datos de la Entidad, se encontr que dicho Centro cuenta con deficiencias a nivel de seguridad ambien-
tal. 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 bitcora de ingreso.

Esta situacin podra originar el riesgo de malfuncionamiento de los Servidores y de los equipos de comunicacin ubicados en dicho
Centro, lo que podra originar a mediano plazo, interrupciones de los servicios y sistemas gestionados por la Oficina de Sistemas e
Informtica.
Se recomienda que la Gerencia General, disponga la evaluacin de las acciones necesarias para que la Oficina de Sistemas e Infor-
mtica priorice las acciones necesarias para subsanar las debilidades encontradas.
En todos los casos se aprecia que el formato de la observacin de auditoria se mantiene.
2 FORMULACIN DE LAS RECOMENDACIONES
Es importante que el Auditor escriba racionalmente las recomendaciones de cada uno de sus hallazgos. Las recomen-
daciones deben ser escritas en forma clara y no deben escribirse recomendaciones que puedan significar un desembol-
so significativo de dinero por parte del Auditado.
Veamos los siguientes ejemplos de recomendaciones:
Tabla 1
Formulaci{on de recomendaciones
FORMA INCORRECTA FORMA CORRECTA
Comprar un nuevo software Evaluar la factibilidad de adquirir un nuevo software
Reemplazar un Sistema de Informacin Disponer que la Gerencia General en conjunto con la Ge-
rencia de TI evalen la posibilidad de cambiar el Sistema de
Informacin
Cambiar al Gerente de TI Disponer que la Gerencia de RRHH evale la conveniencia

de reemplazar al Gerente de TI
Cambiar el 50% de las computadoras actuales del parque Evaluar la factibilidad de cambiar el 50% de las computado-
informtico ras actuales del parque informtico
3 FORMULACIN DEL INFORME DE AUDITORIA
3.1 El informe de Auditoria
El informe de Auditoria es el entregable final del trabajo de un Auditor. Tpicamente es escrito en MS-Word y contiene
los siguientes componentes:
Antecedentes
Objetivo
Alcance
Relacin de Observaciones / Hallazgos
Limitaciones a la auditoria
Otros Aspectos de Importancia
Conclusiones
3.2 Pasos para la presentacin 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:
E
l informe se enviara al auditado (normalmente el Gerente de Sistemas) para darle la posibilidad de que responda
a los hallazgos encontrados.
E
l 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 ocasio-
nes el Auditado podra oponerse a un determinado hallazgo, debido a que el Auditor se equivoc en el hallazgo o
debido a que la recomendacin es imposible de ejecutar, ya que podra ser no beneficioso para los intereses de la
compaa.
El Auditor se entrevista con el Auditado para discutir las respuestas del Auditado y resolver cualquier inquietud.
E
l Auditor coordinar una entrevista final al ms alto nivel de la Compaa (normalmente con el Gerente General)
para la comunicacin de los resultados de la auditora
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
Pg.
INFORME DEL EXAMEN ESPECIAL AL DEPARTAMENTO DE INFORMATICA
I. Sntesis gerencial 2
II. INTRODUCCIN 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
Sntesis Gerencial
El presente Examen Especial comprende la evaluacin de los Sistemas Informticos con los que cuenta la Compaa, los mecanismos
de seguridad informticos, los mecanismos de contingencias y recuperacin de desastres y la implantacin del control interno en el
departamento de Informtica dentro del perodo del 01.01.16 al 31.03.16.
Las principales conclusiones del trabajo realizado son las siguientes:

1. El departamento de Informtica realiza bsicamente labores de soporte a los usuarios, no habiendo actividades de
desarrollo de Sistemas.
2. El departamento de Informtica no cuenta con normatividad esencial para su funcionamiento. Especficamente
no cuenta con un Plan de Contingencias adecuado y adems no cuenta con un Plan Estratgico de Sistemas.
3. Algunos procedimientos del rea no se encuentran normados.
4. La ejecucin 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 accin de control se identificaron seis (6) hallazgos, y diversas deficiencias de control interno entre las que des-
tacan las relacionadas con deficiencias en la seguridad fsica, ejecucin de backups de software base y la documentacin relacionada,
por lo que con la finalidad de promover la superacin de las causas que las motivaron, se proponen las siguientes recomendaciones
tanto al Comit Directivo, Gerencia A, Gerencia B y Gerencia C.
I. INTRODUCCIN
A continuacin se presenta informacin general sobre el presente Examen al Departamento de Informtica de la Compaa.
1. Origen del examen
El Examen Especial al Departamento de Informtica, por el perodo comprendido entre el 01.01.16 y 30.03.16, se realiza en cumpli-
miento del Plan Anual de Control para el 2016 del rgano de Control Institucional de la Compaa.
Es importante destacar que las reas relacionadas con el Departamento de Informtica no han sido materia de acciones de control
posterior en los ltimos dos aos.
2. Naturaleza y objetivos del examen
Esta accin de control consiste en un Examen Especial y tiene como objetivos generales y especficos los siguientes:
Objetivo General
Evaluar el adecuado uso de las Tecnologas de Informacin incidiendo en software, hardware, comunicaciones, seguridad y control de
calidad, as como evaluar la adecuada organizacin, planificacin y administracin del rea de Informtica.
Objetivos especficos
a) Evaluar el Sistema Informtico con el que cuenta la Compaa, determinando si los aplicativos actuales satisfacen las necesidades
de la Compaa, la interrelacin de sus aplicativos, su grado de funcionamiento y los controles implementados.
b) Evaluar los mecanismos de Seguridad Informticos implantados en la Compaa para asegurar la integridad de la informacin
y de los recursos informticos de la Compaa.
c) Evaluar los mecanismos de Contingencias y recuperacin de desastres de la Oficina de Informtica 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 Informtica.
3. Alcance del examen
El alcance del Examen Especial al Departamento de Informtica est referido a todas las acciones de control posterior y dems activida-
des desarrolladas para lograr un adecuado y oportuno funcionamiento de los sistemas de la Compaa, 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 sern la administracin eficiente de los recursos
destinados al desarrollo de actividades del Departamento de Informtica; el nivel de seguridad de los recursos informticos, el nivel de
cumplimiento de objetivos del rea; aplicacin de las normas legales e internas que regulan la labor de informtica y la realizacin de
las labores del rea.
El presente examen especial se desarroll en la ciudad de Lima, en las instalaciones del local institucional de la Compaa. El plazo
inicialmente estimado para el desarrollo de este examen se vio ampliado debido a la solicitud de ampliacin de plazo presentada por el
Gerente A y la Directora de Informtica para la presentacin de sus comentarios y aclaraciones en relacin con los hallazgos comuni-
cados; 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 accin de control posterior, relacionados con los objetivos de sta y con las situaciones evidenciadas en la Compa-
a:
a) Durante la revisin del software con el que cuenta la Compaa, se pudo apreciar que la Compaa 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 informacin de control que sirva como instrumento para la toma de decisiones relacionadas al Presu-
puesto. Las actividades de formulacin y control de los montos ejecutados y pendientes son realizadas de forma manual.
II. HALLAZGOS
Durante el desarrollo de esta accin de control se determinaron las siguientes observaciones, las cuales incluyen los comentarios y
aclaraciones de los funcionarios de la Compaa.
1. ALGUNAS TABLAS DEL SISTEMA CORE1 NO CUENTAN CON LLAVE PRIMARIA
De la revisin a la estructura de la Base de Datos del Sistema CORE1 (Sistema de Informacin Gerencial), se evidenci que de un total
de 90 tablas, 18 tablas no contenan llaves primarias (es la que permite identificar cada registro individual de los dems 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 Informtica no existen procedimientos de monitoreo que permitan asegurar la integridad
referencial de la Base de Datos del Sistema CORE1.
Esta situacin podra conllevar a que los registros de informacin presenten duplicidad en informacin, incrementa el riesgo de que la
Base de Datos del Sistema CORE1 contenga informacin no validada o informacin sujeta a errores.
Se recomienda que la Direccin de Informtica priorice la implementacin de la integridad referencial en la Base de Datos del Sistema
CORE1.
2. EL PLAN DE CONTINGENCIAS NO CUENTA CON LOS PROCEDIMIENTOS DE RECUPERACIN DE DESAS-

TRES ANTE LA OCURRENCIA DE ALGUNA EVENTUALIDAD
El Plan de Contingencias formulado por el Departamento de Informtica, presenta algunas deficiencias, las cuales se detallan a
continuacin:
a) El Plan de Contingencias no cuenta con los procedimientos de recuperacin a seguir ante la ocurrencia de una eventualidad.
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 recuperacin de las aplicaciones CORE2, CORE3 y SISFACT.
La falta de procedimientos en el Plan de Contingencias origina que la Compaa no est preparada para afrontar la ocurrencia de una
situacin de emergencia o desastre, la cual podra devenir en cortes y/o interrupciones prolongadas del servicio informtico ofrecido
por el Departamento de Informtica.
Se recomienda que la Gerencia General disponga que la Directora de la Oficina de Informtica evale la priorizacin de la actualiza-
cin del Plan de Contingencias, definiendo las siguientes actividades:
a) Definir los procedimientos de recuperacin a seguir ante la ocurrencia de una eventualidad.
b) Contemplar diferentes escenarios de desastre por cada riesgo identificado.
c) Definir un calendario para la realizacin de pruebas a los procedimientos del Plan.
3. LA COMPAIA NO CUENTA CON UN PLAN DE SISTEMAS DE INFORMACIN
De la revisin y evaluacin de la documentacin de Planeamiento se determin que el Departamento de Informtica no cuenta un Plan
de Sistemas, el cual es una herramienta de gestin que establece las necesidades de informacin de la Compaa, teniendo el propsito
de prever el desarrollo de los recursos fsicos y lgicos con un horizonte temporal determinado, de manera que contribuya efectivamente
con los objetivos de la Compaa.
El Departamento de Informtica en la actualidad cuenta con un Plan de Actividades que muestra las actividades realizadas en dicho
periodo.
Esta situacin podra conllevar que las actividades del rea Informtica no se encuentren alineadas con los objetivos institucionales y
estratgicos de la Compaa as como a los requerimientos de la empresa; Adems el no contar con un Plan de Sistemas a largo plazo,
origina que la empresa no se comprometa a destinar recursos suficientes para el cumplimiento de los mismos.
Se recomienda que la Direccin de la Oficina de Informtica evale la priorizacin de elaborar el Plan de Sistemas de Informacin, el
cual debe estar alineado con los Objetivos Institucionales trazados en el Plan Estratgico de la Compaa. Especficamente el Plan de
Sistemas debe contener:
Diagnstico de la situacin informtica actual con la finalidad de saber las capacidades actuales de la Compaa;
Elaboracin de objetivos y estrategias del sistema de informacin que sirva de base para apoyar la misin y los objetivos de la
Compaa;
Desarrollo del modelamiento de datos para determinar qu informacin es necesaria para la Compaa;
Generacin, ordenamiento y priorizacin (por nivel de importancia e inversin) sistemtica de los proyectos informticos;
Programacin de los tiempos requeridos para la puesta en marcha de los proyectos designados, estimando el perodo de vida de cada
proyecto.
4. LOS RESPALDOS DE INFORMACIN (BACKUPS) QUE REALIZA EL DEPARTAMENTO DE INFORMTICA

NO SE ALMACENAN EN UN LUGAR SEGURO
Se comprob que los backups son elaborados de forma semanal, guardndose en un disco de uno de los Servidores del Departamento
de Informtica. Dichos backups de manera quincenal son almacenados en cinta. Las cintas son luego, guardadas en la Gerencia de
Administracin, en un estante que no brinda ninguna seguridad ni proteccin para el buen estado de las cintas.
Esta situacin pone en riesgo la continuidad del servicio ofrecido por el Departamento de Informtica, toda vez que ante la ocurren-
cia de un desastre, existe el riesgo de no contar con los recursos necesarios para restaurar el servicio ofrecido por el Departamento de
Informtica.
Se recomienda que la Directora de la Oficina Informtica 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 Administracin. Asimismo definir un
procedimiento que permita a la Directora de Informtica contar con el acceso a dicha caja fuerte solo en los casos de la ocurrencia de
alguna eventualidad.
5. EL DEPARTAMENTO DE INFORMTICA NO REALIZA PERIDICAMENTE UN MONITOREO DE LAS ACTI-

VIDADES DE USO Y ACCESO A LOS RECURSOS INFORMTICOS
De la revisin a los procedimientos de monitoreo de la seguridad lgica, se evidenci que el Departamento de Informtica no realiza
ningn monitoreo peridico de actividades de uso y acceso a los recursos informticos de la Compaa, con el fin de determinar el uso
correcto de dichos recursos, as como detectar intentos de violacin y/o acceso no autorizados a los recursos informticos de la Compa-
a.
As tenemos que no se encontr evidencia de la realizacin de un monitoreo peridico a las actividades de uso de Internet, trfico de
correo, trfico sospechoso por la red, actualizacin de cliente antivirus, cambio de passwords, ni de intentos de acceso o acceso no au-
torizado a los recursos informticos administrados por el Departamento de Informtica.
Esta situacin origina que no se detecten los intentos de acceso o los accesos no autorizados a los recursos informticos de la Compaa
e incluso podra devenir en fuga de informacin sensitiva fuera de la Compaa.
Se recomienda que la Directora de la Oficina de Informtica elabore un calendario peridico que permita definir fechas de realizacin
del monitoreo de las actividades de uso y acceso a los recursos informticos de la Compaa. Asimismo como resultado de dicho moni-
toreo se debe informar a la Gerencia de las actividades encontradas en dicho monitoreo, con el 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 COMPAIA
Durante la inspeccin realizada para verificar los controles de acceso lgico implementados en la Compaa, se pudo verificar que la
Directora de Informtica ha realizado en un par de ocasiones el acceso remoto a los recursos de la Compaa. Este acceso remoto se
realiza a travs de Internet. A la fecha de nuestra revisin, este acceso no se encontraba normado.
Esta situacin podra ocasionar un acceso no autorizado de informacin, toda vez que al tratarse de un acceso remoto, no se necesita
estar dentro de las instalaciones de la Compaa.
Se recomienda que la Direccin de la Oficina de Informtica defina un procedimiento que regule el acceso a los recursos informticas
va 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 Informtica no cuenta con un Plan de Contingencias actualizado y completo, debido a que no
se ha priorizado la definicin de los procedimientos de recuperacin del Plan de Contingencias.
2. El departamento de Informtica no cuenta con un Plan de Sistemas de Informacin, debido a que el Departamen-
to de Informtica basa la ejecucin de sus actividades en un Plan de Actividades anual, el cual contiene la descrip-
cin y cronograma de ejecucin de dichas actividades.
3. Los respaldos de informacin (backups) no son almacenados en un lugar seguro, debido a que no se han tomado
todas las medidas necesarias para garantizar la disponibilidad, proteccin y buen estado de las cintas, necesarias
ante la ocurrencia de alguna contingencia.
4. No se ejecuta un monitoreo peridico de las actividades de uso y acceso a los recursos informticos de la Compa-
ia, debido a que no se ha previsto la realizacin de un cronograma de monitoreo de uso y acceso a los recursos ni
al seguimiento del cumplimiento de normas y polticas del Departamento.
5. No existe un procedimiento formal que regule el acceso remoto a los servidores de la Compaia, debido a que no
se ha previsto la formulacin de un procedimiento que regule el acceso remoto a los recursos informticos de la
Compaa.
En conclusin, se advierte que los sistemas de informacin y la infraestructura tecnolgica que administra la Oficina de Informtica
cuentan con controles deficientes que necesitan ser subsanados para proteger adecuadamente a la Compaa.
TEMA N. 4: MARCOS DE REFERENCIA DE AUDITORIA DE SISTEMAS
INTRODUCCIN
En esta seccin 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 funcin de supervisin de dichas entidades en funcin 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 tecnologas de informacin. En ese contexto, la SBS p-
blica normas que son de carcter obligatorio para las entidades mencionadas. Entre las normas ms 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 gestin de la continuidad del negocio
como un proceso, efectuado por el Directorio, la Gerencia y el personal, que implementa respuestas efectivas para que
la operatividad del negocio de la empresa contine de una manera razonable, con el fin de salvaguardar los intereses
de sus principales grupos de inters, ante la ocurrencia de eventos que pueden crear una interrupcin o inestabilidad
en las operaciones de la empresa.
Las empresas deben realizar una gestin de la continuidad del negocio adecuada a su tamao y a la complejidad de
sus operaciones y servicios.
Si te interesa conocer ms 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 Sis-
tema de Gestin de Seguridad de la Informacin (SGSI) tomando como referencia las normas internacionales ISO
17799 e ISO 27001.
Si te interesa conocer ms 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 Contralora General de la Republica (CGR)
La CGR es la mxima autoridad del Sistema Nacional de Control. La CGR supervisa, vigila y verifica la correcta apli-
cacin de las polticas pblicas y el uso de los recursos y bienes del Estado Peruano. Para realizar con eficiencia sus
funciones, cuenta con autonoma administrativa, funcional, econmica y financiera
En ese contexto, la Contralora emite normas que son de cumplimiento obligatorio para las entidades del Sector Pu-
blico.
La Norma que gobierna las actividades de Auditoria son las Normas Generales de Control Gubernamental. Puedes en-
contrar 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 acpite 2.2 Estndares de ISACA del tema 1.
A nivel de Auditoria de Sistemas, las Normas que debemos tomar en cuenta son las Normas de Control Interno que
estn vigentes desde el 2006. En este documento en la seccin III tenemos 3 clusulas que se deben tener en cuenta:
1.3.1 Clausula 2 Norma General para el componente de evaluacin de riesgos:
El componente evaluacin de riesgos abarca el proceso de identificacin y anlisis de los riesgos a los que est
expuesta la entidad para el logro de sus objetivos y la elaboracin de una respuesta apropiada a los mismos. La
evaluacin de riesgos es parte del proceso de administracin de riesgos, e incluye: planeamiento, identificacin,
valoracin o anlisis, manejo o respuesta y el monitoreo de los riesgos de la entidad.
1.3.2 Clausula 3.10 Controles para las tecnologas de Informacin y Comunicaciones:
La informacin de la entidad es provista mediante el uso de Tecnologas de la Informacin y Comunicacio-

nes (TIC). Las TIC abarcan datos, sistemas de informacin, tecnologa asociada, instalaciones y personal. Las
actividades de control de las TIC incluyen controles que garantizan el procesamiento de la informacin para
el cumplimiento misional y de los objetivos de la entidad, debiendo estar diseados para prevenir, detectar y
corregir errores e irregularidades mientras la informacin fluye a travs de los sistemas.
1.3.3 Clausula 4.4 Sistemas de Informacin:
Los sistemas de informacin diseados 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 caractersticas, necesidades y naturaleza de la entidad. De este modo, el sistema de
informacin provee la informacin como insumo para la toma de decisiones, facilitando y garantizando la trans-
parencia en la rendicin 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 ms de la Contralora General de la Republica, puedes dirigirte a:
http://doc.contraloria.gob.pe/documentos/PREGUNTAS_FRECUENTES_2015.pdf
1.4 Ley 29733 de Proteccin de Datos Personales.
Esta ley obliga a las compaas a tomar medidas para preservar los datos personales que las compaas 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 define a los datos personales a toda aquella informacin sobre una persona natural que la identifica o la hace
identificable a travs de medios que pueden ser razonablemente utilizados. As por ejemplo tenemos Nombres, Apelli-
dos, DNI, telfonos, direccin domicilio, correo electrnico, fecha de nacimiento, sexo, Nro. Identificacin tributaria,
Razn 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 biomtricos que por s mismos pueden identificar al titular; datos
referidos al origen racial y tnico; ingresos econmicos, opiniones o convicciones polticas, religiosas, filosficas o
morales; afiliacin sindical; e informacin relacionada a la salud o a la vida sexual. Un claro ejemplo de datos sensibles
son los Sueldos de los trabajadores en una compaa.
Las compaas estn 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 compaa tiene al menos
4 Bancos de Datos que contienen datos personales:
Clientes
Trabajadores
Proveedores (personas naturales)
Visitantes
Uno de los temas ms 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 compaa que tiene sus datos personales. Los derechos
son:
Acceso. Una persona tiene derecho a saber que datos tiene una compaa de ella.
Rectificacin. Una persona tiene el derecho a rectificar cualquier dato errneo que una compaa tenga de ella.
C
ancelacin. La persona tiene derecho a que la compaa borre la informacin de ella. Esto, siempre y cuando,
no haya una relacin existente. Por ejemplo un trabajador no puede pedir a su compaa que borre toda la infor-
macin de ella.
O
posicin. Un apersona puede oponerse a que una compaa use sus datos personales para un uso particular. Por
ejemplo, una persona puede oponerse a que le enven publicidad.
El cumplimiento de la Ley est a cargo de la Autoridad Nacional de Proteccin de datos personales (ANPDP) que
depende del Ministerio de Justicia. La ANPDP emiti la Directiva de Seguridad que define los controles tecnolgicos,
legales y administrativos que las compaas deben seguir para proteger los datos personales.
Entre los controles tecnolgicos ms importantes esta la implementacin de un Sistema de Gestin de Seguridad de la
Informacin, controles criptogrficos, controles de acceso, respaldo, entre otros.
Puedes ver un video de la Autoridad nacional de Proteccin de datos personales en: https://www.youtube.com/wat-
ch?v=1c4YMd_YaRs
2 REGULACIONES EXTERNAS
2.1 COSO ERM.
El Committee of Sponsoring Organizations of the Treadway Enterprise Risk Management, ms conocido como
COSO ERM es una marco de referencia (framework) de riesgos empresariales. Actualmente est en la versin 3. El
marco es formulado por la Organizacin COSO que es un comit voluntario de 5 instituciones y que est orientado
a gestionar tres temas fundamentales: la gestin del riesgo empresarial (ERM), el control interno, y la disuasin del
fraude en las compaas.
La idea del COSO es promover la gestin de riesgos en todos los niveles de la compaa y establece directrices para la
toma de decisiones de los lderes de las compaas para el control de los riesgos y la asignacin de responsabilidades.
En su ms reciente versin, el marco define 5 componentes de control:
Entorno de control
Evaluacin de riesgos
Actividades de Control
Informacin y Comunicacin
Actividades de supervisin
Todas las compaas que gestionan el riesgo (no solo el riesgo de TI) utilizan este framework como gua para sus ac-
tividades. Si deseas saber ms sobre el COSO ERM, puedes acceder a un resumen ejecutivo en la siguiente direccin:
http://doc.contraloria.gob.pe/Control-Interno/Normativa_Asociada/coso_2013-resumen-ejecutivo.pdf
2.2 CobiT 5.
Es el marco de referencia (framework) ms importante de TI para el gobierno y la gestin de las TI en una compaa.
No existe documento ms importante en TI que el CobiT.
Segn el documento Cobit5 Introduccin:COBIT 5 ayuda a las Compaas a crear un valor ptimo a partir de la TI,
al mantener un equilibrio entre la realizacin de beneficios y la optimizacin de los niveles de riesgo y utilizacin de
los recursos.
COBIT 5 permite que las tecnologas de la informacin y relacionadas se gobiernen y administren de una manera holstica
a nivel de toda la Organizacin, incluyendo el alcance completo de todas las reas de responsabilidad funcionales y de
negocios, considerando los intereses relacionados con la TI de las partes interesadas internas y externas.
Para ello, Cobit5 define 5 principios, los cuales se presentan en el grfico 3:
Satisfacer las
necesidades
de los
stackeholders.
Separar Cubrir
Gobierno de totalmente la
Gestin. empresa.
Principios
Aplicar un
Habilitar
nico marco
un enfoque
de referencia
holstico.
integrado.
Figura 3. Los 5 principios de Cobit5.

Fuente: ISACA.
Asimismo, Cobit5 define 7 habilitadores. Este trmino algo extrao no es ms que los factores que, individual y colec-
tivamente, influyen sobre si algo funcionarn en este caso, el Gobierno y la Gestin de la TI.
Grfico 3 - Los 5 principios de Cobit5.
Fuente: ISACA. Auditora de sistemas
Asimismo, Cobit5 define 7 habilitadores. Este trmino algo extrao no es
ms que los factores que, individual y colectivamente, influyen sobre si al-
go funcionarn en este caso, el Gobierno y la Gestin de la TI.
Los 7 habilitadores que define CobiT se muestran en la siguiente figura.
Los 7 habilitadores que define CobiT se muestran en la siguiente figura.
Grfico 4 Habilitadores de Cobit 5.

Figura 4. Habilitadores de Cobit 5.
Fuente ISACA.
Fuente ISACA.
COBIT 5 une los cinco principios que permiten a la Organizacin construir un marco efectivo de Gobierno y Gestin
COBIT 5 une los cinco principios que permiten a la Organizacin construir
basado en los siete habilitadores, para que juntos,
un marco efectivo optimicen
de Gobierno la inversin
y Gestin basadoen en
tecnologa
los sietede informacin as como su uso
habilitadores,
en beneficio de las partespara
interesadas.
que juntos, optimicen la inversin en tecnologa de informacin as
Asimismo,como su usode
uno en los
beneficio
temas de transcendentales
las partes interesadas.
del CobiT es que separa el
Asimismo, uno de Gobierno
los temas transcendentales
de TI de la Gestin deesTI.
del CobiT queDurante
separa elmuchos
Gobiernoaosde TI se
de la
usGestin de TI. Durante
indistin-
muchos aos se us indistintamente ambos conceptos, pero ahora se tienen claramente
tamente ambos conceptos, pero ahora se tienen claramente diferenciados. diferenciados.
Gobierno de TI es la definicin de los objetivos de TI (en funcin de los ob-
Gobierno de TI es jetivos
la definicin de los objetivos de TI (en funcin de los objetivos de Negocio). 35
de Negocio).
Gestin de TI es el logro de los objetivos trazados. Por tanto un gestor es
Gestin de TI es el logro de los objetivos trazados. Por tanto un gestor es aquel que logra que las cosas se hagan. Qu
aquel que logra que las cosas se hagan. Qu cosas? Las definidas en el
cosas? Las definidas en el Gobierno de TI.
Gobierno de TI.
La figura 5 presenta la separacin de los dominios de CobiT separando el
La figura 5 presenta la separacin de los dominios de CobiT separando el Gobierno de la Gestin
Gobierno de la Gestin
Figura 5. Gobierno y Gestin de TI.

Grfico 5 - Gobierno y Gestin de TI.
Fuente: ISACA
Fuente: ISACA
En funcin a ello, CobiT define un conjunto de 37 procesos, tal como se

presentan a continuacin:
Grfico 5 - Gobierno y Gestin de TI.
Fuente: ISACA 38
En funcin a ello, CobiT define un conjunto de 37 procesos, tal como se

presentan a continuacin:
Fuente: ISACA
Figura 6. Mapa de Procesos de CobiT.
En funcin a ello, CobiT define un conjunto de 37 procesos, tal como se presentan a continuacin:
Figura 6 Mapa de Procesos de CobiT. Fuente: ISACA

UNIDAD I: Introduccin a la Auditoria de Sistemas
36
Para los Auditores, los temas de Gobierno de TI son de mucha utilidad ya que el Auditor puede evaluar la definicin
de objetivos de TI en funcin de los Objetivos de Negocio.
Por el lado de Gestin de TI, el Auditor puede evaluar los procesos que en su conjunto persiguen el logro de los ob-
jetivos de TI.
Si deseas saber ms de CobiT5, te recomiendo el siguiente link: http://www.isaca.org/COBIT/Documents/CO-

BIT5-Introduction-Spanish.ppt
2.3 Familia ISO 27000.
La Familia ISO 27000 es un conjunto de normas internacionales relacionadas a la seguridad de la Informacin. Esta
familia tiene cerca de 40 normas. En este curso nos centraremos en las 2 normas ms 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 numeracin. 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 Captulos (en la norma se
llaman Dominios), 35 Objetivos de Control y 114 Controles que una compaa debe implementar para proteger
su informacin.
Los 14 dominios de la Norma son:
Poltica de Seguridad
Organizacin de la Seguridad de la Informacin
Seguridad relacionada a los RRHH
Gestin de Activos
Control de Accesos
Criptografa
Seguridad fsica y ambiental
Seguridad en las operaciones
Seguridad en las comunicaciones
Adquisicin, desarrollo y mantenimiento de sistemas
Relacin con los proveedores
Gestin de incidentes de seguridad de la informacin
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 numeracin confunden. En el Per existe la Norma
Tcnica Peruana NTP ISO/IEC 17799, que es el equivalente a la ISO 27002:2013. Que no te sorprenda la numeracin!
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 implementacin de un Sistema de Gestin de Seguridad de la Informacin, ms comn-

mente conocido como SGSI. La ISO 27001 define un conjunto de requisitos para establecer, implementar, man-
tener y mejorar un SGSI dentro de una Compaa. Asimismo define requisitos para la evaluacin y tratamiento
de riesgos de seguridad de la informacin.
En el Per la Norma Tcnica Peruana Vigente es la NTP ISO/IEC
27001:2014.
El Sistema de Gestin de la Seguridad de la Informacin (SGSI) en las compaas ayuda a establecer polticas,
A la fecha existen ms de 10 compaas en el Per que han obtenido
procedimientos y controles en relacin a los objetivos de negocio.
el certificado ISO 27001. Entre las que se pueden mencionar a: Aten-
En el Per lato, GMD,
Norma Hermes
Tcnica transportes
Peruana Vigente esblindados, Hochschild
la NTP ISO/IEC Minning PLC, In-
27001:2014.
decopi, Oficina de Normalizacin Previsional ONP, PMC Latam, Secure
Soft, ms
A la fecha existen Telefnica del Per,enTelefnica
de 10 compaas el Per queEmpresas y Telefnica
han obtenido Gestin
el certificado de Entre las que se
ISO 27001.
Servicios Compartidos Per SAC
pueden mencionar a: Atento, GMD, Hermes transportes blindados, Hochschild Minning PLC, Indecopi, Ofi-
cina de Normalizacin Previsional ONP, PMC Latam, Secure Soft, Telefnica del Per, Telefnica Empresas y
Cualquier
Telefnica Gestin compaa
de Servicios puede tomar
Compartidos la decisin de certificarse. Existen
Per SAC
mecanismos de implementacin que requieren el apoyo de la Alta Ge-
rencia. Un
Cualquier compaa ejemplo
puede tomar lade la Certificacin
decisin la Existen
de certificarse. puedesmecanismos
observar deen implementacin
el si- que re-
guiente
quieren el apoyo de lagrfico:
Alta Gerencia. Un ejemplo de la Certificacin la puedes observar en el siguiente grfico:
La compaa donde trabajas
Figura 7 Ejemplo de la certificacin ISO 27001:2013

Figura 7. Ejemplo de la certificacin ISO 27001:2013
La Auditoria de Sistemas a una compaa que cuenta con el certificado ISO
La Auditoria
27001 deesSistemas a una compaa
una Auditoria que cuenta
especializada quecon el certificado
requiere que elISO 27001 conozca
Auditor es una Auditoria
y especializa-
da que requiere que el Auditor conozca y evale sobre la correcta implementacin del SGSI,
evale sobre la correcta implementacin del SGSI,
2.4 Sarbanes-Oxley (SOX).

La Ley Sarbanex-Oxley es una ley federal de los Estados Unidos cuyo obje-
tivo es monitorear a las compaas que cotizan en la Bolsa de valores, a
travs de controles contables para que el valor de las acciones no sean
2.4 Sarbanes-Oxley (SOX).
La Ley Sarbanex-Oxley es una ley federal de los Estados Unidos cuyo objetivo es monitorear a las compaas que coti-
zan en la Bolsa de valores, a travs de controles contables para que el valor de las acciones no sean manipuladas en
deterioro de los accionistas. Esta ley fue aprobada en el ao 2002 despus de la quiebra en el 2001 de la gigantesca
compaa energtica Enron que manipulo escandalosamente sus cifras contables para que la cotizacin de sus accio-
nes 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 compaas Tyco International, WorldCom y Peregrine Systems
que aumentaron la desconfianza en las compaas que cotizaban en bolsa y en las compaas de Auditoria que realiza-
ban la Auditoria Financiera. De hecho, una de las grandes compaas de Auditoria quebr tambin. La compaa se
llamaba Arthur Andersen, quienes se hicieron de la vista gorda con las prcticas contables de Enron.
Los puntos ms importantes que introdujo la Ley Sarbanes-Oxley fueron de ndole contable, que afectan a la TI ya que
los sistemas contables corren en ambientes tecnolgicos.
S
e cre la Public Company Accounting Oversight Board (PCAOB por sus siglas en ingls), que es una Entidad que
debe supervisar las auditoras de las compaas que cotizan en bolsa.
E
s obligatorio que las compaas 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 compaas constaten esta
transparencia y veracidad.
Los estados financieros deben estar certificados por parte del comit ejecutivo y financiero de la compaa.
Las compaas deben trabajar con empresas auditoras completamente independientes.
S
e exige que las compaas que cotizan en bolsa tengan un comit de auditora, con personal completamente in-
dependiente, que supervisen la relacin entre la compaa y sus auditores externos
Prohibicin de prstamos personales de dinero a los altos ejecutivos de la compaa.
Transparencia de la informacin de acciones y opciones, de la compaa en cuestin, que puedan tener los directi-
vos, ejecutivos y empleados claves de la compaa y consorcios, en el caso de que posean ms de un 10% de accio-
nes de la compaa. Asimismo estos datos deben estar reflejados en los informes de las compaas.
E
ndurecimiento de la responsabilidad civil y penal por incumplimiento de la Ley Sox. La ley amplia las penas de
prisin y las multas a los altos ejecutivos que incumplen y/o permiten el incumplimiento de las exigencias finan-
cieras.
Dado que en el Per operan filiales de compaas estadounidenses que cotizan en bolsa, es comn 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
Amrica. Lo puedes encontrar en: https://www.youtube.com/watch?v=mnyzZ7r1zdA
2.5 Basilea III.
Son un conjunto de normas de regulacin bancaria para las instituciones bancarias, que se encuentran vigentes des-
de el 2010, orientadas a proporcionar las mecanismos eficientes para mejorar la capacidad de respuesta del sistema
bancario ante perturbaciones econmicas 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 insti-
tuciones financieras debido a la crisis hipotecaria que golpe a Estados Unidos y se esparci por todo el mundo en el
ao 2008.
Las Normas son emitidas por el Comit de Supervisin 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.
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 me-
jorar la seguridad de los datos del titular de la tarjeta y facilitar la adopcin de medidas de seguridad uniformes a nivel
mundial. Las PCI DSS proporcionan una referencia de requisitos tcnicos 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 tambin to-
das las dems entidades que almacenan, procesan o transmiten CHD (datos del titular de la tarjeta) o SAD (datos de
autenticacin 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 supervisin y evaluacin peridica de las redes, y polticas de seguridad de la infor-
macin para todo el personal.
Puedes visitar el sitio web de PCI en: https://www.pcisecuritystandards.org/
Asimismo,
Diagrama
la norma
Objetivos Inicio
est disponible en: https://es.pcisecuritystandards.org/minisite/en/pci-dss-v3-0.php

de contenidos
LECTURA SELECCIONADA N. 1
seleccionadas
Leer artculo: Auditoria de sistemas.
DSousa, C. (2008). Auditoria de sistemas [Sitio Web]. Disponible en: http://www.gerencie.com/auditoria-de-sistemas.htnl,

ACTIVIDAD N. 1
de contenidos
Participa en el Foro de discusin sobre Los riesgos originados por el uso de las Tecnologas de Informacin en las
organizaciones.
seleccionadas INSTRUCCIONES
Lee y analiza un caso sobre riesgos originados por el uso de las TICs.
Diagrama
Expresa tus opiniones
Objetivos Inicio en relacin al caso en el foro de discusin que se encuentra en el aula virtual.

de contenidos
CONTROL DE LECTURA N 1
seleccionadas
Esta actividad puede consultarla en su Aula virtual.

Diagrama
UNIDAD I:Inicio
Objetivos
Introduccin a la Auditoria de Sistemas MANUAL AUTOFORMATIVO 43

de contenidos
GLOSARIO DE LA UNIDAD I
seleccionadas
Amenaza: Es cualquier cosa que tenga el potencial de hacer dao.

Recordatorio
Auditoria
Anotaciones
de
Chat
Sistemas: es un proceso sistemtico de evaluacin post-mortem y de formacin de opinin sobre una de-
terminada materia o situacin. Para nuestro caso sobre una materia o situacin relacionada a Tecnologa de Informa-
cin tal como un Sistema Informtico, una Base de datos, una Infraestructura tecnolgica, unos Servidores, la gestin
del Gerente de TI, un proceso de atencin de soporte tcnico a usuarios, etc.
Causa: En el contexto de un hallazgo de Auditoria en el Sector Publico se refiera a la(s) razn(es) fundamental(es)
por la cual ocurri la condicin o el motivo por el que no se cumpli el criterio o la norma.
CISA: Acrnimo de Certified Information Systems Auditor. Es la certificacin internacional ms reconocida en el m-

bito de la Auditoria de Sistemas.
Control: Es cualquier cosa que minimiza un riesgo. Por ejm. escribir un procedimiento, implementar un firewall, ins-
talar 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).
Dao: Es el impacto negativo que tenemos si la amenaza se aprovecha de la(s) vulnerabilidad(es). El dao pude ser
econmico, patrimonial, de imagen, etc.
Hallazgo de Auditoria: Es la descripcin que hace un Auditor de Sistemas para dar a conocer una situacin de riesgo.
ISACA. Acrnimo de Information Systems Audit and Control Association(ISACA) que es la institucin mundial ms
importante en Auditoria de Sistemas.
Recomendacin: 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 dao.
Objetivos Vulnerabilidad:
Inicio es cualquier deficiencia que tenga un activo informtico.
Actividades Autoevaluacin
os
BIBLIOGRAFA DE LA UNIDAD I
Glosario Bibliografa
s
Information systems audit and control association. (2016). CISA Re-view Manual. Chicago: ISACA.
o Anotaciones
Information
Chat
systems audit and control association. (2012) COBIT 5 Un marco de negocio para el Gobierno y la Gestin de la
TI en la Empresa. USA: ISACA.
Objetivos Inicio
AUTOEVALUACIN DE LA UNIDAD I
s
1. Ud. est planificando una auditoria al rea de Sistemas de la compaa farmacutica Pharmax. Al respecto, Cul
s
Glosario
de los siguientes NO sera parte de su planificacin de Auditoria?
Bibliografa
A) Evaluacin del rea / tema de la auditora
o Anotaciones ChatB) Obtencin de la evidencia
C) Verificacin de las Pruebas
D) Entrega del Informe
2. Ud. se encuentra auditando la gestin de la Gerencia de Sistemas de la compaa Aji-si-moto y en 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 Ge-
rente 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 de Sistemas autoriza
el pago puntual a la referida compaa. 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 recomendacin
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 pblico, Ud. encuentra que solo existe una observacin por subsanar y que dicha observacin cuenta
con la siguiente estructura:
Descripcin
Criterio
Riesgo
Causa
Recomendacin
Conclusin
En ese contexto, cul de los siguientes representa a la seccin Criterio.
A) La norma transgredida
B) El criterio del auditor
C)
La clasificacin del riesgo encontrado por el auditor
D) La amenaza
4. Lea cuidadosamente la siguiente observacin de Auditoria:
Durante la visita efectuada al rea de TI, se observ que no existe una configuracin de redes virtuales (VLANs)
en las sedes de la compaa, que permitan segmentar el enrutamiento de los datos y mitigar el riesgo de un ac-
ceso ilimitado a toda la red. Recientemente, el rea de TI evidenci la adquisicin de 2 switches (por renovacin
tecnolgica), que permitiran la configuracin de dichas redes virtuales. El Gerente de TI indic que las VLANs
sern 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 tcnica y un contra-
to elaborado para iniciar la implementacin, al cierre de la revisin an se encuentra pendiente la formalizacin
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 compaa, lo que signific una paralizacin de la red por 2 das. Esto
se debi a que la red no cuenta con las VLANs implementadas.
Cul sera la recomendacin ms idnea para reducir el riesgo presentado?
A) Se recomienda que el Gerente General contrate los servicios de una empresa especializada en implementacin
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 implementacin de las redes
virtuales, sin esperar el inicio del proyecto de Comunicaciones Unificadas.
D) Se recomienda que el Gerente de TI logre la autorizacin del Gerente General para el proyecto de Comunica-
ciones Unificadas.
5. Ud. comprende la importancia de gobernar y gestionar adecuadamente las tecnologas de Informacin. Al respec-
to. Ud principalmente recomendara utilizar el marco de referencia:
A) ITIL
B) CobiT
C) PMBOK
D) ISO 27002
6. Ud. ha implementado un Sistema de Gestin de Seguridad de la Informacin (SGSI) recientemente. Luego de la

implementacin Ud. recibe la visita del equipo de Auditoria y el equipo le indica que la auditoria se va a enfocar en
el proceso de evaluacin de riesgos de seguridad de la informacin. Cul de las siguientes normas es ms probable
que el equipo de auditoria utilice como referencia para ejecutar la auditoria?
A) ISO 27002
B) ISO 27001
C) Cobit5
D) COSO ERM
7. Una empresa trasnacional de alimentos con sede en Estados Unidos que cotiza en la Bolsa de New York (NYSE),
cuenta con una importante operacin en Per. Cul de las siguientes regulaciones estara en obligacin de cum-
plir la oficina en Per?
A) CobiT
B) ISO 27001
C) Sarbanes Oxley (SOX)
D) Normas tcnicas de Control Interno de la Contralora 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 Gestin
9. Cul de los siguientes es VERDADERO en relacin a los derechos ARCO que tiene un ciudadano con respecto a
sus datos en poder tienen las compaas en el Per en el marco de la Ley 29733 de Proteccin de Datos personales?
A) El derecho de Cancelacin se refiere a que un ciudadano puede solicitar a una compaa que le cancele un
monto de dinero por el uso de sus datos.
B) El derecho de Oposicin se refiere a que un ciudadano puede oponerse a algn tratamiento de sus datos como
por ejemplo no recibir publicidad de dicha compaa.
C) El derecho de Acceso se refiere a que un ciudadano puede solicitar que sus datos puedan ser accedidos de ma-
nera pblica.
D) El derecho de Rectificacin se refiere a que un ciudadano pueda solicitar a una compaa que elimine comple-
tamente 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 Lati-
noamrica en el Per y est revisando los temas regulatorios que debe cumplir para su correcto funcionamiento en
el pas. Al respecto, De Cul de las siguientes regulaciones estar la compaa preocupada debido a que maneja
datos como pruebas de reacciones alrgicas en personas voluntarias a las pruebas?
A) Ley 29733 de proteccin de datos
B) Basilea III
C) SOX
D) ISO 27001
UNIDAD II: Auditoria al Gobierno y Gestin de TI MANUAL AUTOFORMATIVO 47
UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIN DE TI

de contenidos
DIAGRAMA DE PRESENTACIN DE LA UNIDAD II

Diagrama

Desarrollo
Chat
de contenidos
seleccionadas

3 Videoclase (Video conferencia) 1. Identifica el gobierno (governance) 1. Valora la importancia de la ejecucin de

Tema N. 1: Gobierno y Gestin de TI corporativo y su relacin con el gobierno la auditoria de sistemas.
de TI. 2. Se auto valora por su aprendizaje de las
1. Gobierno Corporativo y Gobierno de TI
2. Formula la estrategia de TI. tcnicas de auditoria de siste-mas.
2. Practicas Gerenciales de Gestin de TI
3. Identifica el rbol normativo de TI. 3. Asume el compro-miso de revisar los
3. Auditora al Gobierno y a la Gestin de TI contenidos del manual.
4. Aplica las prcticas de inversin y asigna-
cin de recursos. 4. Valora la importancia de la auditoria de
Lectura seleccionada 1 : 5. Conocimiento de la estructura organiza- sistemas para el mejora-miento de una
De gerente de TI a CIO, una evolucin nece- cional, los roles y las responsabilidades empresa y para las actividades o procesos
saria en el Per relacionadas con TI. a realizar.
http://www.esan.edu.pe/conexion/actuali- 6. Participa en la redaccin de hallazgos 5. Participa activamente en el desarrollo de
dad/2011/11/14/de-gerente-de-ti-a-cio-una- relacionadas al Gobierno y la Gestin de las actividades de la asignatura.
evolucion-necesaria-en-el-peru/ TI.
Actividad N. 2
Participan en el Foro de discusin sobre las
prcticas gerenciales en el rea de Sistemas.
4 Videoclase 1. Identifica los riesgos relacionados a la

Tema N. 2: Continuidad de Negocio y continuidad de negocio.
Recuperacin de Desastres 2. Identifica los pasos de la ejecucin de un
1. Gestin de la Continuidad de Negocio plan de continuidad de Negocio.
2. Planeacin a la Continuidad de Negocio y 3. Formula hallazgos de auditoria de Siste-
Recuperacin de Desastres mas tomando como base los riesgos de la
continuidad de negocio.
3. Auditoria a la Continuidad de negocio
4. Formulacin del Informe de Auditoria
Tarea Acadmica N 1
Realiza una Auditoria al caso Recuperacin
Lectura seleccionada 2 de Desastres.
Ttulo: Lecciones aprendidas para la recupe-
racin de desastres tras el 9/11
http://www.pcworld.com.mx/Articu-
los/18319.htm
Autoevaluacin N 2
48 UNIDAD II: Auditoria al Gobierno y Gestin de TI
TEMA N. 1: GOBIERNO Y GESTIN DE T.I.
INTRODUCCIN
En este tema nos iremos a 10,000 metros de altura para presentar los tpicos que gestiona un Gerente de Tecnologa
de Informacin. Revisaremos los conceptos de Gobierno Corporativo, como impacta en la Organizacin 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 gestin y luego aprende-
remos a auditar el Gobierno y la Gestin de TI.
1 GOBIERNO CORPORATIVO Y GOBIERNO DE TI
1.1 Gobierno Corporativo
El Gobierno Corporativo (Corporate Governace) es un conjunto de buenas prcticas que deben ser seguidos por una
compaa para alinear los objetivos de los accionistas o a los propietarios (en Per normalmente una familia que con-
trola una empresa) la direccin y la administracin de la empresa, a travs de la definicin y separacin de roles estra-
tgicos, operativos, de vigilancia y gestin. Estas prcticas estn orientadas a lograr una trasparencia sobre los riesgos
de una empresa, protegiendo a los inversionistas o a los propietarios evitando actos ilcitos o fraudulentos (Recuerde
el Caso Enron).
El Gobierno corporativo responde a la pregunta: Qquien controla la empresa y porque? Las buenas prcticas de Go-
bierno Corporativo nacen como respuesta a la Crisis de los inversionistas (alineando los intereses de todas las partes
dentro de una Compaa.
En Per, la Superintendencia del Mercado de Valores, precisa en el documento Cdigo de Buen Gobierno Corporativo
para las Sociedades Peruanas que : La adopcin de prcticas de buen gobierno corporativo por parte de las socieda-
des, 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 administracin de los riesgos a los cuales
se encuentran expuestas; facilita el acceso al mercado de capitales; lleva a una reduccin del costo de capital, as como
a un mayor y mejor acceso a fuentes de financiamiento y de inversin a largo plazo; entre otras ventajas. Asimismo, la
experiencia ha demostrado que en la medida que exista mayor transparencia e informacin, mayor es la confianza que
desarrollan los inversionistas en los mercados. Las prcticas de buen gobierno corporativo ayudan a mitigar las fallas
que existen en los mercados financieros por la asimetra de informacin.
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 Informacin.
Si te interesa aprender ms sobre Gobierno Corporativo, puedes descargar el Cdigo de Buenas Prcticas de Go-
bierno Corporativo para las sociedades peruanas. Lo puedes encontrar en: http://www.smv.gob.pe/Uploads/CodB-
GC2013%20_2_.pdf
1.2 Gobierno de TI
Del concepto de Gobierno Corporativo se desprende el concepto de Gobierno de Tecnologas de Informacin.

que ofrece servicios que otorgan valor al negocio, ya que la forma cmo las
T.I son aplicadas tendr un impacto inmenso en si las compaas lograrn s
visin, misin
UNIDAD II: Auditoria o metas
al Gobierno estratgicas.
y Gestin de TI Es ms, TI tiene la obligacin de aporta
valor al negocio.
Al implementar Gobierno de TI, la gerencia general y la gerencia de TI dan

ISACA define al Gobierno de TI como el liderazgo, estructuras y procesos organizacionales que garantizan que la TI
el impulso
de la empresa sostiene y para
extiendeque TI cumpla
las estrategias con
y objetivos los objetivos de la compaa. Para
organizacionales. ello el
Gerente de TI debe cambiar la forma como la TI ejecuta, permitiendo la
Es decir que el rea de TI debe estar 100% alineado a los objetivos del negocio y eso es responsabilidad de la Gerencia
trasparencia
de TI. Histricamente y control
las reas del
de TI se han rea
visto como de
reasTI y gestionando
de Soporte losderiesgos
Tcnico. El rea relacionados
TI debe sacudirse de
con la tecnologa. Los Gerentes de TI exitosos entienden y manejan los ries-
esta forma de ser percibida y ser una rea que ofrece servicios que otorgan valor al negocio, ya que la forma cmo las
T.I son aplicadas tendr un impacto inmenso en si las compaas lograrn su visin, misin o metas estratgicas. Es
gos relacionados con la implementacin de nuevas tecnologas.
ms, TI tiene la obligacin 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 compaa. Para ello el Gerente de TI debe cambiar la forma como la TI ejecuta, permitiendo la traspa-
rencia y control del rea de TI y gestionando los riesgos relacionados con la tecnologa. Los Gerentes de TI exitosos
entienden y manejan los riesgos relacionados con la implementacin de nuevas tecnologas.
Figura 8. Gobierno Corporativo y Gobierno de TI.

Fuente: ISACA.
1.3 Implementacin delFigura

Gobierno de1TI.
Gobierno Corporativo y Gobierno de TI.
Fuente:
Para Implementar el Gobierno de TI existen 2 marcos de ISACA.
referencia principales. Evidentemente, el primer marco es el
Cobit5 (Recuerde que el CobiT5 permite implementar Gobierno y Gestin 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
1.3 evaluar,
pueda Implementacin del
dirigir y monitorizar Gobierno
el uso de compaa.
de las TI en una TI.
Para Implementar el Gobierno de TI existen 2 marcos de referencia principa

2 PRACTICAS GERENCIALES DE GESTIN DE TI
les. Evidentemente, el primer marco es el Cobit5 (Recuerde que el CobiT5
permitedeimplementar
2.1 Planeamiento TI Gobierno y Gestin de TI). El segundo marco es la
norma ISO/IEC 38500 Corporate Governance of Information technology
queEstratgico
2.1.1 Plan es un Empresarial
conjunto(PEE). de principios para que la Gerencia pueda evaluar, dirigir
Las y monitorizar el uso
compaas para lograr de las
sus objetivos TI en
primero una
deben compaa.
pasar por un procesos de definicin mediante un Pla-
neamiento Estratgico Empresarial (PEE) en el cual se define la visin, la misin, los Objetivos y las estrategias
de Negocio.
Normalmente, estos planes son formulados en reuniones de los ms altos directivos de la compaa (entre los
que debera participar el Gerente de TI) y definen el Plan del negocio a un horizonte de 5 aos como mximo.
Es muy comn encontrar Objetivos como ampliacin de las ventas, ampliacin de la participacin del mercado,
expansin a otros pases, regiones, reduccin de costos, lanzamiento de nuevos productos o servicios, entre otros.
2.1.2 Plan Estratgico de Tecnologa de Informacin.
El Planeamiento de Tecnologas de Informacin se debe realizar poniendo el foco del plan en coherencia con
el Plan Estratgico Empresarial, que vimos en la Unidad anterior.
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 acrnimo de Planeamiento Estratgico de TI, que es un
documento en el cual se plasma la visin, misin, objetivos de TI, el alineamiento de los objetivos de TI con el
negocio, y en funcin a ello, las metas y proyectos del rea de TI.
Usualmente el PETI es formulado con un alcance de tres aos de duracin, ya que es imposible prever que
nuevas tecnologas aparecern en los siguientes aos.
Como recordar el Gobierno de TI tiene que ver con la definicin de Objetivos de TI. A continuacin presen-
taremos una tabla conteniendo ejemplos de alineamiento de TI con el Negocio.
Tabla 2
Ejemplos de Alineamiento de TI con el Negocio
OBJETIVO DE NEGOCIO OBJETIVO DE TI
Aumentar en 30% las ventas Implementar un Sistema de ventas basado en tecnologas

mviles.
Mejorar la rentabilidad en 8% Implementar un Sistema de Consolidacin financiera
Abrir oficinas en 3 nuevos pases Ampliar la infraestructura tecnolgica 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 nego-
cio. Si un rea de TI no est orientado a ese logro, los objetivos de TI sern puramente tcnicos y no necesaria-
mente los intereses de TI coincidirn 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 percepcin de que TI
solo est para arreglar teclados y corregir la impresora, es decir el rea de TI se convierte en un rea de Sopor-
te Tcnico.
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 prctica de la industria, en la cual de manera peridica (por ejemplo, trimestral) se renen la Alta Gerencia
con los Gerentes de la Compaa para supervisar el logro de los objetivos y el desempeo 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 funcin a las necesidades de la compaa.
Un ejemplo de conformacin de un Comit de Sistemas podra ser: Presidente, Vicepresidente de Finanzas,
Vicepresidente de TI, Gerente de Marketing, Gerente de Ventas, Gerente de Produccin, entre otros.
2.2 Normatividad
Una prctica importante para el Gerente de TI para optimizar su gestin 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 Polticas.
Una poltica es una declaracin de una intencin o comportamiento de una compaa sobre un determinado tema.
Por ejemplo veamos esta poltica sobre respaldos:
La compaa respaldar la informacin crtica de manera peridica.
Como se puede apreciar, la poltica declara la intencin de la compaa, en este caso declara la intencin de respaldar.
La poltica no dice que se va a respaldar ni cmo se va a respaldar.
2.2.2 Normas.
Una Norma es el segundo peldao 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 Poltica.
Por ejemplo veamos la siguiente Norma:
Todos los das a las 10pm se realizar el respaldo de informacin de las Bases de Datos de los Sistemas Crticos
de la Compaa.
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 Crticos. La Norma es vinculante y est orientada a cumplir la Poltica, en este caso la poltica de
respaldo de informacin.
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 podra ser:
Procedimiento de respaldo de informacin

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 peldao 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 los pasos generales, mientras que el instructivo contiene los pasos detallados. El
instructivo puede contener instrucciones o comandos de sistema y puede ir acompaado de pantallazos.
A continuacin podemos ver un ejemplo de instructivo:
Instructivo de Instalacin de Software de respaldo.
Elaborado por: Revisado por: Aprobado por: Fecha de Emisin:

Elaborado Revisado por: Aprobado por: Fecha de Emi-
52 por: UNIDAD II: sin:
Auditoria al Gobierno y Gestin de TI
1. PROPSITO
Instalacin de la solucin para realizar copias de seguridad y recu-
1. PROPSITO
peracin de archivos en los equipos de la compaa.
2. de
Instalacin ALCANCE
la solucin para realizar copias de seguridad y recuperacin de archivos en los equipos de la compa-
a. Inicia con la ejecucin de la consola de administracin de RESPALDO
AUTOMTICO DE INFORMACIN y finaliza con el registro del moni-
toreo en el formato asociado correspondiente.
2. ALCANCE
Inicia 3.
con laDESCRIPCIN
ejecucin de la consola DE ACTIVIDADES
de administracin de RESPALDO AUTOMTICO DE INFORMACIN y fina-
liza con el registro del monitoreo en el formato asociado correspondiente.
3.1 Para encontrar los instaladores de RESPALDO AUTOMTICO
3. DESCRIPCINDE DE INFORMACIN
ACTIVIDADES para equipos Windows realizamos la
3.1 Para encontrarcombinacin deRESPALDO
los instaladores de teclas Windows
AUTOMTICO +R DEse mostrara la
INFORMACIN ventana
para equipos Windows
Buscar. En el cuadro escribimos la ruta \\SERVIDOR08 , por la ruta
realizamos la combinacin de teclas Windows + R se mostrara la ventana Buscar. En el cuadro escribimos
\\SERVIDOR08ultimo aceptamos
, por ultimo como
aceptamos como indica
indica la secuencia
la secuencia de la Figura1. de la Imagen 1.
3.2 Ingresamos a la carpeta instaladores como se muestra en

la Imagen 2.
Imagen
Figura 1 1
3.2 Ingresamos
3.2 Ingresamos a la carpeta
a la carpeta instaladores instaladores
como se muestra en la Figura2. como se muestra en
la Imagen 2.
9
Imagen 2
3.3 Una vez dentro ingresamos a la carpeta Utilitarios y Otros

Figura 2
haciendo doble click como se muestra en la Imagen 3
3.3 Una vez dentro ingresamos a la carpeta Imagen 2 haciendo
Utilitarios y Otros doble click como se muestra en la Figura3
3.3 Una vez dentro ingresamos a la carpeta Utilitarios y Otros

haciendo doble click como se muestra en la Imagen 3
Figura 3
Imagen 3
3.4 Hacer click al archivo Setup.exe para comenzar la instala-

cin del RESPALDO AUTOMTICO
Imagen DE3 INFORMACIN

cin del RESPALDO AUTOMTICO DE INFORMACIN
Imagen 4
Imagen 3

cin del RESPALDO AUTOMTICO DE INFORMACIN
3.4 Hacer click al archivo Setup.exe para comenzar la instalacin del RESPALDO AUTOMTICO DE INFORMA-
CIN
Imagen 4 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.
Como se puede apreciar, el instructivo es muy detallado y puede con-

tener pantallazos para que el usuario pueda seguirlo y cumplir con los
pasos indicados.
2.3 Practicas Gerenciales de RRHH
ElGerenciales
Practicas Gerente de TI enfocado
de RRHH en que se logren los objetivos de TI alineados con los objetivos del Negocio, debe preocu-
parse de contar con los mejores profesionales. Son las personas las que hacen que las cosas sucedan y son las personas
el factor
El Gerente de TIdeterminante
enfocado para
enelque
logrose
de los objetivos.
logren los objetivos de TI alineados con
os objetivos del Negocio, debe preocuparse de contar con los mejores pro-
ParaSon
esionales. ello ellas
gerente de TI debe
personas lasrecurrir a las mejores
que hacen que prcticas relacionadas
las cosas sucedan a la ygente.
son las
personas el factor determinante para el logro de los objetivos.
Para ello2.3.1
el gerente decontratacin.
Prcticas de TI debe recurrir a las mejores prcticas relacionadas
a la gente.
El gerente de TI debe asegurarse de que el rea de RRHH cuente con mecanismos de contratacin eficientes
que filtrarn al mejor candidato posible.
a) Verificacin 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
10 anteriores de los can-
didatos para confirmar la veracidad de la experiencia profesional.
b) Verificacin de Logros Acadmicos. Tambin hay que revisar si los grados, ttulos y certificaciones de los
candidatos son veraces. Cuantas veces se han visto casos que incluso han salido a la luz pblica, de gente que
dice tener una maestra o doctorado sin tenerlo.
c) Verificacin de Antecedentes. A cada uno de los candidatos se les debe solicitar que presenten sus antece-
dentes penales, policiales y judiciales. Un profesional serio no debera tener este tipo de antecedentes.
d) Verificacin domiciliaria. La verificacin domiciliara es importante para conocer el ambiente donde viven
los candidatos y si este ambiente podra ser riesgoso. Por ejm. se suele contratar a una compaa para realizar
las verificaciones domiciliarias.
e) Verificacin crediticia. La verificacin crediticia es importante ya que un candidato con deudas podra ori-
ginar un riesgo para la compaa. Su in candidato no honra sus deudas o est atravesando problemas fi-
nancieros, podra ser tentado a cometer un acto ilcito. Por ejm. se debe consultar a las centrales de riesgo
crediticias como Experian o Infocorp.
f) Prueba del polgrafo. En algunos casos, algunos puestos crticos para el rea de IT podran requerir de una
prueba del polgrafo(detector de mentiras).
2.3.2 Prcticas de retencin de talento.
Una vez que tenemos el mejor profesional, un reto mayo es retenerlo en la Compaa. Los profesionales talen-
tosos siempre estn buscando retos que valgan la pena.
Para la retencin, el Gerente de TI debe definir:
a) Lnea de carrera. El profesional debe conocer cul es la lnea de carrera en la compaa. El no contar con
una lnea de carrera origina que los trabajadores se aburran y busquen nuevas oportunidades fuera de la
Compaa.
b) Recompensa. Los mejores profesionales siempre esperan estar bien recompensados. No solo se trata del
monto mensual sino de conocer los mrgenes de Utilidades y bonos que la compaa le puede proporcionar.
c) Clima Laboral. Otro aspecto importante es el clima laboral. El profesional talentoso espera que la compaa
sea un lugar donde sea fcil trabajar, que su jefe le de libertad, que se reconozcan sus logros.
2.3.3 Segregacin de Funciones.
La segregacin de funciones es una prctica importante para prevenir actos ilcitos o fraudulentos. Cuando
existe segregacin de funciones un trabajador no puede controlar un proceso o transaccin de manera com-
pleta. 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 podra ver tentada de hacer
trampa.
Veamos un ejemplo: Suponga que Ud. es programador de la Municipalidad del distrito donde vive. Ud tiene ac-
ceso a los programas fuentes del Sistema Informtico. En esta municipalidad aplican la prctica de segregacin
de funciones por lo que Ud. no tiene acceso a la Base de Datos. Qu podra pasar si Ud. tuviese acceso a la Base
de Datos? Qu le impedira que acceda a la tabla de Arbitrios y pagar los arbitrios de su casa?. Lo nico que
lo detendra es su tica. Pero, Qu pasara 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 segregacin de fun-
ciones en su rea.
2.3.4 Prcticas de terminacin laboral.
El Gerente de TI debe tener definidos los procedimientos de cese de su personal. La mejor prctica indica que
se deben cortar inmediatamente los accesos a todos los recursos informticos una vez que una persona se retira
de la compaa. Esto aplica para todos los trabajadores de la compaa.
Es posible que un trabajador se retire mal de la compaa, es decir que se le detecte en un acto ilegal o tenga
un problema laboral que exija que se retire inmediatamente de la compaa y se le retiren tambin inmediata-
mente todos los accesos.
2.4 Tercerizacin
La tercerizacin es una de las mega-tendencias tecnolgicas y los Gerentes de TI deben aprovechar muy bien esta
oportunidad.
La tercerizacin tiene que ver con pasar a una compaa especialista actividades que no estn directamente relaciona-
das con la misin 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 Tcnico, el desarrollo de software, la gestin de la infraes-
tructura tecnolgica, entre otros. Incluso en Per hay algunos casos en donde se ha tercerizado la gran matoria de TI
e incluso hay un par de compaas 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 deter-
minado tema. Asimismo, la tercerizacin 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. Tambin se dice a menudo que la
tercerizacin reduce costos, pero no siempre es as. A veces incluso puede salir ms caro.
Uno de los aspectos ms 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 hacindolo internamente. Es decir no tiene sentido, contratar a un
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
no haya de Nivel de Servicio
cortes en el (ANS), por En
servicio. sus siglas en espaol.
un mundo ideal, el SLA debera ser de
100% lo que significa que los aparatos siempre estarn funcionando. Sin
Un SLA es emabrgo,
un documento estoennoel cual el proveedor
es as. se compromete
Si e proveedor a garantizar
nos ofrece un SLAun determinado
de 99.95% nivel
dede servicio. En
caso de quedisponibilidad
el proveedor noal cumpla con dicho nivel, le aplicaremos una penalidad.
ao, esto significara que nosotros toleraramos cortes al
ao que representan como mximo el 0.05%. El 0.05% de 365 das son 18
Por ejemplo, si contratamos un proveedor para que nos gestione la infraestructura tecnolgica compuesta por servi-
das. Esto es inaceptable para una compaa.
dores, switches y routers, deberamos exigir que estos aparatos siempre estn funcionado, de tal manera que no haya
En cambio, el proveedor nos ofrece un SLA de 99.99%, esto significa que
cortes en el servicio. En un mundo ideal, el SLA debera ser de 100% lo que significa que los aparatos siempre estarn
toleraramos un corte de 3.65 dias. Dependiendo del tipo de compaa, esto
funcionando. Sin emabrgo, esto no es as. Si e proveedor nos ofrece un SLA de 99.95% de disponibilidad al ao, esto
significarapodra ser inaceptable.
que nosotros toleraramos cortes al ao que representan como mximo el 0.05%. El 0.05% de 365 das son
Si el proveedor
18 das. Esto es inaceptable para nosunaofrece un SLA de 99.999%, esto significa que tolerara-
compaa.
mos un corte de 8 horas al ao.
En cambio,Mientras
el proveedormejor es el un
nos ofrece SLA,
SLAmejor seresto
de 99.99%, el servicio y evidentemente,
significa que el servi-
toleraramos un corte de 3.65 dias. Depen-
cio se encarece ya que el proveedor
diendo del tipo de compaa, esto podra ser inaceptable. tendr que invertir ms en sistemas de
contingencia.
Si el proveedor nos ofrece un SLA de 99.999%, esto significa que toleraramos un corte de 8 horas al ao.
2.5 Capacidad y planeacin del crecimiento
Mientras mejor es el SLA, mejor ser el servicio y evidentemente, el servicio se encarece ya que el proveedor tendr
que invertirOtro
ms enimportante
sistemas deaspecto que un Gerente debe gestionar es velar que la tec-
contingencia.
nologa siempre responda a las necesidades del Negocio. Por ejemplo nunca
debera suceder que nos quedemos sin espacio de disco duro, ni que los
2.5 Capacidad y planeacin del crecimiento
usuarios se queden sin ancho de banda o que el CPU del Servidor de Archi-
vos est
Otro importante al 90%
aspecto que un deGerente
utilizacin.
debe gestionar es velar que la tecnologa siempre responda a las necesidades
Para evitar esto, hay
del Negocio. Por ejemplo nunca debera que suceder
estar continuamente
que nos quedemos monitoreando la capacidad
sin espacio de disco de los usuarios se
duro, ni que
queden sinla tecnologa
ancho de bandayo adelantarse
que el CPU delaServidor
posibles de circunstancias
Archivos est al 90% y tomar decisiones de
de utilizacin.
renovar la tecnologa o ampliar la capacidad.
Para evitar Ampliar
esto, hay laquecapacidad significa adquirir
estar continuamente ms la
monitoreando GB de disco
capacidad desila nos estamos
tecnologa que-
y adelantarse a posibles
dando
circunstancias sin decisiones
y tomar espacio. de Tambin
renovar podra significar
la tecnologa adquirir
o ampliar ms memoria RAM si la
la capacidad.
memoria est quedando corta. Esto debe hacerse de manera planificada
Ampliar la capacidad significa adquirir ms GB de disco si nos estamos quedando sin espacio. Tambin podra signifi-
car adquirirVeamos
ms memoria RAM si laTenemos
un ejemplo. memoria est una quedando
compaa corta.
que Esto debe hacerse un
experimenta de manera planificada
importante
incremento en ventas en el mes de mayo. SI el Gerente de T.I. realiza un
Veamos unproceso
ejemplo. de
Tenemos una compaa
monitoreo que experimenta
de la capacidad, un importante
el grafico incremento
de utilizacin en ventas en el mes de
de memoria
mayo. SI el Gerente de T.I. realiza un proceso de monitoreo de la capacidad, el grafico de utilizacin de memoria se
se vera de la siguiente manera:
vera de la siguiente manera:
Figura 1- Ejemplo de Uso de Memoria RAM.

Figura 9. Ejemplo de Uso de Memoria RAM.
Fuente: Elaboracin
Fuente: Elaboracin propia.propia.
Como
Como se puede se puede
observar en elobservar
ejemplo, elen
usoelde
ejemplo, el va
la memoria uso de la memoria
aumentando va aumentan-
desde mayo hasta julio y que de seguir
do desde mayo hasta julio y que de seguir as nos quedaremos sin memoria
as nos quedaremos sin memoria en el mes de setiembre.
en el mes de setiembre.
Por otro lado, la gestin de la capacidad tambin tiene que ver con no com-
56
prar ms de lo necesario. Imagine
que compramos UNIDAD II: Auditoria al Gobierno y Gestin de TI
un nuevo servidor con
32GB de RAM. Se instala el software y el software consume 8 GB casi de
manera consistente. Qu pasara con los otros 24GB no utilizados? Pues
son Por
capital muerto,
otro lado, esla decir
la gestin de son
capacidad soles
tambin tiene(o
que dlares) que gastamos
ver con no comprar y no
ms de lo necesario. utili-que
Imagine
zamos.
compramos un nuevo servidor con 32GB de RAM. Se instala el software y el software consume 8 GB casi de manera
consistente. Qu pasara con los otros 24GB no utilizados? Pues son capital muerto, es decir son soles (o dlares) que
gastamos y no utilizamos.
6 Satisfaccin de usuarios.
2.6 Satisfaccin de usuarios.
El Gerente de TI debe estar comprometido en lograr la satisfaccin de los
El Gerente de TI debe estar comprometido en lograr la satisfaccin de los usuarios con los servicios que TI entrega. La
usuarios con los servicios que TI entrega. La forma ms efectiva de saber
forma ms efectiva de saber cul es la percepcin de nuestros usuarios es preguntndoles!
cul es la percepcin de nuestros usuarios es preguntndoles!
ParaPara
ello,
ello, el Gerente
el Gerente de TIdedebeTI debe
realizar realizar
encuestas encuestas
de satisfaccin depara
peridicas satisfaccin
saber de primeraperidicas
mano cual es el
grado de satisfaccin de los usuarios con el servicio ofrecido por el rea de TI.
para
A continuacin, presentaremos
A continuacin, presentaremos un ejemploun ejemplo de encuesta:
de encuesta:
Figura 2-Figura
Ejemplo de
10. Ejemplo de encuesta.
encuesta.
Fuente: Elaboracin propia.
2.7 Benchmarking.
7 Benchmarking.
El benchmarking es una tcnica de mejora continua. Consiste en comparar una materia o un proceso que se realiza
dentro de la compaa y hacer la comparacin entre como lo hacemos nosotros y como lo hace una compaa recono-
El benchmarking es ouna
cida del pas, de la regin tcnica de mejora continua. Consiste en comparar
mundial.
una Enmateria o un proceso que se realiza dentro de la compaa y hacer la
funcin a la comparacin, se pueden muchas oportunidades de mejora para que un Gerente de TI mejore su gestin.
comparacin entre como lo hacemos nosotros y como lo hace una compaa
reconocida delnopas,
En el Per esta de la muy
es una prctica regin o mundial.
establecida debido a que las compaas no comparten informacin entre ellas.
Pero en otros pases como en Estados Unidos, es normal que las compaas comparten su informacin. Dado que el
En funcin a la comparacin, se pueden muchas oportunidades de mejora
modelo en Estados Unidos es que las compaas estn basadas en accionistas, por la transparencia del Gobierno Cor-
paraporativo,
que un Gerente
comparten muchade Ti mejore
informacin la cual su gestin.
puede ser aprovechada para hacer benchmarking.
En el Per esta no es una prctica muy establecida debido a que las compa-
as2.8
noGestin
comparten
de cambios informacin entre ellas. Pero en otros pases como en Es-
tados Unidos, es normal que las compaas comparten su informacin. Dado
El rea de TI maneja por su propia naturaleza muchos Sistemas. La infraestructura tecnolgica, los sistemas inform-
que ticos
el modelo
son complejosensistemas
Estados Unidos
que estn es que
funcionando en la las compaas
Compaa. estn
En su definicin msbasadas en ac-
simple, un Sistema es un
cionistas, por
conjunto de lainterrelacionadas
partes transparencia del Gobierno
y que interactan Corporativo,
con el propsito comparten
de lograr un objetivo, mucha
En este orden de ideas,
un cambio a alguna parte de un sistema podra afectar al Sistema en su conjunto.
informacin la cual puede ser aprovechada para hacer benchmarking.
Es muy frecuente escuchar a los usuarios decir que: Los del rea de TI o Sistemas cuando corrigen alguna cosa ma-
8 Gestin
logran de
otra cambios
cosa. Estas situaciones se originan cuando se realizan cambios a los sistemas y estos cambios impactan en
alguna otra parte, lo cual impacta a los usuarios de dicho Sistema.
El rea de TI maneja por su propia naturaleza muchos Sistemas. La infraes-

tructura tecnolgica, los sistemas informticos son complejos sistemas que
estn funcionando en la Compaa. En su definicin ms simple, un Sistema
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 situacin 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 revisin por el Comit de Cam-
bio (Change Advisory Board CAB por sus siglas en ingles).
Veamos un ejemplo de un RFC:
Requerimiento para Cambio

Fecha de 28-10-2015 Cdigo RFC:
Ingreso:
Fecha de Estado: En
liberacin: Proceso
Iniciador del Cambio:

Nombre: Luis____________ Correo: a@compaia.com____
Apellidos: Iberico__________ rea: Seguridad
IT_________________
Tel.:
Descripcin del Cambio (Razn de Negocio e Impacto)

Detalle del Cambio Estado Actual y Estado despus del cambio
Modificacin en la configuracin de la consola de administracin de antivirus, dnde se
deshabilitar la opcin 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 po-
sibilidad de agregar excepciones desde el cliente antivirus para ejecutar algn tipo de software
malicioso.
Riesgo de no aplicar el cambio: La vulnerabilidad sigue vigente.
Impacto en el Negocio: No
Servicios Impactados: Componentes Impactados:

Servicio Antivirus Symantec de Per.
Urgencia
o Emer- O Media
gencia (Hasta 2 ventanas)
(Mismo
Da)
o Baja
(Mnimo 2 ventanas)
X Alta
(Inmediata)
Impacto
o Alto
Impacto
Alto Medio Bajo
Alta 1 2 3
Urgencia
Media 2 3 3
Baja 3 4 4 X Medio
o Bajo
Prioridad = Urgencia x Impacto
1: Emergencia
2: Alta
3: Significante
4: Baja Estndar
Consideraciones de Interrupcin de Servicio:
N.A
Atributos del Despliegue:

O Se requiere el reinicio del Sistema?
O Se requiere el reinicio del servicio?
X El despliegue es automatizado?
Ubicacin de Planes de Liberacin, Despliegue, Pruebas y Rollback:

Insertar la ruta correspondiente de la ubicacin de estos archivos segn aplique.
o Plan de liberacin. Incluye los resultados de la evaluacin de Software/ Hardware y el
mecanismo de liberacin.
o Plan de Despliqegue. Incluye el Cronograma de distribucin de paquetes.
o Plan de Pruebas. Incluye los requerimientos mnimos de Pase o indicadores de falla en la
prueba. Deben ser revisados antes del pase a produccin.
Figura 11. Ejemplo de un RFC.

2.9 Gestin Financiera
Una de las principales preocupaciones de un Gerente de TI es optimizar los recursos. Es decir hacer ms 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 tecnologa se carguen no solamente a TI, sino que
se carguen contablemente a quienes utilizan la tecnologa.
Veamos un ejemplo. Considere que un Gerente de TI de una compaa que tiene 500 usuarios necesita comprar un
nuevo switch para la red. En primer lugar, esta compra debera estar en el presupuesto. Si est en el presupuesto,
entonces nos deberan 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 tecnologa!
Lo debe pagar T.I. !!!
Ahora repensemos: Quin o quienes utilizan el switch? Es solo el rea de TI? Por supuesto que no. El switch es utili-
zado 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 gestin financiera, el Switch lo pagar contablemente el centro de Costos del rea de T.I. El
problema de esto es que si toda la tecnologa que una compaa 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 ms gastadoras de toda la compaa.
Muchas de las compaas cuando compran tecnologa cargan todo el gasto de la tecnologa al rea de T.I. Es labor
del gerente de T.I. educar a los ejecutivos de alto nivel de la compaa que si bien T.I. hace la adquisicin, pero la
utilizacin es de todas las reas de la compaa 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 dems reas del presupuesto que deben con-
siderar en sus presupuestos por la parte que les toca de los gastos de tecnologa.
3 AUDITORIA AL GOBIERNO Y A LA GESTIN DE TI
3.1 La Auditoria
Para auditar el Gobierno y la Gestin de TI, el Auditor debe conocer los conceptos de Gobierno y gestin de TI; as
como las prcticas gerenciales presentadas en este tema.
El Auditor debe recabar la documentacin de Gobierno y Gestin, tal como planes, actas, presupuestos, contratos,
reunirse con el Gerente de T.I. y los profesionales que le reportan al Gerente de T.I.
Con toda esta informacin y de acuerdo al Plan de Auditoria, el Auditor de Sistemas se enfocar en encontrar situa-
ciones que puedan originar riesgos.
3.2 Situaciones que podra originar riesgos.
A continuacin presentaremos situaciones que generan riesgo:
a) Planeamiento Estratgico
- Falta de Plan Estratgico
- Desactualizacin del Plan Estratgico
- El Plan Estratgico 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 polticas
- Los documentos normativos estn desactualizados
d) Prcticas de Recursos Humanos
- No existen prcticas de contratacin de personal de T.I.
- No existen prcticas de retencin del talento
- No se hace revisin de desempeo
- No se hace segregacin de funciones
e) Gestin de la capacidad
- No se monitorean la capacidad de los diversos recursos informticos
- Si se monitorea, no se toman acciones cuando los
- Existen demasiados recursos informticos
f) Satisfaccin de usuarios
- No se mide la satisfaccin de usuarios
- No se toma accin sobre las encuestas realizadas.
g) Benchmarking
- No se realiza procesos de benchmarking

- No existe un proceso de mejora de los proceso de T.I.
h) Gestin de cambios
- Los cambios se realizan sin autorizacin
- No se realiza un anlisis de los impactos de los cambios
- Si sucede un error, los usuarios son los que pagan las consecuencias.
i) Gestin Financiera
- No existe presupuestos de TI
Diagrama
- Los presupuestos
Objetivos Inicio de las reas no consideran los gastos de tecnologa
- Todos los gastos de tecnologa son cargados a TI

de contenidos
LECTURA SELECCIONADA N. 1:
seleccionadas
Leer artculo: De gerente de TI a CIO, una evolucin necesaria en el Per
Santana
Recordatorio
Ormeo,Chat
Anotaciones
M. (2011). De gerente de TI a CIO, una evolucin necesaria en el Per. Disponible en http://bit.
ly/2bdRZE5
TEMA N. 2: CONTINUIDAD DE NEGOCIO Y RECUPERACIN DE DESASTRES
INTRODUCCIN
Este tema est enfocado en como efectuar una Auditoria de Sistemas a la Continuidad de Negocio y Recuperacin de
Desastres.
1 GESTIN DE LA CONTINUIDAD DE NEGOCIO
1.1 La dependencia de las compaas hacia la tecnologa.
A medida que las compaas utilizan ms y ms la tecnologa, se vuelven ms dependientes de ella. Casi todos los proce-
sos de una compaa estn soportados por tecnologa. Aqu cabe preguntarse: Si las compaas son ms dependientes
de la tecnologa Qu pasara con la compaa si la tecnologa falla de manera prolongada? Qu le puede pasar a una
compaa si sus sistemas informticos son interrumpidos por la ocurrencia de un desastre?
Eso fue precisamente lo que sucedi el da 11 de setiembre del 2001 a muchas compaas. Ese da 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 compaas que funcionaban en ambas torres. Ese da fue el ltimo da de las
compaas? O podra ser que, algunas compaas lograron sobrevivir a semejante desastre?
La respuesta a esta interrogante es la Continuidad de Negocio y Recuperacin de Desastres. La diferencia entre que
una compaa cierre sus puertas o que logre superar un desastre es si ha implementado procesos de Continuidad de
Negocio y Recuperacin de Desastres.
1.2 Gestin de la Continuidad de Negocio.
La Gestin de la Continuidad de Negocio es un proceso que le permite a una Compaa estar preparada ante la ocu-
rrencia de un desastre, identificando potenciales impactos de amenazas a la compaa y proveyendo una estructura
flexible y una capacidad de efectiva respuesta para continuar con las operaciones de la compaa.
1.3 Estndares internacionales.
Para implementar este proceso, a nivel mundial existen marcos de referencia para la gestin de la Continuidad de
Negocio.
La principal norma es la norma ISO 22301:2012 Seguridad de la sociedad Sistemas de gestin de la continuidad del
negocio y se ha posicionado como el marco de referencia para gestionar la continuidad del negocio en una organi-
zacin, para disminuir la posibilidad de ocurrencia de un incidente que impacte prolongadamente a una compaa
y, en caso de producirse, que la compaa est preparada para responder en forma adecuada y, de esa forma, reducir
drsticamente el dao potencial de ese incidente.
Tambin 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 & Organi-
zational Continuity.
quede inoperativa por un periodo de tiempo que impacte adversa-
mente sus operaciones. Estas interrupciones obligan a la compaa a
tomar acciones para recuperar el estado operativo en el que estaba
62 antes del desastre. UNIDAD II: Auditoria al Gobierno y Gestin de TI
El origen de los desastres puede ser:
1.4 Desastres a) Naturales. Como por ejemplo terremotos, tsunamis, inundaciones,

huaicos, huracanes, etc.
Los desastres sonb) Tecnolgicos.
interrupciones que Entre esteque
ocasionan tipo decompaa
una desastres tenemos
quede apagones,
inoperativa por un periodo de tiempo que
impacte adversamente malware, fallas en
sus operaciones. la interrupciones
Estas infraestructura, etc.a la compaa a tomar acciones para recuperar el
obligan
estado operativo c)
en elHumanos.
que estaba Por
antesejemplo un incendio provocado por un atentado,
del desastre.
una huelga, entre otros.
El origen de los desastres puede ser:
Ejemplos
a) Naturales. Como de desastres
por ejemplo abundan.
terremotos, tsunamis,Ainundaciones,
nivel mundial tenemos,
huaicos, solo por
huracanes, etc.
b) Tecnolgicos.citar
Entrealgunos
este tipoejemplos:
de desastres el derrumbe
tenemos de las
apagones, torres fallas
malware, gemelas
en la en Nueva
infraestructura, etc.
York, el tsunami en el sudeste asitico, la epidemia SARS, el apagn
c) Humanos. Por a ejemplo un incendio
gran escala provocado
en el Noreste deporUSAunyatentado,
Canad,una loshuelga, entre otros.
huracanes Katrina y
Sandy, los terremotos en Japn, el desastre nuclear en Fukushima,
Ejemplos de desastres abundan. A nivel mundial tenemos, solo por citar algunos ejemplos: el derrumbe de las torres
gemelas en Nueva etc.
York, el tsunami en el sudeste asitico, la epidemia SARS, el apagn a gran escala en el Noreste de
USA y Canad, los huracanes Katrina y Sandy, los terremotos en Japn, el desastre nuclear en Fukushima, etc.
El Per no es ajeno a los desastres. Por ejemplo tenemos al Fen-
El Per no es ajeno
menoa losdel
desastres. Por ejemplo
Nio que tenemos
causa lluvias al Fenmeno
torrenciales e del Nio que causa
inundaciones lluvias torrenciales e inun-
cada
daciones cada cierto nmero de aos.
cierto nmero de aos.
Seguramente Ud. recuerda
Seguramente Ud. recuerda el terremoto en Piscoel el
terremoto
ao 2007. enEsePisco el ao
terremoto 2007.
afect Ese compaas entre las
a muchas
terremoto afect a muchas compaas entre las cuales figuran
cuales figuran empresas de telecomunicaciones que al verse afectadas, afectaron a sus clientes. em-
presas de telecomunicaciones que al verse afectadas, afectaron a sus
A continuacin presentaremos unas vistas de cmo quedo la torre de una compaa de telecomunicaciones que comu-
clientes.
nicaba Ica con Lima
A continuacin presentaremos unas vistas de cmo quedo la torre de
una compaa de telecomunicaciones que comunicaba Ica con Lima
Figura 12. Situacin de la torre de comunicaciones de la compaa Nextel en el terremoto de Pisco.

Figura 1 Situacin de la torre deFuente:
comunicaciones
Nextel. de la compaa Nextel
en el terremoto de Pisco.
Fuente: Nextel.
22
Figura 2 Vista lateral de la torre de comunicaciones de la compaa

Figura
Nextel 13. Vista
en el lateral de la torre de
terremoto decomunicaciones
Pisco. de la compaa Nextel en el terremoto de Pisco.
Fuente: Nextel.
Fuente: Nextel.
Un desastre puede interrumpir las operaciones de una Compaa, lo que nos

obliga a tomar acciones para estar preparados.
Un desastre puede interrumpir las operaciones de una Compaa, lo que nos obliga a tomar acciones para estar pre-
parados.
2 PLANEACIN A LA CONTINUIDAD DE NEGOCIO Y RECUPERACIN DE DESASTRES
Para hacer frente a los desastres, las compaas deben estar preparadas. El objetivo de la continuidad del negocio /
recuperacin de desastres es habilitar a un negocio para que contine brindando sus servicios crticos en caso de de-
sastre y que pueda sobrevivir a una interrupcin por un desastre en sus operaciones y en sus sistemas de informacin.
Repasemos el prrafo anterior. El objetivo no es evitar el desastre. No es posible evitar un desastre. Cmo podramos
evitar que suceda un terremoto? Cmo podramos evitar la ocurrencia del fenmeno del nio?
Lo que si puede hacer una compaa 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 compaas fueran resilentes? Es decir si sucede un desastre, la compaa rpidamente (cual resorte)
podran volver a su estado normal.
La Continuidad de Negocio ayuda a las compaas a volverse resilentes.
2.1 Componentes del BCP.
Un Plan de Continuidad Negocios o Business Continuity Plan (BCP) es un plan que formula una compaa 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 operacin
de los procesos crticos. Es decir, los procesos que no deben para en una compaa. Aqu las reas para ejecutar
sus procesos podran usar sistemas stand-alone, hojas de clculo o incluso procedimientos manuales a papel y lpiz
para continuar con las operaciones crticas.
b) Plan de Recuperacin de Desastres. Tambin conocido como Disaster Recovery Plan (DRP). Este plan es ejecutado
por el rea de T.I. y tiene como objetivo recuperar los recursos informticos que soportan los procesos crticos de
una compaa.
Ambos planes se deben ejecutar en paralelo. Es decir, mientras las reas usuarias trabajan en la continuidad de sus
operaciones crticas (sin los sistemas informticos), el personal de T.I. se enfoca en volver a la operatividad los recursos
informticos ejecutando el DRP.
2.2 Fases del BCP
El plan de continuidad de Negocio y recuperacin de desastres consta de 4 fases:
a) Anlisis de Impacto de negocio.
Esta fase tambin conocida como Business Impact Analysis (BIA) est enfocada en identificar los procesos crticos
de negocio, Es decir, hay que seleccionar de todos los procesos de la compaa a los procesos que no deben parar
ya que afectaran severamente a la compaa. Estos procesos son los llamados procesos crticos.
En esta fase tambin se identifican las mtricas de tiempo de recuperacin como son el Recovery Point Objective
(RPO), el Recovery Time Objective. (RTO), el Maximum Tolerable Downtime (MTD) y el Work Recovery Time (WRT).
El RPO es la prdida aceptable de datos en el caso de una interrupcin de las operaciones. Ello indica el
punto ms anticipado en el tiempo al cual es aceptable recuperar los datos (ej. 4 horas). Esta mtrica sirve
para definir la frecuencia de los respaldos (backups). Mientras ms pequeo el RPO ms esfuerzo y dinero
se invertir en los respaldos.
El RTO es el tiempo improductivo aceptable en el caso de una interrupcin de las operaciones. Ello indica
el punto ms lejano en el tiempo en el que las operaciones de negocio deben retomarse despus del desas-
tre. Por ejemplo si una compaa puede tolerar 3 horas entonces su RTO es de 4 horas. El RTO puede ser
calculado para cada proceso crtico del negocio identificado en el BIA. Mientras ms pequeo el RTO ms
esfuerzo y dinero se invertir en la estrategia de recuperacin.
El MTD es el Tiempo durante el cual un proceso puede estar inoperante hasta que la empresa empiece a
tener prdidas y colapse.
El WRT es el Tiempo entre la recuperacin del sistema y la normalizacin del procesamiento. Es el tiempo
invertido en buscar datos perdidos y realizar reparaciones.
En la siguiente figura se aprecian la relacin entre los distintos indicadores:
Figura 14. Relacin entre los tiempos de la recuperacin de desastres.

b) Estrategias de recuperacin.
UnaFigura
vez que se3 definido
han Relacin entre
los procesos los detiempos
crticos negocio y lasde la recuperacin
mtricas de recuperacin, el de desas-
siguiente paso es
tres.
seleccionar una de las estrategias de recuperacin. En T.I es imposible hablar de recuperacin, si es que no se tiene
un Centro de Datos de Respaldo.
Fuente: Elaboracin propia
Existen 5 estrategias de recuperacin:
b) Estrategias de recuperacin.
Alta Disponibilidad. Tambin conocida como High Avalilability (HA). Esta estrategia es utilizada cuando el
RTO es muy pequeo. Se trata de tener un Centro de Datos replicado en tiempo real. Esto significa que si un
dato es grabado en una Base de Datos en el Centro de Datos principal automticamente se graba una copia
Unaen vez que
el Centro se han
de Datos definido los procesos crticos de negocio y las
de Respaldo.
mtricas de recuperacin,
Hot Site. Consiste el Datos
en tener un Centro de siguiente paso
alterno similar es seleccionar
al Centro de Datos principaluna dela repli-
pero sin las
estrategias de recuperacin.
cacin de los datos en tiempo real. En T.I es imposible hablar de recupera-
cin,
WarmsiSite.
es Esque no se
un Centro tiene
de Datos conun Centroparcial
equipamiento de Datos deal Respaldo.
o inferiores Centro de Datos principal. Por
Existen
ejemplo5 estrategias
si una compaa hacede recuperacin:
renovacin tecnolgica de servidores, los servidores antiguoes pueden ser
enviados al Centro de Datos Warm Site.
Alta Disponibilidad. Tambin conocida como High Avalilability (HA).

Esta estrategia es utilizada cuando el RTO es muy pequeo. Se
trata de tener un Centro de Datos replicado en tiempo real. Esto
Cold Site. Ms que un Centro de datos es una ubicacin con la infraestructura bsica (electricidad, cableado
de datos) para soportar la recuperacin, la cual se puede realizar trayendo los equipos necesarios para rea-
lizar la recuperacin.
Acuerdo reciproco. Esta es una estrategia a utilizar cuando la compaa no cuenta con recursos para imple-
mentar un centro de Respaldo. El Acuerdo indica que la compaa A puede utilizar al Centro de Datos de
la compaa B en caso de un desastre y viceversa. Este acuerdo se puede firmar con una compaa amiga y
que tenga una infraestructura informtica similar a la nuestra. Ejemplo de ello podra ser compaas de un
mismo grupo empresarial o en compaas del Estado.
Sitios Mviles: Esta es una estrategia en la cual se tiene un Centro de Datos mvil, el cual puede ser transpor-
tado a un lugar determinado que necesite un Centro de Respaldo. Por ejemplo podra ser til en una mina
o en caso de eventos deportivos. La siguiente figura ilustra un Sitio Mvil.
Figura 15. Ejemplo de Centro de Datos Mvil. Fuente: APC.
La seleccin de una estrategia depende del RTO, pero tambin del costo del Centro de Datos de recuperacin.
c) Desarrollo del Plan.
Una vez definida la estrategia de recuperacin ya se puede pasar a formular el Plan de Recuperacin de Desastres.
Aqu se deben considerar los siguientes puntos:
Procedimientos de preparacin antes de un desastre
Procedimientos de evacuacin
Procedimientos para declarar un desastre
Las circunstancias bajo las cuales se debe declarar un desastre.
La identificacin de responsabilidades en el plan
La identificacin de las personas responsables de cada funcin en el plan
La identificacin de los diversos recursos requeridos para la recuperacin y operacin continua de la orga-
nizacin
Los Nmeros de telfonos y direcciones del personal crtico, de los proveedores, de los agentes de las com-
paas de seguros.
La explicacin paso por paso de las etapas de recuperacin.
Asimismo, en el plan se definen los equipos que estn involucrados en los procesos de Continuidad y recuperacin
de Desastres. A continuacin se muestran los posibles equipos que se forman para
Equipo de accin ante emergencias
Equipo de evaluacin de daos
Equipo administrador de la emergencia

Equipo de almacenamiento alterno (Off-site)
Equipo de software
Equipo de aplicaciones
Equipo de seguridad
Equipo de operaciones de emergencia
Equipo de recuperacin de la red
Equipo de comunicaciones
Equipo de Transportes
Equipo de hardware de usuario
Equipo de preparacin de datos y registros
Equipo de soporte administrativo
Equipo de suministros
Equipo de salvamentos
Equipo de reubicacin
Equipo de coordinacin
Equipo de asuntos legales
Equipo de prueba de recuperacin
Equipo de entrenamiento
Como se puede apreciar en el plan se formulan los puntos necesarios para la continuidad y la recuperacin.
d) Pruebas y Actualizacin
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 elctrico al centro de Datos.
Los resultados de las pruebas deben ser documentadas, y las mejoras detectadas deben ser incorporadas al plan. Es
una buena prctica que al menos 2 veces al ao 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 organizacin
Desarrollo o adquisicin de nuevos recursos /aplicaciones
Cambios en la estrategia del negocio pueden alterar la importancia de las aplicaciones crticas o considerar
como criticas aplicaciones adicionales.
Los cambios en el software o ambiente de hardware
No sirve de nada embarcarnos en la formulacin del Plan para que cuando suceda el desastre nos demos con la
sorpresa que esta desactualizado y no nos ayuda en la recuperacin
3 AUDITORIA A LA CONTINUIDAD DE NEGOCIO
3.1 La Auditoria
ISACA recomienda que para auditar la Continuidad de Negocio y Recuperacin de Desastres, se debe verificar:
Entender y evaluar la estrategia de continuidad de negocios y su conexin a los objetivos de la Compaa
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
Revisin de los recursos informticos incluidos en el plan
Determinar si todas las aplicaciones crticas han sido identificadas
Revisin 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 ejecucin del BCP
Evaluar los procedimientos de actualizacin
Evaluar los planes y si estos estn escritos de manera sencilla y si son fciles de entender
Pruebas del plan
Verificar que el plan este mantenido
3.2 Situaciones que podra originar riesgos.
a) Continuidad de Negocio.
No existencia de una estrategia de Continuidad de Negocio
Existencia de Plan de Recuperacin de Desastres pero no del Plan de Continuidad de Operaciones.
b) Anlisis de Impacto
No determinacin de procesos crticos
No determinacin de los recursos informticos crticos que soportan los procesos crticos
Definicin incorrecta de las mtricas: RPO y RTO

c) Estrategia de recuperacin
Seleccin 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 recuperacin
e) Pruebas y Actualizacin
Falta de realizacin de pruebas
Pruebas realizadas pero mejoras no incluidas en el Plan
Diagrama Objetivos
Plan desactualizado
Inicio

de contenidos
LECTURA SELECCIONADA N. 2
seleccionadas
Leer artculo: Lecciones aprendidas para la recuperacin de desastres tras el 9/11.
Mearian, L. (2011). Lecciones aprendidas para la recuperacin de desastres tras el 9/11 [Sitio Web]. Disponible en:
http://www.pcworld.com.mx/Articulos/18319.html,
ACTIVIDAD N. 2
de contenidos
Participa en el Foro de discusin sobre las Prcticas gerenciales en el rea de Sistemas.

seleccionadas
INSTRUCCIONES
Revisa las prcticas gerenciales del rea de Sistemas expuestas en el tema 1.

Formula un ensayo sobre si est de acuerdo o no con las prcticas gerenciales mencionadas. Asimismo, plantea nuevas
prcticas
Diagrama gerenciales
Objetivos Inicio que a su juicio deben ser revisadas por un Auditor de Sistemas.

de contenidos
TAREA ACADEMICA N. 1
seleccionadas
Esta actividad puede consultarla en su Aula virtual.

Diagrama

Objetivos
UNIDAD
Inicio
II: Auditoria al Gobierno y Gestin de TI MANUAL AUTOFORMATIVO 69

de contenidos
GLOSARIO DE LA UNIDAD II
seleccionadas
BCP. Acrnimo de Business Continuity Plan. Proceso de la Compaia que se formula para estar preparado ante la
ocurrencia de un desastre que pueda afectar prolongada y adversamente los objetivos de una compaia.
BIA. Acrnimo de Business Impact Analysis. Es una fase del proceso de Continuidad de Negocio en donde se identifi-
can los procesos crticos de negocio y se definen las mtricas de recuperacin.
Centro de Datos. Tambin conocido como Data Center. Anteriormente conocido como Centro de Cmputo. Es la
ubicacin fsica donde residen la Infraestructura tecnolgica como Servidores, dispositivos de red, equipos de comu-
nicacin que soportan los procesos de una compaa.
Comit de Sistemas. Comit conformado por los Gerentes de Alto Nivel de una Compaa que se encargan de dar
seguimiento al alineamiento de TI con los objetivos de la Compaa.
DRP. Acronimo de Disaster Recovery Plan. Es el Plan seguido por el rea de TI despus de un desastre, para recuperar
los recursos informticos crticos.
PEE. Acronimo de Plan Estratgico Empresarial. Es el Plan en donde una compaa define su visin, misin, objetivos
y estrategias de negocio.
PETI. Acronimo de Plan Estratgico de Tecnologas de Informacin. Es el plan que el rea de TI sigue donde define
su visin, misin, objetivos y estrategias, para apoyar en el cumplimiento del PEE.
Proceso crtico. Proceso de la compaa que no debe parar ya que de hacerlo afectara adversamente los objetivos de
la Compaa.
RTO. Acronimo de Recovery Time Objective. Es el tiempo improductivo aceptable en el caso de una interrupcin de
las operaciones.
RPO. Acronimo de Recovery Point Objective. El RPO es la prdida aceptable de datos en el caso de una interrupcin
de las operaciones
Objetivos Stand-Alone.
Inicio Equipo informtico (PC o laptop) que no cuenta con acceso a la red, funcionando de manera individual.
os
BIBLIOGRAFA DE LA UNIDAD II
s
o Anotaciones Chat
Objetivos Inicio
AUTOEVALUACIN DE LA UNIDAD II
s
1. Ud. esta auditando la gestin de proyectos de un rea de Sistemas e identifica que la lista de espera de proyectos
es mayor a 6 meses. Esto origina conflictos entre las distintas reas para lograr que Sistemas priorice sus proyectos
s
Glosario Cul es el mecanismo ms eficaz que Ud. recomendara como auditor para atender y priorizar las distintas nece-
Bibliografa
sidades de las reas usuarias?
A) Gestin de Proyectos
o Anotaciones Chat
B) Plan Estratgico
C) Comit de Sistemas
D) Evaluacin de desempeo
2. Ud. esta auditando los temas relacionados a la gestin del personal de un rea de sistemas de una empresa pblica
y encuentra que los gerentes de las reas de desarrollo, mantenimiento y soporte tcnico, 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 Informacin
D) Denuncias por malos manejos
3. Cul de las siguientes no es necesariamente una ventaja de la tercerizacin?
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 aplicacio-
nes e interacta directamente con los usuarios de las diversas aplicaciones. Para dar soporte oportuno, se realiza
diariamente una copia de la BD de produccin a la BD de soporte. Cul es el principal riesgo de esta situacin?
A) Falla del Sistema de Informacin
B) Fuga de Informacin
C) Modificacin de registros en la Base de Datos
D) Eliminacin de registros de la Base de Datos

5. Ud. encuentra que todos los gastos de tecnologa son cargados al Centro de Costos del rea de Sistemas. Esta situa-
cin coloca al rea de sistemas como el rea que ms gasta de la empresa Cul de las siguientes recomendara un
Auditor para una eficaz gestin financiera de IT?
A) Reducir los costos de hardware y software
B) Trasladar los gastos relacionados al uso de tecnologa a las reas usuarias
C) Realizar mltiples versiones de presupuestos
D) Comprar un software con mantenimiento a 3 aos para lograr economa de escala
6. Ud. est realizando una auditoria a la planeacin del rea de sistemas. En ese sentido, Ud. solicita al Gerente de
Sistemas una copia del Plan Estratgico de Tecnologa de Informacin (PETI). La principal preocupacin del au-
ditor 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 anlisis FODA
E) Orientarse a soportar el aumento de las ventas de la empresa
7. Cul de las siguientes afirmaciones es verdad en relacin al Recovery Time Objective (RTO) y el Recovery Point
Objective (RPO)?
A) EL RPO y el RTO mientras ms pequeos es ms caro.
B) EL RPO y el RTO mientras ms pequeos es ms 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 seleccin de la estrategia de recuperacin. Cul de los siguientes sera el
criterio principal para la determinacin de una estrategia de recuperacin?
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 documentacin del Plan de Continuidad de Negocio de la compaa minera AntraxMina.
Cul de las siguientes no sera un documento a considerar en la revisin:
A) Disaster Recovery Plan (DRP)
B) Polticas de Seguridad
72
C) Business Impact Analysis (BIA)
D) Plan de Continuidad de Operaciones (PCO)
10. En el contexto de la continuidad de negocio, Cul de los siguientes no es considerado un desastre?
A) Un terremoto
B) Desastres naturales como por ejemplo el fenmeno del nio
C) Infeccin de un spyware
D) Error del administrador como por ejm. el borrado de una BBDD crtica.
UNIDAD III: Auditora al Ciclo de Vida de desarrollo de Software MANUAL AUTOFORMATIVO 73
UNIDAD III: AUDITORA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE

de contenidos
DIAGRAMA DE PRESENTACIN DE LA UNIDAD III

Diagrama

Desarrollo
Chat
de contenidos
seleccionadas

5 Videoclase (Video conferencia) 1. Identifica los riesgos de cada una de las 1. Valora la importancia de la ejecucin de
Tema N. 1: Etapas del ciclo de vida de Desa- fases del ciclo de vida de desarrollo de la auditoria de sistemas.
rrollo de Software sistemas. 2. Se auto valora por su aprendizaje de las
1. Etapas del ciclo de vida 2. Identifica las metodologas y prcticas de tcnicas de auditoria de sistemas.
pruebas relacionadas con el desarrollo de 3. Asume el compro-miso de revisar los
2. Controles de entrada, procesamiento y sistemas de informacin.
salida en el Software contenidos del manual.
3. Identifica los procedimientos de cambios 4. Valora la importancia de la auditoria de
en los sistemas sistemas para el mejora-miento de una
Tema N. 2: Mantenimiento de Sistemas 4. Aplica los controles en el software. empresa y para las actividades o procesos
1. Procedimiento de control de cambios a realizar.
Actividad N. 3 5. Participa activamente en el desarrollo de
Lectura seleccionada 1: las actividades de la asignatura.
Participan en el Foro de discusin sobre las
Ttulo: Ciclo de Vida del Software. disponi- riesgos en el desarrollo de software.
ble en: http://static.ccm2.net/es.ccm.net/
contents/pdf/ciclo-de-vida-del-software-223-
k8u3gm.pdf
6 Videoclase 1. Identifica los principales componentes de

Tema N. 3: Aplicaciones de Negocio las Aplicaciones de Negocio
1. Medicin, anlisis y mejora 2. Identifica los riesgos de las Aplicaciones
2. Seguimiento y medicin 3. Formula hallazgos de auditoria de Siste-
mas sobre el ciclo de vida y el manteni-
3. Control del producto No conforme miento de sistemas.
4. Anlisis de datos. Mejora
Control de Lectura N 2
Tema N. 4: Auditoria al ciclo de vida Evaluacin escrita de los temas N. 1,2,3, y 4 ,
1. Auditora a ciclo de vida de desarrollo ms los contenidos de las lecturas selecciona-
2. Auditora al mantenimiento de Sistemas das 1 y 2 de la Unidad III.
Lectura seleccionada 2:
Ttulo: Qu es big data?. Disponible en:
https://www.ibm.com/developerworks/ssa/
local/im/que-es-big-data/
Autoevaluacin N 3
En este tema abordaremos el amplio mundo del desarrollo del softwar
compaas
74 gastan cientos de miles UNIDADde III:
dlares en delos
Auditora al Ciclo procesos
Vida de de desarro
desarrollo de Software
software y es conocido que todo desarrollo de software conlleva riesgo
cuales deben ser revisados adecuadamente por los Auditores de Sist
Tambin abordaremos
TEMA N. elDEmantenimiento
1: ETAPAS DEL CICLO VIDA de Sistemas y los procedimientos q
Auditores toman en cuenta para asegurar que los cambios al software ex
no introduzcan nuevos riesgos a las compaas.
INTRODUCCIN
1. Ciclo de Vida de Desarrollo de Software

En este tema abordaremos el amplio mundo del desarrollo del software. Las compaas gastan cientos de miles de
dlares 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. Tambin abordaremos el mantenimiento de
1.1 Etapas
no introduzcan nuevosdel
riesgosCiclo de Vida Tradicional
Sistemas y los procedimientos que los Auditores toman en cuenta para asegurar que los cambios al software existente
a las compaas.
Muchas compaas utilizan el Ciclo de Vida tradicional para el de

1 CICLO DE VIDA DE DESARROLLO DE SOFTWARE
del software. Este ciclo de vida ha sido utilizado durante muchos
1.1 Etapases muy
del Ciclo probable
de Vida Tradicional que un Auditor de Sistemas se tope con este
vida. utilizan
Muchas compaas El Ciclo de
el Ciclo Vida
de Vida tradicional
tradicional consta
para el desarrollo de Este
del software. fases secuenciales,
ciclo de vida ha sido utiliza- tal
muestra en la figura 1.
do durante muchos aos 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 genricas del Ciclo de Vida de Desarrollo de Software.
Figura
Como se puede 1enla Etapas
apreciar genricas
figura 1, el Ciclo de Vida consideradel Ciclo
actividades de Vida
de adquisicin de Desarrollo
de software. Ud. podra
Software.
preguntarse qu hace la adquisicin en un ciclo de vida de desarrollo. Esto es lgico ya que mucho del software ya se
encuentra escrito y podra ser muy ventajoso adquirir software en lugar de construirlo.
Como se puede apreciar en la figura 1, el Ciclo de Vida co

actividades de adquisicin de software. Ud. podra pregunta
A continuacin, 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 estn relaciona-
dos a dinero e incluyen ahorro de costos, incremento de las ventas, reduccin 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 cunto costara
y cunto tiempo podra tomar implementar la solucin. Una buena prctica seria formular un Request for Infor-
mation (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 cunto tiempo y dinero
costara.
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 podra 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 decisin de que alternativa seguir. Recuerde que tomar una deci-
sin es seleccionar una alternativa entre varias alternativas posibles.
Determinar si es necesario desarrollar o adquirir
1.3 Requerimientos
El anlisis de requerimientos es la etapa ms importante del ciclo de vida (Alguien dijo curso de Ingeniera de Re-
querimientos). 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 reque-
rimientos de los usuarios, por lo que es vital la participacin de los usuarios.
En esta etapa se realizan las siguientes actividades:
Detallar el problema o necesidad que requiere solucin.
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 estn completos, consistentes, probables y rastreables.
Determinar si se va a desarrollar el sistema o adquirir un sistema ya existente.

76 UNIDAD III: Auditora al Ciclo de Vida de desarrollo de Software
1.4 Diseo
En caso de que se decida desarrollar, entonces la siguiente fase ser la de diseo. La fase de diseo solo puede hacerse
despus de que se tenga definidos claramente los requerimientos.
En esta fase es muy comn utilizar algn lenguaje de modelado de software tal como el Unified Modeling Language
(UML) para disear, 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 diseo es equivalente a realizar un plano en la construccin de un edificio. El plano indica cmo ser el
edificio. De manera similar en la fase de diseo 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 Adquisicin del Software
En caso de que se decida no desarrollar, entonces la siguiente fase despus de la fase de Requerimientos es la fase de
Adquisicin del software. Al igual que la fase de Diseo, la adquisicin de software solo puede ocurrir despus de cerrar
la fase de requerimientos, ya que no podemos adquirir un software sin saber lo que necesitamos.
En esta etapa bsicamente 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
tcnicos, 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 ms conveniente. Es comn que las propuestas sean evalua-
das en funcin a su peso tcnico y econmico. Por ejemplo la evaluacin tcnica puede pesar 70-80% y la evaluacin
econmica 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 continuacin de la fase de Diseo. Con los documentos de especificaciones de diseo, se realiza la co-
dificacin utilizando diversos mtodos, tcnicas y lenguajes de programacin. Es muy comn que los desarrolladores
utilicen ambientes integrados de desarrollo integrado (IDE) que facilitan la programacin del cdigo fuente.
En esta etapa se debe considerar las pruebas que garanticen la calidad del software construido. No se puede conceptua-
lizar 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: Cunto tiempo se le debe dedicar a las pruebas? Cul es la relacin
optima de tiempo entre el desarrollo y las pruebas? Por ejemplo si tomo 1 mes para codificar, Cunto tiempo se debe
estimar para las pruebas? Muchas compaas le dedican el 20% a la codificacin y el 80% del tiempo a las pruebas. Eso
significa que si se estima un mes para la codificacin, se debera tener 4 meses de codificacin. Ahora le pregunto Ud.
considera que esta bien la relacin 20%80% Est un poco exagerada? Ser esta la prctica de los desarrollos de
software en el pas? Lo cierto es cada equipo de desarrollo tiene sus propios estndares. 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.
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 integracin. Esta prueba verifica que la informacin fluya 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 recuperacin. Verifican que el software funcione adecuadamente despus de una falla de hardware o
software.
Pruebas de seguridad. Verifican la seguridad de un software.
Pruebas de estrs/volumen. Verifican la performance de un software con grandes volmenes de datos.
Pruebas de volumen. Determina el nmero mximo de transacciones que un software puede procesar.
Pruebas de Stress. Determina el nmero mximo 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 aceptacin final User Acceptance Test(UAT). Esta prueba se da en la fase de implementacin, 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 podra 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 especfica de un sistema.
Caja blanca. Evala la efectividad del cdigo fuente de un sistema.
Caja negra. Evala la efectividad funcional de un sistema.
Funcin/validacin.
Evala la funcionalidad de un sistema contra los requerimientos para verificar que se est
construyendo e software de acuerdo a los requerimientos.
Regresin.
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 verificar que un cambio en un software no afecta a otros sistemas. Es decir
que el sistema es amigo de los dems 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 docu-
mentar los resultados de las pruebas. Los errores y fallas deben ser incorporados en el desarrollo.
1.7 Configuracin
La fase de Configuracin es la fase que continua despus de la adquisicin del software (en caso que se decidi ad-
quirir un software). En esta etapa se adecua el software para que funcione segn los requerimientos de la Compaa.
Normalmente esto se basa en cambiar los parmetros del software evitando as tener que hacer cambios en el cdigo
fuente del sistema a adquirir. Para ello el software a adquirir debera ser lo suficientemente flexible para permitir con-
figurar y personalizar el software.
En esta fase, cabe la pena preguntarse: Hay que adecuar el software a la compaa o adecuar la compaa al softwa-
re? En lneas generales esta pregunta genera muchas y acaloradas discusiones. En mi opinin cuando se adquiere un
software, este software ya fue implementado decenas, cientos o incluso miles de veces en compaas anteriores, por
lo que el software trae muchas buenas prcticas. No siempre la forma como opera una compaa es la mejor y hacer
que el software se adecue a la compaa podra generar automatizacin de procesos no optimizados, por lo que de
preferencia la compaa debera adecuarse al software. De esa manera el software se utilizara en su versin estndar y
fortalecera el soporte del fabricante del software.
Asimismo, es una prctica normal de las compaas construir interfaces entre el software adquirido con los software
existentes.
1.8 Implementacin
En la fase de implementacin se establece y la operacin efectiva del nuevo sistema. Antes de la implementacin, el
usuario ha aceptado la funcionalidad del sistema a travs de la prueba de aceptacin del usuario final (UAT).
1.9 Revisin Post-Implementacin
Normalmente los proyectos de desarrollo de sistemas de informacin culminan en la fase de Implementacin. Sin em-
bargo es vital que se considere la fase de Revisin de Post-Implementacin. Esta revisin es una oportunidad no apro-
vechada por el rea de T.I. para demostrar los beneficios que el Software brinda a la Alta Direccin de la Compaa.
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 ms presentemos los resultados logrados, ms fcil
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/beneficios o el Retorno sobre Inversin (ROI) proyectados.
Elaborar recomendaciones de los aspectos inadecuados que se dieron en el proyecto de desarrollo.
Obtener las lecciones aprendidas que sern 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 compo-
nen de tareas pequeas etapas repetitivas. Ejemplo de procesos iterativos lo constituyen el desarrollo evolucionario,
el desarrollo en espiral y el desarrollo gil. De estos 3, el proceso ms popular es el desarrollo gil con 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 incorrec-
tos, que los procesos sean exactos y proteger los reportes emitidos por el Sistema.
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 validacin. ISACA recomienda que se consideren los siguientes controles para validar los datos:
Tabla 3
Lista de controles de validacin de entrada de datos.
NO. PARMETRO DESCRIPCIN
1. Verificacin de limite Un dato no debe ser menor a, o mayor a un determinado valor. Ea decir debe estar
dentro de un lmite. Por ejemplo el monto total de una factura de una compaa que
vende autos no puede ser menor que USD 7,000.
2. Verificacin 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 aos.
3. Verificacin de validez Verificacin 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. Verificacin de razonabilidad El dato es comparado para determinar lmites razonables o tasas de ocurrencia prede-
terminadas. Por ejm. La edad de una persona no puede ser mayor a 100 aos.
5. Verificacin de coincidencia Los datos ingresados deben coincidir con valores almacenados en una tabla. Por ejm.
cdigos Postales
6. Dgito de control Un valor numrico calculado por un algoritmo y que permite asegurar la integridad
de un dato. Este control es efectivo para detectar la transposicin de los caracteres
de un campo. Por ejm. La verificacin del RUC debe ser realizada con el algoritmo
Modulo 11 modificado (El ejemplo aplica para Per).
7. Verificacin de obligatoriedad Un campo debe contener datos vlidos, segn el tipo de campo que se est ingresan-
do.
8. Verificacin de datos duplicados Una transaccin 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 estn orientados a garantizar que los clculos 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 verificacin del clculo de un algoritmo, usando otro me-
canismo de clculo para verificar el resultado. Por ejemplo verificando que el resultado de un clculo con una com-
probacin a travs 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:

SELECT SUM (valor) from tabla where elemento < = 10
Existen muchas formas de verificar los clculos dentro de un Sistema de Informacin. Por ejemplo:
Rutinas de recalculo despus de que los clculos han sido ejecutados
Comprobar los totales cada vez que se inicia una nueva rutina.
Controles programados para detectar inconsistencias.
Verificaciones de lmite o rango, similares a los controles que vimos en la entrada de datos.
2.3. Controles de Salida
Los controles de Salida estn orientados a proveer que los datos entregados a los usuarios sern presentados, formatea-
dos y entregados en una forma consistente y segura.
Los controles de salida a implementar en un Sistema de informacin incluyen:
Generacin 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 Crdito completa. Podra 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 ningn re-
porte se pierda. Por ejemplo controlar las numeraciones de la facturas.
Tambin se deben seguir controles de salida fsicos. Todos los controles en un Sistema Informtico se pueden venir
abajo si es que al imprimirse un reporte con informacin sensible no se toman las medidas fsicas necesarias para
proteger la informacin impresa. Entre las medidas fsicas a considerar tenemos por ejemplo:
Registro y Almacenamiento de Formularios Negociables, Sensitivos y Crticos en un Lugar Seguro. Este control
evitara la sustraccin o robo de reportes que contengan valores.
Distribucin de Reportes. Los reportes crticos deben ser distribuidos de manera segura. Por ejemplo si es un estado
de cuenta, debe ensobrarse. Ahora existen maquinas que imprimen y ensobran automticamente.
Retencin de Reportes. Los reportes con informacin sensible que pierdan su vigencia deben ser destruidos. La
destruccin debe considerar las leyes y regulaciones sobre retencin de documentos que pudiesen existir.
Verificacin 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 informacin.
Un error muy comn 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 informacin.
TEMA N. 2: MANTENIMIENTO DE SISTEMAS
INTRODUCCIN
Una vez que un Sistema de Informacin est funcionando (en produccin), 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 Informacin. Sin embargo, tambin se pueden dar cambios para corregir funcionalidades defectuosas del
Sistema de Informacin. Desde el punto de vista de Auditoria, los cambios no deben introducir nuevos riesgos.
1 MANTENIMIENTO DE SISTEMAS
Las estadsticas indican que el Mantenimiento de Sistemas representa aproximadamente el 80% del ciclo de la vida
til de un Sistema de Informacin. Esto significa que los costos y tiempo consumidos en el proceso de ciclo de vida de
desarrollo del Sistema de Informacin representa solamente el 20%.
Los fabricantes de software saben que el negocio est en el mantenimiento de software ms que en el desarrollo de sof-
tware. Cuando un sistema de informacin 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 Informacin, ste podra afectar adversamente el funcionamiento de un
Sistema. Es por ello que cualquier cambio debe ser minuciosamente analizado a travs de un proceso de control de
Cambios.
El Control de Cambios es uno de los procesos de ITIL (Information technology Infrastructure Library). Bsicamente
este proceso trata de que un cambio pase por un proceso de autorizacin y revisin antes de su implementacin para
verificar que el cambio no introduce riesgos ni impactos no deseados.
En una compaa 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 podra agregar
nuevos segmentos de red, o cambios en las redes o routers; la gente de Base de Datos podra modificar objetos dentro
de una Base de Datos, la gente de Servidores realizar cambios en la configuracin de uno o ms servidores. Como se
podr intuir, un cambio en un componente podra afectar a otros componentes de la Infraestructura e impactar adver-
samente 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 produccin.
A continuacin presentaremos un conjunto de pasos a seguir (se asume que se trata de una empresa grande)
a) El usuario solicita un cambio a travs de una solicitud de cambio (En ingls Request for Change RFC).
b) El lder del rea evala la necesidad del cambio.
c) El lder 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 especificacin en base a la solicitud de cambio.

h) El programador escribe los cambios en el cdigo fuente.

i) El Analista de Calidad de Software evala 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 funcin al tamao de la compaa, a la formalidad de los procesos
de la compaa, a la cantidad de personas que laboran en el rea de Sistemas, a la segregacin de funciones del rea,
entre otros.
3 IMPLANTACIN 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 produccin. El usuario obtiene por fin su cambio!
4 DOCUMENTACIN
Para asegurar el mantenimiento futuro del sistema, toda documentacin relevante debe ser actualizada. Un error muy
comn es que los cambios no son acompaados de la correspondiente documentacin. Debido a que los cambios en
un sistema se necesitan para ayer, es comn sacrificar la documentacin. El mantener un sistema sin la documenta-
cin actualizada introduce riesgos de que los cambios se demoren un mayor tiempo, ya que el programador necesita
entender el cdigo fuente.
5 CAMBIOS DE EMERGENCIA.
Imagine una situacin donde un Sistema de Informacin falle y se necesite corregir este error inmediatamente. En
este caso, sera 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 situacin 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 produccin de manera controlada. Muchas compaas por
ejemplo disponen de unos sobres cerrados y lacrados, los cuales solamente sern abiertos cuando se tenga un caso de
emergencia. Dentro de los sobres se tienen usuarios y contraseas, las cuales podrn ser utilizadas por un programador
para corregir una situacin en un programa o en una Base de Datos. Evidentemente estos usuarios y contraseas 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 situacin de emergencia.
6 RAZONES POR LAS QUE SUCEDEN LOS CAMBIOS NO AUTORIZADOS
Un cambio no autorizado a un sistema de informacin puede originarse por varias razones:
El programador tiene acceso a las carpetas de produccin que contiene los programas, incluyendo el cdigo fuente
y el cdigo objeto.
El usuario responsable de la aplicacin no estaba al tanto del cambio (el usuario no firm la solicitud de cambio
(RFC)
No existe un procedimiento formal.
El Gerente que deba autorizar no firm la solicitud de cambio aprobando el inicio de los trabajos.
El usuario solicitante no firm el formulario de aceptacin de cambio (UAT).
El cdigo fuente modificado no fue revisado adecuadamente.
El programador puso un cdigo extra para beneficio personal (es decir, cometi fraude).

Diagrama
UNIDAD
Objetivos
III:Inicio
Auditora al Ciclo de Vida de desarrollo de Software MANUAL AUTOFORMATIVO 83

de contenidos
seleccionadas
Leer el artculo: Ciclo de Vida del Software.
Kioskea.net (2014). Ciclo de Vida del Software. [Sitio Web]. Disponible en: http://static.ccm2.net/es.ccm.net/con-
tents/pdf/ciclo-de-vida-del-software-223-k8u3gm.pdf
ACTIVIDAD N. 3
de contenidos
Participan en el Foro de discusin sobre los Riesgos de desarrollo de software.

seleccionadas
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 discusin sobre los riesgos de desarrollo de software.

TEMA N. 3: APLICACIONES DE NEGOCIO
INTRODUCCIN
Este tema est enfocado en analizar algunas Aplicaciones de Negocio verticales comunes que comnmente son revisa-
das por los Auditores de Sistemas; as como el Big Data que se convertir sin ninguna duda en el modelo de sistemas
de informacin 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 ms bien
son utilizadas por una industria especifica o para un solo propsito. A continuacin revisaremos algunas de las aplica-
ciones de negocio verticales ms utilizadas.
1.1 Comercio Electrnico (E-Commerce)
El E-Commerce se refiere a la venta y compra de productos o servicios a travs 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 ms populares tenemos:
Business-To-Consumer (B2C). En este modelo la compaa que vende se relaciona directamente con miles o inclu-
so millones clientes. El lder de este sector es www.amazon.com quien reinventa este sector con cientos de innova-
ciones.
Business-To-Business (B2B). En este modelo las compaas 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 compaa pone a disposicin de sus empleados realizar transacciones directas como
por ejemplo solicitar un prstamo, 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 compaas realizar trmites y pagar directamente los
impuestos ante el Gobierno.
Como se puede apreciar, el comercio electrnico tiene muchas ventajas. Sin embargo tambin hay que considerar los
riesgos del comercio electrnico, entre los que tenemos:
Confidencialidad. Para poder realizar transacciones electrnicas, los clientes deben suministrar informacin perso-
nal que podra incluir tarjetas de crdito que de perderse podran afectar a los clientes y ser vctimas de fraude. De
hecho este riesgo ha sucedido varias veces. Basta buscar en Internet los ataques a la compaa Target. Puede ver un
pequeo video en: https://www.youtube.com/watch?v=lqu_Bx4Uf5w
Integridad. Alguna vez le ha pasado o ha escuchado que se est procesando una transaccin electrnica y no termi-
na y el sistema se cuelga, con lo que el usuario no sabe si la transaccin termin o debe volver a hacerla. Si vuelve
a realizarla, se podra comprar doble. Por otro lado, que sucede si los criminales informticos 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 compaa de comercio electrnico es estar fuera de lnea, es
decir no estar disponible. Esto aparte de hacer perder dinero a la compaa, podra espantar a los clientes y hacerles
perder la confianza en el sitio.
Traslado del poder a los clientes. Este es el riesgo ms importante de un sitio de comercio electrnico. Los clientes
estn cada vez ms 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 Electrnico de Datos es un estndar en la cual los sistemas de informacin de diferentes empresas con-
versan directamente entre ellos, sin necesidad de intervencin humana.
Imagine la siguiente situacin: Trabajamos en un gran supermercado, el cual tiene cientos (o incluso miles) de pro-
veedores. La tarea de emitir rdenes de Compra para comprar a los proveedores los diversos productos a medida que
se van agotando de los stocks de las diversas tiendas requerir de un ejrcito de gente en el rea de Compras. Por cada
proveedor, tenemos que emitir una Orden de Compra y debemos registrar los artculos y las cantidades a comprar en
la Orden y luego emitir la orden. Una vez emitida la Orden habr que enviarla por correo electrnico al proveedor.
El proveedor una vez recibida la Orden, ingresara los datos de la Orden de Compra en su Sistema de Ventas y en fun-
cin a ello, emitir una factura y una gua de remisin para que despachen los productos que estamos adquiriendo.
En el proceso descrito existen dos compaas (el supermercado y el proveedor) en el cual ambos cuenta con sistemas
de informacin pero la transferencia de datos es a travs de correo electrnico.
Entonces, no sera mejor que los sistemas conversasen? Es aqu donde entra EDI. EDI es un estndar que permite a
sistemas comunicarse entre s. Para que dos sistemas se comuniquen entre si se necesita que hablen un mismo proto-
colo de comunicacin. Eso es precisamente EDI.
Entre los beneficios de implementar EDI se tiene:
Menos papeleo
Menos errores durante el intercambio de informacin
Mejor flujo de informacin, de base de datos a base de datos y de compaa a compaa
No se necesita introducir los datos en la manera repetitiva
Menos demoras en la comunicacin
Mejores procesos de facturacin y de pago
Evidentemente, la naturaleza crtica de muchas transacciones (rdenes de Compra, facturas y pagos), requiere protec-
cin de las transmisiones. Por ello, los sistemas EDI cuentan con mecanismos de proteccin, tales como:
Normas para indicar que el formato y el contenido del mensaje son vlidos
Controles para asegurar que la aplicacin de traduccin convierte correctamente las transmisiones estndar para
el software de aplicacin
Procedimientos para determinar que los mensajes son solamente de partes autorizadas
Canales de transmisin directos o dedicados entre las partes
Los datos deben estar encriptados usando algoritmos acordados por las partes involucradas
Registro en un log de cada transaccin 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.
1.3 Sistemas de Punto de VentaPoint 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 travs de los Sistemas de Punto de Venta (POS) que permiten a diversas
compaas, aceptar pagos electrnicos por ventas en tiempo real. A travs de los sistemas POS los clientes pueden pa-
gar sus compras a travs del uso de tarjetas de crdito y de dbito en 24x7. Los POS pueden estar conectados a lectores
magnticos, lectores de chip, cdigos de barra, entre otros.
Desde el punto de vista de riesgo, es importante identificar y analizar cmo estos sistemas guardan la informacin que
procesan, tales como el nmero de la tarjeta, y la informacin personal de los tarjetahabientes; as como las medidas
de seguridad en la transmisin de la informacin.
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, Fi-
nanciera Uno, entre otros.
1.4 Sistemas de Dinero Electrnico.
El objetivo de los sistemas de dinero electrnico es emular el dinero en efectivo. Un emisor hace esto mediante la
creacin 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 electrnico son:
Se ahorra tiempo y dinero ya que se puede realizar todas las operaciones de dinero electrnico en cualquier mo-
mento y en cualquier lugar.
No se necesita usar billetes ni monedas, tarjeta de crdito y/o dbito.
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
electrnico en lugar de cargar efectivo para mandar y recibir plata, a travs del uso de cualquier celular. Puedes obte-
ner ms informacin en www.mibim.pe
1.5 Big data
Uno de las Aplicaciones que ms van a impactar a las compaas en el futuro cercano es el Big Data.
Es sabido que una persona promedio el da de hoy genera ms datos en un solo da, que una persona en el siglo XIV
en toda su vida.
Esta explosin de informacin, llevndolo al contexto de las empresas es ms evidente que nunca. Las compaas gene-
ran terabytes (e incluso petabytes) de informacin cada ao y no necesariamente se aprovecha toda esa informacin.
Si las compaas pudiesen aprovechar la cuantiosa informacin que poseen, estaran en posicin de tomar mejores
decisiones de negocio.
Anteriormente, la toma de decisiones se hacan sobre los sistemas de Business Intelligence, pero que tenan el proble-
ma de que demoraban mucho en cargar la data proveniente de los sistemas transaccionales. Con el pasar del tiempo,
aparecieron los sistemas de computacin 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 informacin.
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 rpida forma de profundizar los conocimientos de Big Data.
Otra fuente de informacin que recomiendo, la puede encontrar en el sitioThe human face of big data. http://
humanfaceofbigdata.com .
Este sitio (del mismo nombre del famoso libro de big data) contiene excelentes videos y ejemplos de la inmensa can-
tidad de datos al que nos enfrentamos.
Asimismo un ejemplo prctico del big data lo puede encontrar en: https://www.youtube.com/watch?v=d9NJt4DBb-I
TEMA N. 4: AUDITORIA AL CICLO DE VIDA
INTRODUCCIN
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 Informacin.
1 AUDITORIA AL CICLO DE VIDA
1.1 Tareas del Auditor.
En lneas generales, el Auditor de Sistemas debe efectuar las siguientes tares:
Identificar los componentes significativos o importantes en la aplicacin y el flujo de las transacciones a travs del
sistema.
Identificar las fortalezas de control de la aplicacin y evaluar el impacto de las debilidades de control para desarro-
llar una estrategia de prueba, mediante el anlisis de la informacin acumulada.
Probar los controles para asegurar su funcionalidad y su eficacia.
1.2 Documentacin a solicitar.
Documentos de la metodologa de ciclo de vida. Esto dar un entendimiento al Auditor de la robustez de los pro-
cesos de construccin de desarrollo de software.
Documentos de requerimientos. Esto permitir entender cules fueron los requerimientos
Especificaciones de diseo funcional. Revisando este documento se tiene el conocimiento de la Aplicacin.
Request for Change (RFC). Este documento permitir conocer que cambios se realizaron y si estos contaron con
la autorizacin respectiva y debera poder cruzarse el documento de cambio con los cambios en el cdigo fuente.
Manuales de usuario. Con este documento se entiende como el usuario utiliza la aplicacin. Es muy comn que
este documento este desactualizado.
1.3 Situaciones que podra originar riesgos en el Ciclo de Vida de Desarrollo de Software.
b) Estudio de factibilidad.
Costos y beneficios no verificables.
Falta de razonabilidad en la solucin propuesta.
No existencia de estudios de factibilidad.
Falta de Business Case
Falta de aprobacin para el proyecto
c) Requerimientos.
Existencia de requerimientos incompletos.

Existencia de requerimientos muy genricos.
Falta de identificacin de los interesados y sus requerimientos.
Falta de requerimientos no funcionales
d) Diseo
Falta de utilizacin 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) Adquisicin 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 correccin de los resultados de las pruebas.
g) Configuracin
Falta de documentacin en la configuracin.
No adecuacin de los procesos de la compaa a las mejores prcticas del software.
Automatizacin de procesos inconsistentes.
Falta de control de las interfaces con las aplicaciones existentes.
h) Implementacin
Falta de la aceptacin del usuario (UAT).
Falta de migracin de daros importantes para el Sistema.

Falta de medidas de regresin en caso de falla.
i) Revisin Post-Implementacin
Inexistencia de la fase Revisin de Post-Implementacin
Falta de demostracin de los beneficios que el Software brinda.
Falta de documentacin de las lecciones aprendidas.
2 AUDITORIA AL MANTENIMIENTO DE SISTEMAS
En lneas generales, el Auditor de Sistemas debe efectuar las siguientes tares:
Identificar si existe un flujo de aprobacin de cambios.
Identificar si todos los cambios estn autorizados.
2.2 Documentacin a solicitar.
Request for Change (RFC). Este documento permitir conocer que cambios se realizaron y si estos contaron con
la autorizacin respectiva y debera poder cruzarse el documento de cambio con los cambios en el cdigo fuente.
Manuales de usuario actualizados. Con este documento se verifica si los cambios se ven reflejados en la documen-
tacin.
2.3 Situaciones que podra originar riesgos en el Mantenimiento del Software.
Inexistencia de un proceso de control de cambios.
La inexistencia de un flujo de aprobaciones para los cambios.
Falta de priorizacin 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 produccin donde se encuentra los ob-
jetos fuente y ejecutables
Existencia de cambios sin documentacin.

Adems, el auditor de SI debe revisar el proceso global de gestin del cambio de la compaa, para identificar posibles
mejoras en el tiempo de respuesta y la satisfaccin de los usuarios con el proceso de cambio.
de contenidos
seleccionadas
Leer artculo: 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).

Diagrama
UNIDAD
Objetivos
III:Inicio
Auditora al Ciclo de Vida de desarrollo de Software MANUAL AUTOFORMATIVO 91

de contenidos
CONTROL DE LECTURA N 2
Diagrama ObjetivosInicio
Esta actividad
Lecturas
Glosario
seleccionadas puede
Bibliografa
consultarla en su Aula virtual.

de contenidos Recordatorio Anotaciones Chat
GLOSARIO DE LA UNIDAD III

seleccionadas
Big data: Se refiere a la disciplina de recoleccin, almacenamiento, bsqueda, comparticin, anlisis, y visualizacin de
grandes cantidades de informacin.
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 ms conveniente.
IDE: Acrnimo de Integrated Development Environment. En espaol, Entorno de Desarrollo Integrado, es un sof-
tware que facilita el desarrollo de software, contando con un editor de cdigo fuente, herramientas de construccin
automticas y un depurador. La mayora de los IDE tienen auto-completado inteligente de cdigo y algunos cuentan
con un compilador, un intrprete, o ambos.
ITIL: Acrnimo de Information technology Infrastructure Library. En espaol Biblioteca de Infraestructura de Tecno-
loga de Informacin. Es una prctica reconocida para la gestin de los servicios ofrecidos por las IT. Dentro de ITIL
se encuentra el proceso de Gestin de Cambios.
RFC: Acrnimo de Request for Change. En espaol Solicitud de Cambio, es un documento utilizado en el proceso de
Gestin de cambios, donde se documenta un cambio que es requerido.
RFI: Acrnimo de Request for Information. En espaol Solicitud de Informacin, es un documento que permite re-
coger informacin de las capacidades y caractersticas de un software de un proveedor. Normalmente se utiliza para
sondear el mercado.
RFP: Acrnimo de Request for Proposal. En espaol Solicitud de Propuesta, es un documento que solicita a los pro-
veedores que presenten sus propuestas para adquirir un determinado bien o servicio. Este documento normalmente
se solicita dentro de un proceso de licitacin. Tambin es conocido como especificaciones tcnicas.
SDLC: Acrnimo de Software Develepment Life Cycle. En espaol, Ciclo de vida de desarrollo de software, es un pro-
ceso de la Ingeniera de Software para creacin de desarrollo y/o adquisicin de software.
UAT: Acrnimo de User Aceptation Test. En espaol, prueba de aceptacin 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: Acrnimo de Unified Model Language. En espaol, Lenguaje Unificado de Modelado, es un lenguaje grafico
utilizado para visualizar, especificar, construir y documentar un sistema. UML ofrece un estndar para describir un
Objetivos plano
Inicio del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del siste-
ma, y aspectos concretos como expresiones de lenguajes de programacin, esquemas de bases de datos y reciclaje de
componentes.
os
BIBLIOGRAFA DE LA UNIDAD III

s
o Anotaciones Chat
Objetivos Inicio
AUTOEVALUACIN DE LA UNIDAD III

s
1. Ud. esta auditando los resultados de un servicio de Hacking tico a las aplicaciones de una compaa y encuentra
que el hacker fue contratado para realizar pruebas de caja blanca. Esta prueba verifica:
s
Glosario
Bibliografa
A) Los controles de validacin
B) El cdigo fuente
o Anotaciones
Chat
C) El proceso de ciclo de vida de la aplicacin
D) La aceptacin del usuario a la aplicacin
2. En cul de las siguientes fases del ciclo de vida de desarrollo de software se lleva a cabo la prueba de Aceptacin
de Usuario (UAT)?
A) Adquisicin
B) Configuracin
C) Implementacin
D) Post-Implementacin
3. Ud. esta auditando la validacin 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. Cul de las siguientes validaciones Ud.
recomendara?
A) Chequeo de razonabilidad
B) Prueba de sociabilidad
C) Validacin de llave
D) Chequeo de relaciones lgicas
4. Ud. esta auditando el proceso de mantenimiento de software y encentra que en el presente ao el principal sistema
de informacin ha tenido 18 cambios. Cul de las siguientes sera una evidencia que Ud. solicitara como parte de
la revisin?
A) Metodologa 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 In-
tercambio Electrnico de Datos basado en el estndar EDI. El Sistema de Compras se conecta con los sistemas de
informacin de los proveedores. Al respecto, cul de los siguientes NO seria su principal preocupacin?
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

6. Ud. es parte del equipo de Auditoria al sitio de comercio electrnico de la librera ms importante del mundo:
Barnes and Noble.com. Cul de los siguientes NO seria parte de la auditoria?,
A) Revisin de los mecanismos de extraccin de datos para las estadsticas del sitio
B) Revisin de los controles de los mecanismos de pago del sitio
C) Revisin de los controles de autenticacin de usuarios del sitio
D) Revisin de los controles de disponibilidad del sitio
7. Ud. esta auditando el proceso de ciclo de vida de desarrollo de software de la compaa de lcteos Glorita, y el rea
de Sistemas le informa que ha presentado al gerente Financiero, un caso de negocios (Business Case) relacionado
a la implementacin de un nuevo Sistema de Recursos Empresariales (ERP) al gerente. El rea de Sistemas presen-
to el caso de negocio al gerente Financiero para:
A) Cerrar el proyecto
B) Validar los beneficios del proyecto post cierre
C) Tomar una decisin 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 dae los software que ya se encuentran corriendo es la:
A) Prueba de caja blanca
B) Prueba de regresin
C) Prueba de caja negra
D) Prueba de sociabilidad
9. En cual fase del ciclo de vida de desarrollo de sistemas se toma la decisin de desarrollar o adquirir el software
A) Diseo
B) Adquisicin
C) Ingeniera de requerimientos
D) Estudio de Factibilidad
E) Implementacin
10. Ud. est revisando una RFP (Request For Purposal) Cul es la fase del ciclo de vida que est auditando?
A) Estudio de Factibilidad
B) Pruebas
C) Adquisicin
D) Configuracin
94
UNIDAD IV: Auditora a la seguridad de la informacin MANUAL AUTOFORMATIVO 95
UNIDAD IV: AUDITORA A LA SEGURIDAD DE LA INFORMACIN

de contenidos
DIAGRAMA DE PRESENTACIN DE LA UNIDAD IV

Diagrama

Desarrollo
Chat
de contenidos
seleccionadas

7 Videoclase (Video conferencia) 1. Identifica los riesgos relacionados a la 1. Valora la importancia de la ejecucin de
Tema N. 1: Seguridad de la informacin seguridad de la informacin la auditoria de sistemas.
1. Seguridad de la informacin 2. Identifica los riesgos relacionados a la 2. Se auto valora por su aprendizaje de las
seguridad informtica tcnicas de auditoria de sistemas.
2. Seguridad informtica
3. Participa en la redaccin de observacio- 3. Asume el compro-miso de revisar los
nes relacionadas a la Gestin de Accesos y contenidos del manual.
Tema N. 2: Controles de seguridad I Criptografa. 4. Valora la importancia de la auditoria de
1. Gestin de accesos sistemas para el mejora-miento de una
Actividad N. 4 empresa y para las actividades o procesos
2. Criptografa
a realizar.
Lectura seleccionada 1 Elabora un ensayo sobre cuando utilizar los
diversos tipos de criptografa. 5. Participa activamente en el desarrollo de
Aplicacin de la criptografa. Disponible en: las actividades de la asignatura.
https://www.icai.es/contenidos/publicacio-
nes/anales_get.php?id=1235
8 Videoclase
Tema N. 3: Controles de Seguridad II 1. Identifica los riesgos relacionados al
1. Dispositivos de Seguridad Internet Internet
2. Seguridad Cloud 2. Identifica los riesgos relacionados al
Cloud
3. Seguridad Mviles
3. Identifica los riesgos relacionados a los
dispositivos mviles
Tema N. 4: Auditora a la Seguridad de la 4. Participa en la redaccin de observa-
Informacin ciones relacionadas a la seguridad de
1. Auditora a la seguridad de la informa- la informacin, poniendo nfasis en la
cin recomendacin de controles.
2. Auditora a los controles de seguridad.
Lectura seleccionada 2: Tarea Acadmica N 2
Seguridad en dispositivos mviles: Qu Elabora un informe de auditora de controles
pautas debes seguir?. Disponible en: http:// de seguridad del caso Auditoria de una
hipertextual.com/archivo/2013/12/seguri- empresa regional.
dad-dispositivos-moviles-consejos/
Autoevaluacin de la unidad IV
96 UNIDAD IV: Auditora a la seguridad de la informacin
TEMA N. 1: SEGURIDAD DE LA INFORMACIN
INTRODUCCIN
En este tema revisaremos los conceptos fundamentales sobre la seguridad de la informacin.
1 SEGURIDAD DE LA INFORMACIN
1.1 Qu es la Seguridad de la Informacin?
En su definicin ms simple la Seguridad es la ausencia de riesgo. Esto quiere decir que la Seguridad es un estado. Hoy
puedo estar seguro y maana no estarlo; o al revs, hoy no estarlo y maana estar seguro.
La Seguridad de la Informacin es la disciplina orientada a proteger la informacin de las compaas.
La informacin de las compaas tiene valor y por ello requiere ser protegida. Esto tiene un significado relevante ya
que la informacin 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 mvil. En cualquiera de estos requiere de proteccin del intangible.
La seguridad de la Informacin tiene 3 objetivos a lograr:
a) Confidencialidad. La confidencialidad se refiere a que la informacin solamente sea accedida por las personas
autorizadas. Por ejemplo si un criminal informtico logra acceder a informacin de muestra compaa, se vera
afectada la Confidencialidad.
b) Integridad. La integridad se refiere a que la informacin permanezca completa e inalterable, es decir que se
mantenga exacta tal como fue ingresada. Si por ejemplo un malware encripta la informacin, es decir la modifica,
entonces se afecta la integridad.
c) Disponibilidad. Se refiere a que la informacin est disponible cuando la persona autorizada la requiere. Este atri-
buto de la seguridad es el ms 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 informtico.
1.2 Factores Crticos de xito
Para que una iniciativa de Seguridad de la Informacin tenga xito en una organizacin, 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 informacin de

la compaa. En ese sentido, hay que lograr el respaldo de la Gerencia antes de implementar las medidas de segu-
ridad de la informacin. Si no se cuenta con el espaldarazo de la gerencia, la iniciativa de seguridad perder fuerza
y no podr lograrse.
b) Polticas, Normas y Procedimientos. Este tema lo vimos en la Unidad II, cuando vimos el tema de las prcticas
gerenciales de IT. Se debe contar con un rbol normativo con todas las polticas, normas y procedimientos de se-
guridad de la informacin.
c) Organizacin. 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 informacin
en la compaa donde laboran.
d) Educacin. Los usuarios deben ser capacitados en los temas relevantes de Seguridad de la Informacin. Temas
como riesgos, amenazas, uso aceptable de informacin y consideraciones que deben ser tomadas, son los temas
que deben ser considerados en las capacitaciones de seguridad de la informacin. Se debe considerar capacitar a
los usuarios al menos una vez al ao.
e) Monitoreo. La ejecucin de un monitoreo continuo y en tiempo real del cumplimiento de los controles y de la
normatividad de seguridad de la informacin es una actividad vital para la seguridad de la informacin.
f) Manejo de Incidentes. Tarde o temprano van a suceder incidentes de seguridad de la informacin. Esto es una rea-
lidad a pesar de todos los controles de seguridad de la informacin que el dinero pueda comprar y se implementen
en una compaa.
El responsable de Seguridad de la Informacin es el llamado a lograr a que estos Factores Crticos de xito se cumplan.
De estos factores dependen si va a tener xito o no en su gestin.
1.3 Inventario de Activos de Informacin
Existe una mxima en Seguridad de la informacin: 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 informacin radica en contar con un inventario exhaus-
tivo de los activos de informacin. En este inventario no interesa si el activo es de propiedad de la compaa. Es decir
se deben considerar los activos de informacin que sean de propiedad de terceros y que contengan informacin de la
compaa. Si est conectado a la red, debe ser considerado en el inventario.
En un inventario de Activos de Informacin se deben considerar:
Sistemas de Informacin
Base de Datos
Media
Licencias
Interfaces
Servidores
PCs / Laptops
Disp. mviles
Perifricos
Equipos de comunicacin
Equipos de Proteccin elctrica
Contratos
Documentacin
Personal
2 SEGURIDAD INFORMTICA
2.4 La Seguridad de la Informacin y la Seguridad Informtica.
De primera impresin, la Seguridad de la Informacin podra confundirse con la Seguridad Informtica. De hecho
muchos profesionales, usan el trmino indistintamente.
Sin embargo, es preciso acotar que la Seguridad Informtica es un subconjunto de la disciplina de la Seguridad de la
Informacin.
Segn Jeimy J. Cano, la Seguridad Informtica, es la disciplina que se encargara de las implementaciones tcnicas de
la proteccin de la informacin, el despliegue de las tecnologas antivirus, firewalls, deteccin de intrusos, deteccin
de anomalas, correlacin de eventos, atencin de incidentes, entre otros elementos, quearticulados con prcticas
de gobierno de tecnologa de informacinestablecen la forma de actuar y asegurar las situaciones de fallas parciales
o totales, cuando la informacin es el activo que se encuentra en riesgo.
Entonces se puede decir que la Seguridad Informtica trabaja en una capa operativa con algunos temas tcticos para
proteger la informacin de una compaa.
Por su lado, el mismo autor refiere que la Seguridad de la Informacin es la disciplina que nos habla de los riesgos,
de las amenazas, de los anlisis de escenarios, de las buenas prcticas y esquemas normativos, que nos exigen niveles
de aseguramiento de procesos y tecnologas para elevar el nivel de confianza en la creacin, uso, almacenamiento,
transmisin, recuperacin y disposicin final de la informacin.
Esto significa que la Seguridad de la Informacin trasciende al rea de TI, ya que la informacin podra estar en medios
tecnolgicos como no tecnolgicos. Es decir que la Seguridad de la Informacin se encarga de la proteccin de la in-
formacin en todas sus manifestaciones. En ese sentido, la Seguridad de la Informacin es la capa estratgica orientada
a proteger la informacin.
En resumen, la Seguridad de la Informacin es un concepto ms amplio y abarca la Seguridad Informtica.

TEMA N. 2: CONTROLES DE SEGURIDAD I
INTRODUCCIN
En este tema vamos a revisar 2 controles importantes de Seguridad de la Informacin: La Gestin de Accesos y la Crip-
tografa.
1 GESTIN DE ACCESOS
La Gestin de Accesos es un control preventivo que permite que no se acceda a la a la informacin por parte de usua-
rios no autorizados. La Gestin de Accesos est relacionada a la Confidencialidad de la Informacin.
1.1 Acceso.
Empecemos por lo primero: definiendo lo que es el Acceso. Acceso es el flujo de informacin entre un sujeto y un
objeto. Un sujeto puede ser una persona, una aplicacin, una interface, etc. Por su lado, un objeto puede ser una Base
de datos, un programa, una impresora.
El acceso a la informacin dentro de una compaa no puede darse sin ningn tipo de control. El acceso a la informa-
cin 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 Compaa?
La Sra. de limpieza para realizar sus funciones necesitara acceso a la planilla de la compaa?
El administrador de la Red para realizar sus funciones necesitar tener acceso a la Contabilidad de la compaa?
En los 3 casos presentados, Qu debera suceder si alguno de estas personas solicita acceso? Evidentemente, el acceso
a la informacin debera ser rechazado. A eso se refiere la necesidad de Saber. Este criterio precisa que los accesos
a los activos de informacin deben ser otorgados a aquellas personas que para el desenvolvimiento de sus funciones
requieren de dicho acceso.
Ahora, vayamos un paso ms all. Qu sucede con el Gerente General o dueo de la Compaa? Necesitara tener
acceso a todo la informacin de la compaa? La respuesta es NO. El gerente General debera tener acceso solamente
a aquella informacin que necesite para realizar sus funciones de Gerente General.
La necesidad de Saber no es fcil de implementar en las organizaciones. En muchas compaas se otorga acceso a todo
aquel que lo pide o se otorga acceso a los compaeros o amigos de la oficina. Todas las compaas deberan compren-
der este criterio fundamental y aplicarlo.
1.2 Fases del control de Accesos
El Control de accesos se implementa en los sistemas de informacin en 3 fases.
a) Identificacin
b) Autenticacin
c) Autorizacin
A continuacin veremos las fases en detalle.

a) Identificacin
La identificacin 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 informacin, es evidente que no basta con identificarnos ante un Sistema
para acceder a la informacin. Los Sistemas de Control de Acceso siempre requieren que se verifique la identidad del
usuario.
b) Autenticacin.
La autenticacin es el segundo paso y consiste en asegurar que el usuario demuestre que es quien dice ser.
La autenticacin se logra a travs de 3 preguntas:
Qu es lo que se?
Qu es lo que tengo?
Qu es lo que soy?
b.1 Autenticacin sabiendo algo.
La pregunta Qu es lo que se? es la ms popular y se responde a travs de contraseas. Es decir, los usuarios saben sus
contraseas.
El reto de una contrasea es que cumpla 2 criterios de forma simultneamente:
Que la contrasea sea fcil de recordar (para el usuario)
Que la contrasea sea difcil de adivinar (para cualquier atacante)
Por ejemplo, la contrasea: %%3sat5050599??##, es una contrasea difcil de adivinar, pero no es fcil de recordar,
por lo que no cumple los 2 criterios simultneamente.
Existen 2 tcnicas recomendadas para recordar contraseas y que permiten cumplir ambos criterios.
La tcnica del Acrstico: Por ejemplo considere la frase: Ms vale pjaro en mano que ciento volando. Si aplicamos
la tcnica del acrstico, es decir tomamos la primera letra de cada palabra de la frase nos dara la contrasea: Mvpem-
q100v.
La segunda tcnica es la de usar una frase que sea familiar. Considere la siguiente frase corta: si se puede. Agregando
smbolos a la frase nos dara la contrasea: Si##se##puede
Esta tcnica tambin 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 contrasea: margaretthatcheris110%SEXY. Esta
contrasea se deriva de la frase: Margaret Thatcher es 110% sexy. Puede encontrar ms informacin de las recomen-
daciones de Edward Snowden en:
http://www.20minutos.es/noticia/2429957/0/edward-snowden/seis-consejos/contrasenas-seguras-internet/#x-
tor=AD-15&xts=467263
b.2 Autenticacin teniendo algo. Auditora de sistemas
Otra forma de autenticacin (menos popular) es la d
autenticacin teniendo algo. Por ejemplo: un token, una tarjeta d
coordenadas o un chip. En la siguiente figura se tiene un ejempl
b.2 Autenticacin teniendo algo.
de tarjeta
Otra forma de autenticacin de
(menos coordenadas:
popular) es la de autenticacin teniendo algo. Por ejemplo: un token, una tarje-
ta 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 autenticacin.

Fuente: zonabancos.com
Figura 1- tarjeta de coordenadas usada en la autenticacin.
El Sistema antes de permitir una transaccin importante, nos solicita que ingresemos una determinada coordenada.
Por ejemplo B6. El usuario no sabe el cdigo, simplemente lo tiene.
Fuente: zonabancos.com
b.3 Autenticacin siendo algo.
El Sistema antes de permitir una transaccin importante, nos solicit
Esta pregunta se responde con la biometra. El Sistema pide ingresar un dato biomtrico para autenticar a la persona.
que ingresemos una determinada coordenada. Por ejemplo B6. E
Esto puede ser logrado con la huella dactilar, el anlisis del iris, de la retina, la geometra de la mano. Las venas del
usuario no sabe el cdigo, simplemente lo tiene.
dorso, etc.
c) Autorizacin
b.3 Autenticacin siendo algo.
La ltima fase del control de Acceso es la Autorizacin y se refiere a que permisos (tambin llamados privilegios) tiene
un usuario cuando ingresa al Sistema.
Esta pregunta se responde con la biometra. El Sistema pid
En funcin a la Autorizacin un determinado usuario puede insertar, modificar o incluso eliminar registros en una
ingresar un dato biomtrico para autenticar a la persona.
determinada transaccin. Est
puede ser logrado con la huella dactilar, el anlisis del iris, de
retina,
c.1 Sistema de Control la geometra de la mano. Las venas del dorso, etc.
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:
Identificacin y autenticacin en base a una o ms factores.
Restriccin de logon IDs a terminales y horarios especficos

1
Gestin de la Autenticacin a travs de la creacin o modificacin de perfiles de usuario
Crear responsabilidades y auditabilidad individual a travs de registro de los eventos en una bitcora
Reportes de Accesos
2 CRIPTOGRAFA
2.3 Definicin
La criptografa es otra tcnica utilizada para preservar la confidencialidad de la Informacin.
La criptografa permite convertir un texto plano (tcnicamente se llama plain text) que requiere ser transmitido, a
un texto ilegible (tcnicamente se le llama cypher text) que no puede ser entendido si es que alguien captura el texto
durante la transmisin.
La criptografa tiene 3 elementos:
El
algoritmo criptogrfico. Siempre se debe utilizar un algoritmo pblico ya que este algoritmo es considerado
robusto.
La
llave. La llave se refiere 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 criptografa reside en la seguridad de la llave.
La
longitud de la llave. Mientras ms larga la longitud de la cadena de bits, ms 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 cripto-
grafa intentando todas las combinaciones posibles de llave.
2.4 Tipos de Criptografa
Existen 3 tipos de criptografa:
a) Criptografa simtrica.
Tambin conocida como criptografa de clave privada.
b) Criptografa asimtrica.
Tambin conocida como criptografa de clave pblica.
c) Funciones hash.
Es una criptografa de una sola direccin. Es decir, se puede encriptar, pero no se puede desencriptar.
A continuacin, revisaremos las caractersticas de cada una de las criptografas.
a.1 Criptografa simtrica.
La criptografa asimtrica es una criptografa 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 criptografa simtrica ms popular es el algoritmo AES (Advanced Encription System). Este algoritmo
permite longitudes de llave de 128, 192 o 256 bits. (EL da 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
criptografa convocado por la NIST en el ao 2001.
Puede encontrar ms informacin en:
https://es.wikipedia.org/wiki/Advanced_Encryption_Standard
Por otro lado, puede ver un video de esta criptografa en:
https://www.youtube.com/watch?v=46Pwz2V-t8Q
El problema de la criptografa simtrica es la distribucin 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.
Por ejemplo si encriptamos un documento, enviamos el documento encriptado al destinatario, pero, cmo haramos
para hacerle llegar la llave? Para resolver este problema, en los aos 70 se invent la criptografa asimtrica.
b.1 Criptografa asimtrica
La criptografa asimtrica 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, podra estar publicada en cualquier
directorio). Con esto se evita, que se tenga que distribuir la llave secreta.
El algoritmo de criptografa asimtrica ms 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 da 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 criptografa es la funcin hash. Se trata de una funcin de una sola va, es decir en un solo sentido.
Se utiliza para encriptar pero no para desencriptar.
La funcin hash es una funcin muy sensible. Esto significa que un pequeo cambio en el texto plano originar un
resultado completamente diferente.
El resultado de una funcin Hash es llamado MD (Message Digest) o resumen del mensaje. Este resultado siempre es
de una longitud fija sin importar la longitud del mensaje original.
El algoritmo Hash ms utilizado es el SHA-II (tambin llamado SHA-256).
Esta criptografa es ms utilizada para garantizar la integridad (ms que la confidencialidad).
Para probar cmo funciona, ingrese a hashgenerator.de y ponga un texto, hagale anos cambios y observe como el
Message Digest cambia dramticamente.
2.5 Comparacin de las tres criptografas
Las 3 criptografas se utilizan en diversas situaciones. A continuacin presentaremos un cuadro resumen de las 3 crip-
tografas:
Tabla 4
Cuadro Comparativo Criptografas.
ATRIBUTO CRIPTOGRAFA SIMTRICA CRIPTOGRAFA ASIMTRICA FUNCIN HASH
Nro. de llaves 1 2 1
Algoritmo AES RSA SHA-II
Log de llave 128, 192, 156 2048. 3072 256
Performance Rpido Pequeos N/A
Volmenes de informacin Grandes Pequeos N/A

2.6 Aplicaciones
La Criptografa tiene una serie de aplicaciones.
Firma
Digital. Este algoritmo emula la firma humana en transacciones digitales. Utiliza la criptografa asimtrica y
la funcin Hash.
Transport Layer Security (TLS). Este protocolo encripta la comunicacin 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 autenticacin mutua y establecer
parmetros criptogrficos. 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 estndar para la proteccin de correos electrni-
cos.
3D Secure. Es un protocolo basado en XML para otorgar seguridad en las transacciones de tarjeta de dbito y de
crdito.
Si te interesa el tema de la criptografa, le recomiendo la pelcula El Cdigo Enigma donde se cuenta la historia de
cmo se logr romper la criptografa de la maquina alemana que encriptaba los mensajes de guerra durante la Segun-
da Guerra Mundial.

de contenidos
LECTURA SELECCIONADA N 1:
seleccionadas
Leer artculo: Aplicaciones de la Criptografa.
Delgado, V., & Palacios, R. (2006). Aplicaciones prcticas de la criptografa. Anales de Mecnica y Electricidad. Dispo-
nible
Recordatorioen:Anotaciones
http://bit.ly/2bcFvh1
Chat
ACTIVIDAD N. 4
de contenidos
Participan en el Foro de discusin subiendo un ensayo sobre cuando utilizar los diversos tipos de criptografa.

seleccionadas INSTRUCCIONES
1. Revisa los temas 1 y 2 y la lectura seleccionada.

Recordatorio
2. Lee lasChatinstrucciones en el Aula Virtual.
Anotaciones
3. Elabora un ensayo sobre cuando utilizar los diversos tipos de criptografa y sbelo al aula virtual.
4. Participa en el foro de discusin, emitiendo tu opinin sobre el trabajo de un compaero, como mnimo.
TEMA N. 3: CONTROLES DE SEGURIDAD II
INTRODUCCIN
Este tema est enfocado en los controles a implementar tanto en la Seguridad de Internet, como en el cloud y los
mviles.
1 SEGURIDAD EN INTERNET
La Seguridad de Internet tiene que ver con los controles a implementar por las compaas para protegerse de las
amenazas provenientes de Internet.
En Internet hay una diversidad de personas entre las que resaltan:
Crackers. Ms conocidos como los criminal hackers. Son personas con conocimientos tecnolgicos (no necesaria-
mente muy sofisticados) que realizan actividades ilegales como ingresar a los sistemas de informacin para robar
informacin con el fin de obtener un beneficio econmico.
Hay que diferenciar el cracker del hacker. El hacker no es un criminal. Es una persona con altos conocimientos
tecnolgicos y que averiguan como ingresar a un determinado objetivo. Esta ms orientado con la satisfaccin per-
sonal que con el lucro haciendo actividades ilegales, como es el caso del cracker. Sin embargo, la persona comn
no distingue entre ambos. En realidad cracker y hacker son opuestos.
Lammers. Los lammers son aquellas personas que tienen limitaciones en su capacidad tcnica y que se hacen pasar
como hackers. Es decir, presumen de sus habilidades tcnicas, a pesar de que no las tienen. Los hackers utilizan
este trmino como un insulto para la persona que se alucina hacker pero que lo nico que hace es utilizar pro-
gramas de fcil manejo para intentar hackear un objetivo.
Wannabies. Los Wannabies son aquellas personas que estn en proceso de hacerse hackers. Podra tratarse de no-
vatos con altos conocimientos tcnicos pero que an no son reconocidos por la comunidad hacker. Etas personas
perseveran estudiando y aprendiendo las diversas tcnicas de ingreso a los sistemas.
Script-Kidies. Los Script-Kiddies son personas sin conocimientos tcnicos avanzados y que se dedica a utilizar pro-
gramas y scripts desarrollados por otros para atacar sistemas. Son como los lammers.
Samurai. Los Samirai son personas con alta capacidad tncia y que son llamados por una compaa 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 compaa. En Latinoamerica existe un espionaje industrial en aumento y las compa-
as deben protegerse de la competencia.
Las compaas para defenderse de las amenazas de Internet, implementan controles, los cuales veremos a continua-
cin.
1.1 Firewalls
El Firewall es considerado como el control primario de defensa de las compaas. El firewall puede ser visto como una
garita de peaje. En funcin a ciertas reglas permite o no el acceso entre 2 redes. Los firewalls pueden ser implementa-
dos en hardware o software, o en una combinacin de ambos
El firewall tambin 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 tecnologas de firewall entre las que destacan:

Filtrado
de paquetes. Este tipo de firewall filtra cada paquete tomando nicamente la informacin contenida en
el paquete en s, utilizando generalmente una combinacin del emisor del paquete y la direccin de destino, su
protocolo, y, en el trfico TCP y UDP, el nmero de puerto. Este tipo de Firewalls fue el primer tipo, y actualmente
no es muy utilizado.
Aplicacin. Este tipo de Firewall es usado con los servidores proxy. En esta situacin no se da una trasferencia de
datos de forma directa entre redes, porque existe un monitoreo de la informacin.
Stateful
Inspection. Este tipo de firewall realiza un seguimiento del estado de las conexiones de red (TCP, UDP) que
cruzan a travs de l, dejando pasar solo a los paquetes que coincidan con una conexin activa conocida.
Cuando se implementa un firewall, una buena prctica es seguir la gua 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 Generacin (NGFW). Estos Firewalls son capa-
ces de entender las aplicaciones Web 2.0 (Facebook, Dropbox, Youtube, etc) y tambin se conectan con los sistemas
LDAP y con ello conocen a los usuarios de la red. La compaa palo Alto invento este concepto y se est apoderando
rpidamente del mercado de Firewalls.
Una descripcin de este tema lo puede ubicar en: http://media.paloaltonetworks.com/documents/Firewall_Featu-

re_Overview-spanish.pdf
1.2 IDS
El Sistema IDS es un sistema que intenta detectar anomalas.
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 trfico de la red (o parte de ella),
inspeccionado los paquetes en busca de situaciones anmalas. Un NIDS es un control que complementa a los fi-
rewalls.
Una analoga para comprender el NIDS son los controles antes de abordar un avin. Cuando Ud. quiere abordar un
avin 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 mquina 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 degradacin 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 crticos 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 cam-
biar una llave en el regedit, el HIDS toma este cambio como una situacin anmala y detiene el intento.
2 SEGURIDAD DEL CLOUD
1.1 Cloud Computing
Una de las mega tendencias en TI indudablemente es la adopcin del Cloud Computing. Mucho se ha escrito del
Cloud y existe algo de confusin en este tema.
Las definiciones oficiales de Cloud se encuentran en la gua NIST SP 800-145. La gua la puede ubicar en:
http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf
Segn esta gua, el Cloud es un modelo para habilitar el acceso de red de forma continua, conveniente y bajo deman-
da a un conjunto de recursos de computacin configurables que puedan ser rpidamente provisionados y lanzados
con un mnimo esfuerzo de gestin e interaccin con el proveedor de servicio.
Asimismo la gua define 5 caractersticas que debe cumplir toda solucin para ser considerada Cloud:
Auto-servicio por demanda
Acceso amplio desde la red
Pooling de recursos
Rpida 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:
Prdida
de control. La compaa pierde control de las soluciones tecnolgicas, 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 deberan interesar al cliente donde estn sus datos. Sin
embargo, algunos pases exigen que los datos no salgan de sus territorios.
Ambigedad
de responsabilidades. Ante la ocurrencia de un problema, el proveedor y el cliente podran verse
enfrentados debido a una evasin de las responsabilidades.
Adaptacin de usuarios al nuevo modelo. Cambiar el modo de trabajar de los usuarios hacia una solucin 100%
web podra originar 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 origina riesgos de proteccin de la informacin cuando es accedida
desde los dispositivos mviles tanto de propiedad de la compaa como de los propios usuarios.
Incapacidad
de medir cumplimiento. El modelo de Cloud se basa en la medicin. Esto origina riesgos en el cliente
para saber si la medicin es la adecuada.
Falla
de la Nube. En caso de falla en la Nube, la compaa se quedara sin servicio. El Internet se convierte en un
recurso crtico. Sin Internet no hay acceso a la solucin.
En relacin a los riesgos de seguridad de la informacin, la principal organizacin que investiga estos temas es la Cloud
Security Alliance. Su sitio web es: https://cloudsecurityalliance.org/
Esta organizacin emite todos los aos un informe de las amenazas que afectan a los servicios Cloud. El ltimo informe
es el informe The Treacherous 12 CSAs Cloud Computing Top Threats in 2016, en el cual se definen las principales
amenazas, las cuales se presentan a continuacin:
1. Violaciones de los datos
2. Identidad dbil, gestin de accesos y credenciales

3. APIs inseguras
4. Vulnerabilidades de la Aplicacin y del sistema
5. Secuestro de cuentas
6. Empleados del proveedor maliciosos
7. Amenazas persistentes avanzadas (APT)
8. Prdida de Datos
9. Insuficiente Due Diligence
10. Abuso y Uso nefasto de servicios en la nube
11. Denegacin de Servici
12. Cuestiones tecnologa compartida
El informe con todo el detalle, lo puede obtener en:
https://downloads.cloudsecurityalliance.org/assets/research/top-threats/Treacherous-12_Cloud-Computing_Top-
Threats.pdf
3. SEGURIDAD DE MVILES.
3.1 Consumerizacin de la tecnologa
Hubo un tiempo en que los usuarios dentro de una compaa le pedan asesora al rea de TI, sobre que tecnologa
adquirir. El rea de TI era el rea experta y los usuarios agradecidos seguan los consejos que el rea de TI ls daba. Esos
son tiempos muy lejanos. El da de hoy estamos viviendo una tendencia en que los usuarios saben tanto de tecnologa
como el rea de TI. Esto es particularmente cierto en el caso de las tecnologas mviles. Incluso, las tecnologas de in-
formacin llegan primero al consumidor y luego son adoptadas por las compaas. Este fenmeno es conocido como
la consumerizacin de la tecnologa. Es por esta razn que los dispositivos mviles estn prcticamente al alcance de
cualquier persona.
Esto enfrenta a las compaas a la decisin de si permitir o no el ingreso de los dispositivos mviles. Las compaas
enfrentan el da de hoy estas realidades:
Presin de los usuarios por usar equipos personales en mbito laboral
Los usuarios tienen mejor tecnologa que la prevista por sus empresas
Nuevos riesgos para las empresas
Para enfrentar los desafos de la consumerizacin, las compaas tienen 2 estrategias:
COPE
(Corporate Owned Personally Enabled). En esta estrategia la compaa adquiere los dispositivos mviles y
los entrega a sus trabajadores. Dado que la propiedad de los dispositivos es de la compaa, los dispositivos estn
sujetos a las polticas y restricciones que la compaa impone.
BYOD
(Bring Your Own Device). En esta estrategia la compaa permite a sus trabajadores que traigan sus propios
dispositivos mviles personales y les permite que desde dichos dispositivos se accedan a activos de informacin de la
compaa tales como correo electrnico, Intranet, VPN, acceso a Sistemas internos, entre otros. Esto significa que
en un dispositivo personal conviven aplicaciones e informacin tanto del usuario como de la compaa.
3.2 Los riesgos en los mviles
Estas nuevas tendencias en las que la informacin de la compaa reside en los dispositivos mviles generan nuevos
riesgos. Entre los riesgos ms relevantes tenemos:
Robo
o prdida de dispositivo. Si se pierde el dispositivo mvil, no solo se pierde informacin personal del usuario,
sino que un tercero podra tener acceso a la informacin de la compaa.
Fuga
de datos. Si la compaa no implementa controles, un usuario podra sacar informacin de la compaa sin
ningn tipo de restriccin.
Acceso no autorizado. Un dispositivo mvil no protegido puede ser accedido ante un descuido del usuario y la
informacin de la compaa podra ser accedida de manera no autorizada.
Propagacin
de malware. Los dispositivos mviles son ahora otro canal de propagacin 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 mviles. Puede ver un
video sobre este tema (en ingls) en: http://www.youtube.com/watch?v=iJUwz2b64Sw
A continuacin haremos un rpido repaso de las diversas plataformas mviles:
a) iOS.
El SO de Apple es considerada la plataforma ms segura debido a que toda App es revisada por Apple antes de ser pu-
blicada 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/tecnologia/moviles-dispositivos/iphone-ipad/20150925/54436836215/apple-apps-
malware.html
b) Android.
La plataforma mvil de Google es considerada una de las ms inseguras debido a que no cuenta con los controles que
Apple exige. Los diversos estudios indican que esta es la plataforma mvil preferida para la distribucin del malware y
la generacin 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 diseo 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 mvil de Windows no es precisamente la ms 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.
TEMA N. 4: AUDITORIA A LA SEGURIDAD DE LA INFORMACIN
INTRODUCCIN
Este tema est enfocado en como efectuar una Auditoria de Sistemas a la Seguridad de la informacin.
1 AUDITORIA A LA SEGURIDAD DE LA INFORMACIN
En lneas generales, el Auditor de Sistemas debe efectuar las siguientes tareas cuando revisa la Seguridad de la Infor-
macin:
Revisin de polticas, procedimientos y estndares escritos de seguridad de la informacin.
Revisar la ejecucin de charlas de concientizacin de Seguridad a todo el personal.
Revisar la existencia de Inventarios de Activos de Informacin y la existencia de Propietarios para los Activos.
Revisar la existencia de procesos peridicos de Anlisis de Riesgo de seguridad de la informacin.
Revisin
de controles para minimizar riesgos en cada uno de los Activos de Informacin a travs de la existencia de
Baselines de seguridad.
2 AUDITORIA A LOS CONTROLES DE SEGURIDAD.
A continuacin presentaremos las principales tareas que realiza el Auditor de Sistemas cuando audita los controles de
seguridad.
2.1 Auditoria a los accesos.
Es muy comn 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:
Revisin
de usuarios vigentes y cesados. Lo que se trata de encontrar es accesos de usuarios ya cesados y que siguen
vigentes en los sistemas.
Revisin
de cuentas genricas / de servicio. Aqu se trata de identificar si todas las cuentas genricas tienen un pro-
pietario, si estn vigentes. Por las cuentas de servicio se revisa si es que siguen vigentes.
Revisin
de Privilegios. Se revisa los permisos que tienen los usuarios dentro de un determinado Sistema. El propie-
tario debe validar si los permisos estn vigentes.
Revisin
de autorizaciones para el acceso. Se revisa que todo acceso cuente con su autorizacin correspondiente
por parte del propietario del Activo de informacin
2.2 Auditoria a la Criptografa.
Revisin
de gestin de llaves. El auditor revisa el ciclo de vida de las llaves criptogrficas: Cmo se crean? Quin
las crea? Cmo se almacenan? Qu controles existen para proteger las llaves?
Fortaleza
de los algoritmos criptogrficos. El auditor revisa los algoritmos utilizados en las diversas implementacio-
nes para verificar su vigencia y robustez.
As por ejemplo una pgina muy usada por los Auditores es https://www.ssllabs.com/ssltest. Esta pgina permite revi-
sar la robustez de los algoritmos criptogrficos y del certificado digital de una pgina web.
2.3 Auditoria a los Controles de Seguridad Internet, Cloud y Mviles
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 genricas que
permiten accesos indebidos.
Revisar reglas del IDS/IPS. Se revisan las reglas en busca de debilidades en las reglas de deteccin de anomalas.
Revisar la actualizacin 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 solucin Cloud. Asimismo se revisan los Contratos y si los SLAs ofrecidos
por el proveedor Cloud se cumplen.
Finalmente a nivel de los dispositivos mviles se revisan que en los mviles COPE y BYOD se tengan implementados
controles para asegurar la confidencialidad de la informacin contenida en dichos mviles. As por ejemplo, el Audi-
tor revisa que la compaa tenga alguna solucin de control como por ejemplo MDM (Mobile Device Management).
112 Diagrama Objetivos Inicio
UNIDAD IV: Auditora a la seguridad de la informacin

de contenidos
LECTURA SELECCIONADA N 2:
seleccionadas
Leer
Diagramaartculo:
Objetivos Seguridad
Inicio en dispositivos mviles: qu pautas debes seguir?.
Velasco, J. (2013). Seguridad en dispositivos mviles: qu pautas debes seguir?. Disponible en http://bit.ly/2bxHOZZ
de contenidos
Diagrama Objetivos
TAREA ACADEMICA N 2
Inicio
Esta actividad
Lecturas
Glosario
seleccionadas puede
Bibliografa
consultarla en su Aula virtual.
de contenidos
Recordatorio
GLOSARIO DE LA UNIDAD IV
Anotaciones Chat

seleccionadas
Activo de informacin. Recurso informtico que trata informacin. Puede ser una Base de datos, un Sistema, un Ser-
vidor, etc.
BYOD. Acrnimo de Bring Your Own Device. Es una estrategia utilizada por las compaas para permitir a los usuarios
traer sus propios dispositivos y conectarlos a la red de la Compaa.
COPE. Acrnimo de Corporate Owned personally Enabled. Es una estrategia usada por las compaas para entregar a
sus trabajadores dispositivos mviles.
Cuenta de Servicio. Es una cuenta utilizada por un Sistema de Informacin o dispositivo de red para comunicarse con
otro sistema o dispositivo. La cuenta de Servicio no es utilizada por ningn usuario.
Cuenta genrica. Es una cuenta utilizada para un usuario para un propsito especfico pero que no cuenta con sus
Objetivos Inicio
nombres y apellidos. Toda cuenta genrica debe contar con un Propietario.
Propietario. Responsable de otorgar acceso a un Activo de informacin.

os
BIBLIOGRAFA DE LA UNIDAD IV
s
o Anotaciones Chat
Objetivos Inicio
AUTOEVALUACIN DE LA UNIDAD IV
s
1. Despus de 2 meses, la Universidad Universal, descubre un hueco de seguridad que permiti a 2 alumnos reali-
s
Glosario
zar un ataque informtico y acceder y modificar las notas almacenadas en la Base de Datos del Sistema Acadmico.
Bibliografa
El descubrimiento fue accidental. En este caso, la Universidad habra podido detectar oportunamente si es que
tuviese implementado en la Base de datos:
o Anotaciones
Chat
A) Algoritmo criptogrfico RSA de Criptografa asimtrica
B) Funcin Hash tipo SHA-II
C) Algoritmo criptogrfico AES de 128 bits de Criptografa simtrica
D) Algoritmo criptogrfico AES de 256 bits de Criptografa simtrica
2. En una auditoria a la Infraestructura de red, cul de los siguientes NO revisara?
A) Topologa de la red
B) Interconexion de la red
C) Revisin del File Server
D) Gateway a Internet
3. Ud. Encuentra que el rea de IT ha adquirido un Firewall de Nueva Generacin y encuentra que el equipo esta
dimensionado para soportar hasta 200Mbps de ancho de banda de Internet. Sin embargo, debido a una reciente
fusin la Compaa, el trafico esta en 290 Mbps Esta situacin origina el riesgo que hay trafico sin proteger. Su
recomendacin 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 autenticacin de doble factor es una obligacin en cul de las siguientes situaciones?
A) Para conectarse a la red desde las oficinas de la compaa
B) Para conectarse a un servidor dentro de la red desde las oficinas de la compaa
C) Para conectarse remotamente a travs desde un cliente VPN
D) Para conectarse a un sitio web pblico con https ( x ejm de un Banco)

5. La Ley de Proteccin de datos obliga a las compaas a proteger los datos que se transmiten sobre la red. Ud. en-
cuentra que una compaa ha aumentado dramticamente la transmisin de datos con diversos socios de negocios
y se transfieren datos personales Cul de los siguientes algoritmos Ud. recomienda utilizar para proteger la trans-
misin?
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 informacin guarda las contraseas en plano. Cul de los siguientes algoritmos
Ud. recomienda utilizar para almacenar las contraseas?
A) Advanced Encription System (AES)
B) Secure Hash Algorithm (SHA-II)
C) Rivest, Shamir, Adleman (RSA)
D) Message Digest 5 (MD5)
7. En cul de las siguientes situaciones Ud. recomendara la implementacin de tokens como mecanismo de auten-
ticacin?
A) Para conectarse a la red desde las oficinas de la compaa
B) Para conectarse a un sitio web pblico sin https ( x ejm de un Banco)
C) Para conectarse remotamente a travs desde un cliente VPN
D) Para conectarse a un sitio web pblico con https ( x ejm de un Banco)
8. Un auditor encuentra que los usuarios de una empresa trasnacional utilizan sin ningn tipo de restriccin aplica-
ciones personales de almacenamiento en la nube tales como Dropbox, Google Drive, Microsoft One Drive entre
otras para almacenar informacin 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
9. Cul de las siguientes opciones es la que otorga la postura ms robusta de

seguridad?
A) Contrasea + Token
B) Biometra + Token
C) Contrasea + Tarjeta con chip
D) Contrasea + Biometra
10. Ud. requiere configurar un WiFi corporativo basado en la tecnologa Cisco.

Al configurar el enrutador inalmbrico, el Sistema le presenta varias opciones
para configurar la encriptacin del trfico. Al respecto, Cul de los siguientes
algoritmos Ud. seleccionara?
A) 3DES
B) AES
C) RSA
D) SHA-II
E
ste manual autoformativo es el mate- muro y las tareas, siempre acompaado de tus
rial didctico ms importante de la docentes y amigos.
presente asignatura. Elaborado por el
docente, orienta y facilita el auto aprendizaje El modelo educativo de la Universidad Con-
de los contenidos y el desarrollo de las activi- tinental a distancia es innovador, interactivo
dades propuestas en el slabo. e integral, conjugando el conocimiento, la

investigacin y la innovacin. Su estructu-
Los dems recursos educativos del aula virtual ra, organizacin y funcionamiento estn de
complementan y se derivan del manual. Los acuerdo a los estndares internacionales.
contenidos multimedia ofrecidos utilizando Es innovador, porque desarrolla las mejores
videos, presentaciones, audios, clases interac- prcticas del e-learning universitario global;
tivas, se corresponden a los contenidos del interactivo, porque proporciona recursos
presente manual. La educacin a distancia en para la comunicacin y colaboracin sncro-
entornos virtuales te permite estudiar desde na y asncrona con docentes y estudiantes;
el lugar donde te encuentres y a la hora que e integral, pues articula contenidos, medios
ms te convenga. Basta conectarse al Internet, y recursos para el aprendizaje permanente y
ingresar al campus virtual donde encontrars en espacios flexibles. Ahora podrs estar en
todos tus servicios: aulas, videoclases, presen- la universidad en tiempo real sin ir a la uni-
taciones animadas, biblioteca de recursos, versidad.

Auditoria - de - Sistemas 2016

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Auditoria - de - Sistemas 2016

Загружено:

Авторское право:

Доступные форматы

AUDITORA DE SISTEMAS

Gonzalo Martin Valdivia Benites

Direccin: Emma Barrios Ipenza

Este manual autoformativo no puede ser reproducido, total ni parcialmente, ni registrado en o

UNIDAD I: INTRODUCCIN A LA AUDITORIA DE SISTEMAS 9

TEMA N. 2: EL PROCESO DE LA AUDITORIA DE SISTEMAS 17

TEMA N. 4: MARCOS DE REFERENCIA DE AUDITORIA DE SISTEMAS 33

UNIDAD II: AUDITORIA AL GOBIERNO Y GESTIN DE TI 47

UNIDAD III: AUDITORA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE 73

TEMA N. 2: MANTENIMIENTO DE SISTEMAS 81

TEMA N. 4: AUDITORIA AL CICLO DE VIDA 88

UNIDAD IV: AUDITORA A LA SEGURIDAD DE LA INFORMACIN 95

TEMA N. 2: CONTROLES DE SEGURIDAD I 99

LECTURA SELECCIONADA N 1: 104

LECTURA SELECCIONADA N 2: 112

UNIDAD I UNIDAD II UNIDAD III UNIDAD IV

TIEMPO MINIMO DE ESTUDIO

1era. Semana y 3era. Semana y 5ta. Semana y 7ma. Semana y

Diagrama Objetivos Inicio

UNIDAD I: INTRODUCCIN A LA AUDITORIA DE SISTEMAS

DIAGRAMA DE PRESENTACIN DE LA UNIDAD I

CONTENIDOS EJEMPLOS ACTIVIDADES

ORGANIZACIN DE LOS APRENDIZAJES

CONOCIMIENTOS PROCEDIMIENTOS ACTITUDES

2 Videoclase 1. Identifica el riesgo y escribe hallazgos de

Tema N. 4: Marcos de referencia de audi-

TEMA N. 1: VISIN DE LA AUDITORIA DE SISTEMAS

1.2 Tipos de Auditoria

Existen muchos tipos de Auditoria. Entre las principales tenemos:

1.3 Auditoria Interna vs. Auditoria Externa.

Cuando1.4una Las Big Four.

Figura 1. Las Big Four.

Si te interesa saber ms de estas compaas, puedes obtener ms informa-

1.5 Qu es la Auditoria de Sistemas?

CRISC (Certified in Risk and

Figura 2 Muestra de un Certificado CISA

2.2 Estndares de ISACA

A continuacin, vamos a detallar los estndares ms relevantes para nuestro curso.

Hallazgos, conclusiones y recomendaciones de la auditora

3  EL RIESGO COMO ELEMENTO CLAVE DE LA AUDITORIA DE SISTEMAS

3.1 Identificar el riesgo

Y lo primero es que debes tener muy presente lo que es el riesgo.

Aqu la amenaza es cualquier cosa que tenga el potencial de hacer dao.

La vulnerabilidad es cualquier deficiencia que se tenga.

El Servidor no cuenta con Antivirus.

Al Sistema Operativo nunca se le han instalado parches del fabricante

Descompongamos la primera situacin en funcin de la definicin del riesgo:

Cul sera la vulnerabilidad? La propia inexistencia del Antivirus es la vulnerabilidad.

Ahora, veamos la segunda situacin:

Cul sera la vulnerabilidad? Mantener la misma contrasea es la vulnerabilidad.

Cul sera el dao? El robo o la modificacin de la informacin contenida en el servidor.

Finalmente, veamos la tercera situacin:

Cul sera la vulnerabilidad? El no actualizar los parches del Sistema Operativo

Cul sera el dao? El robo o la modificacin de la informacin contenida en el servidor.

Como vez, en las 3 situaciones se encuentra la amenaza, la vulnerabilidad y el dao.

Los Auditores de Sistemas se enfocan en identificar los riesgos.

3.2 Qu se hace con el riesgo?

El auditado tiene 4 opciones para trata el riesgo:

Para minimizar los riesgos se pueden implementar varios tipos de controles:

TEMA N. 2: EL PROCESO DE LA AUDITORIA DE SISTEMAS

1.1 Planeamiento de la Auditora de Sistemas

Cmo se planifica? Existen 2 tipos de planeamiento:

Entender los cambios en el entorno de negocios del auditado.

UNIDAD III: AUDITORA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE 73

2 Videoclase 1. Identifica el riesgo y escribe hallazgos de

3 EL RIESGO COMO ELEMENTO CLAVE DE LA AUDITORIA DE SISTEMAS

- Ttulo que utiliza el hecho observado (sumilla).

- La situacin irregular o deficiencia hallada (condicin).

- Las normas transgredidas (criterio).

1 FORMULACIN DE LOS HALLAZGOS DE AUDITORIA

- Se encontr que el Centro permanece a una temperatura no adecuada.

- Se encontr un extractor de aire no instalado.

- El Centro de Datos no cuenta con un falso piso no falso techo.

- Se cuenta con UPS individuales para cada servidor.

- No existe una bitcora de ingreso.