A0031 MA Auditoria de Sistemas ED1 V1 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
UNIDADES DIDACTICAS
TIEMPO MINIMO DE ESTUDIO
UNIDAD I: Introduccin a la Auditoria de Sistemas
DIAGRAMA DE PRESENTACIN DE LA UNIDAD I
ORGANIZACIN DE LOS APRENDIZAJES
TEMA N. 1: Visin de la Auditoria de Sistemas
11
INTRODUCCIN 11
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
2
3
Formulacin de las Recomendaciones

Formulacin del Informe de Auditoria
TEMA N. 4: Marcos de Referencia de Auditoria de Sistemas
23
26
26
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
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
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
83
ACTIVIDAD N. 3
83
TEMA N. 3: Aplicaciones de Negocio
84
INTRODUCCIN 84
1 Aplicaciones de Negocio Verticales
TEMA N. 4: Auditoria al Ciclo de Vida
84
88
INTRODUCCIN 88
1 Auditoria al Ciclo de Vida
88
2 Auditoria al Mantenimiento de Sistemas
90
90
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
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
2 Criptografa
99
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
112
TAREA ACADEMICA N 2
112
GLOSARIO DE LA UNIDAD IV
112
BIBLIOGRAFA DE LA UNIDAD IV
112
AUTOEVALUACIN DE LA UNIDAD IV
113
MANUAL AUTOFORMATIVO
INTRODUCCIN
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-
La asignatura est estructurado en 4 Unidades:

La primera Unidad est enfocada en el proceso de Auditoria. En este parte Ud. aprender los conceptos bsicos y el proceso a seguir para realizar Auditoras de
Sistemas.
Tambin Ud. aprender a redactar Hallazgos de Auditoria as como informes de Auditoria, donde expresa
su opinin con respecto a una determinada materia o
situacin. L finalizar e esta Unidad revisaremos los principales Marcos de referencia de auditoria tanto nacionales como internacionales que utilizan los Auditores en
la ejecucin de su Auditoria.
En la Unidad II revisaremos la Auditoria al Gobierno y
Gestin de TI. En esta parte revisaremos el Gobierno
Corporativo y el Gobierno de TI, las diferencias entre
to de Sistemas y revisaremos algunas aplicaciones de

Negocio especficas que los Auditores suelen revisar. Al
finalizar esta Unidad revisaremos la Auditoria al Ciclo
de Vida de Desarrollo de Software y al Mantenimiento
de Software.
En la ltima Unidad nos enfocaremos en la Auditoria a
la Seguridad de la Informacin. Revisaremos las tcnicas y procedimientos de Seguridad de la Informacin y
Seguridad Informtica, enfocndonos en temas como
encriptacin, control de acceso, seguridad de Internet,
Cloud, Mviles, entre otros. Finalizaremos esta Unidad
con la Auditoria a la seguridad de la informacin
Espero que el curso sea de su provecho y que el contenido aporte su granito de arena para que lo ayude a Ud.
en un profesional ms completo. Y por qu no? Este
curso puede descubrir que Ud. podra ser un excelente
Auditor de Sistemas.
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
las reas deAutoevaluacin
Sistemas, a travs de la identificacin de los riesgos asociados a las tecnologas de informacin
Desarrollo en Actividades
de
encontenidos
las organizaciones de hoy; aplicando los principales estndares, normas, metodologas y mejores prcticas a nivel
mundial en auditoria de sistemas.
Glosario
UNIDADES DIDACTICAS
Lecturas
seleccionadas
Bibliografa
UNIDAD I
UNIDAD II
UNIDAD III
UNIDAD IV
Introduccin a la Auditoria de
Sistemas
Auditoria al Gobierno y Gestin

de TI
Auditoria al Ciclo de Vida de

desarrollo de Software
Auditoria a la seguridad de la
informacin
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
Recordatorio
Anotaciones
TIEMPO MINIMO DE ESTUDIO
Diagrama
Objetivos
Inicio

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

Lecturas
Diagrama
seleccionadas
Glosario
Objetivos
Bibliografa
Inicio
CONTENIDOS
Desarrollo
Recordatorio
de contenidos
Actividades
Anotaciones
Autoevaluacin
Lecturas
seleccionadas
Glosario
Bibliografa
EJEMPLOS
autoevaluacin
ACTIVIDADES
BIBLIOGRAFA

Recordatorio
Anotaciones
CONOCIMIENTOS
Video de presentacin de la asignatura
Unidad I: Introduccin a la Auditoria de
Sistemas
1 Videoclase (Video conferencia)
Tema N. 1: Tema 1
1. Visin de la Auditoria
2. Estndares de ISACA
3. El riesgo como elemento clave de la Auditoria de Sistemas
Tema N. 2: El proceso de Auditoria de
Sistemas
1. Planeamiento de Auditoria
2. Programa de Auditoria
Lectura seleccionada 1
Ttulo: Auditoria de Sistemas. Disponible en:
http://www.gerencie.com/auditoria-de-sistemas.html
PROCEDIMIENTOS
ACTITUDES
1. Infiere los procedimientos de auditora a

aplicar.
1. Valora la importancia de la ejecucin de

la auditoria de sistemas.
2. Participa en la definicin de los controles

para minimizar riesgos.
2. Se auto valora por su aprendizaje de las

tcnicas de auditoria de siste-mas.
3. Identifica las diferentes actividades en la

ejecucin de la Auditoria
3. Asume el compro-miso de revisar los

contenidos del manual.

planificacin de la Auditoria
4. Valora la importancia de la auditoria de

sistemas para el mejora-miento de una
empresa y para las actividades o procesos
a realizar.

ejecucin de la Auditoria
Actividad N. 1
Participan en el Foro de discusin sobre Los
riesgos originados por el uso de las Tecnologas de Informacin en las organizaciones.
5. Participa activa-mente en el desarrollo de

las actividades de la asignatura.
10
2 Videoclase
1. Identifica el riesgo y escribe hallazgos de

auditoria.
Tema N. 3: Hallazgos y observaciones de

Auditoria
2. Analiza y utiliza lo explicado en un caso

prctico.
1. Formulacin de los hallazgos de Auditoria
3. Identifica los estndares, las directrices y

las prcticas relacionadas.
2. Formulacin de recomendaciones para

minimizar los riesgos identificados
4. Identifica leyes, regulaciones y estn-dares

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 auditoria
Control de Lectura N 1
1. Marcos Internacionales: CobiT, Familia

ISO 27001.
Formula Observaciones de Auditoria del

caso Auditoria de Sistemas en una empresa
regional.
2. Marcos Nacionales: Contralora General

de la Repblica, Superintendencia de
Banca y Seguros.
Ttulo: CobiT5-Introduction-Spanish.
Disponible en: www.isaca.org/COBIT/Documents/COBIT5-Introduction-Spanish.ppt
Autoevaluacin N 1
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 tocaremos 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 Gerente 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 operativos 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 tecnolgicos 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 auditorias 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
11
12
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.
Dadotienen
que la
los
Auditores
son internos
la realizar
ventaja
de conocer
los Auditores son
internos
ventaja
de conocer
el negociotienen
y pueden
auditoras
ms detalladas. Una
el negocio
y caso
pueden
realizar
auditoras
msentre
detalladas.
desventaja
desventaja podra
ser que en
hubiese
algn tipo
de relacin
el AuditorUna
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
los laboran
Auditores
internos
el rea
Auditoriadel
Interna.
En Per los Auditores
internos
en el
rea de laboran
Auditoriaen
Interna.
En de
las Entidades
Estado laboran en las
EnInterno
las Entidades
Oficinas de Control
(OCI). del Estado laboran en las Oficinas de Control Interno
(OCI).
Auditoria
En este
caso,de
elAuditoria
Auditor pertenece
o equipoade
Auditoria Externa.
En esteExterna.
caso, el Auditor
o equipo
unaAuditoria
compaa perteexterna que tiene una
experiencia amplia
haber
auditado muchas
deuna
diversos
rubros. Como
una por
desventaja
nece por
a una
compaa
externacompaas
que tiene
experiencia
amplia
ha- se tiene que
la Auditoria Externa
podra sermuchas
menos detallada
ya que
cuentanComo
con ununa
periodo
de tiempo reducido
ber auditado
compaas
denormalmente
diversos rubros.
desven(semanas o pocos
paraque
realizar
la revisin.Externa podra ser menos detallada ya que
tajameses)
se tiene
la Auditoria
normalmente cuentan con un periodo de tiempo reducido (semanas o
pocos meses) para realizar la revisin.
1.4 Las Big Four.
Big Four.
Cuando1.4
una Las
empresa
requiere realizar una Auditoria Externa, es muy frecuente que las compaas contraten a una de
Cuando
unaque
empresa
realizar una Auditoria Externa, es muy frelas llamadas Big Four para
realicen requiere
la Auditoria.
cuente que las compaas contraten a una de las llamadas Big Four para que
realicen
la Auditoria.
Se llama Big Four
al conjunto
de las 4 compaas internacionales ms prestigiosas en el campo de la auditoria, tal como
se muestra enSe
el llama
grfico Big
1. Four al conjunto de las 4 compaas internacionales ms prestigiosas en el campo de la auditoria, tal como se muestra en el grfico 1.
Figura 1. Las Big Four.
Grfico
N 1 ms
Lasinformacin
Big Four. en las siguientes direcciones:
Si te interesa saber ms de estas compaas,
puedes obtener
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 & Young:
http://www.ey.com/PE/es/Services/Assurance
Ernst
& Young: 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
a las Tecnologas
La Auditoria relacionadas
de Sistemas se refiere
a la Auditoriade
de Informacin.
materias o situaciones relacionadas a las Tecnologas de InformaEl
auditor
de
Sistemas
tiene
el
negocio de encontrar riesgos. Veamos un
cin.
ejemplo: Imagina que te contratan como Auditor de Sistemas de una comy altiene
hacer
la revisin
un Servidor
Baseun
deejemplo:
Datos (todava
no saEl auditor depaa
Sistemas
el negocio
de de
encontrar
riesgos.de
Veamos
Imagina que
te contratan como
bes cmo
se compaa
hace, noyte
preocupes
aunde
por
encuentras
SerAuditor de Sistemas
de una
al hacer
la revisin
un eso),
Servidor
de Base de que
Datosdicho
(todava
no sabes cmo se
hace, no te preocupes aun por eso), encuentras que dicho Servidor no cuenta con Antivirus. Tambin encuentras que
9 que al Sistema
la contrasea del super usuario de la Base de datos no ha sido cambiada desde hace 3 aos y encuentras
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 super 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
UNIDAD I: Introduccin
Auditoria que
de Sistemas
fabricantea la
(Imagina
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.
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
Auditores de
Sistemas
estn
agrupados
en(ISACA).
gremios profesionales. A niprestigiosas es
la Information
System
Audit and
Control
Association
vel mundial una de las instituciones ms prestigiosas es la Information SysAudit and
Control
Association
(ISACA).
ISACA es unatem
institucin
con Sede
en Chicago,
Estados
Unidos, que agrupa a los profesionales de auditoria, control,
ISACA
institucin
con
en Chicago,
Estados Unidos,
que agrupa
riesgo y gobierno
dees
TI.una
Te invito
a que le
desSede
un vistazo
a esta institucin.
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
en http://www.isaca.org
Asimismo ISACA
es uno de las entidades certificadoras de profesionales ms importantes del mundo. Actualmente,
ISACAlasescuales
uno son:
de las entidades certificadoras de profesionales ms
ISACA ofreceAsimismo
4 certificaciones,
importantes del mundo. Actualmente, ISACA ofrece 4 certificaciones, las
cualesInformation
son:
CISA (Certified
Security Auditor)
CISA (Certified Information Security Auditor)
CISM (Certified
Information
Manager)
CISM
(CertifiedSecurity
Information
Security Manager)
CGEIT (Certified in the Governance of Enterprise IT)
CGEIT (Certified
in the
Governance
of Enterprise
IT)
CRISC
(Certified
in Risk
and Information
Systems Control)
CRISC (Certified
in Risk and
Control) la Certificacin que nos sirve es
Para Auditoria
deInformation
Sistemas, Systems
evidentemente
la CISA. Si a lo largo del curso, descubres que la Auditoria de Sistemas te inPara Auditoria
de Sistemas,
la Certificacin para
que nos
sirve es la CISA.
Si a entonces
lo largo deltu
curso, descubres
teresa
y ves evidentemente
que tienes competencias
identificar
riesgos,
que la Auditoria
de Sistemas
interesa
y ves que
tienes En
competencias
para identificar
riesgos,como
entonces
podras
ser untefuturo
Auditor
CISA.
la figura adjunta
te muestro
es tu podras ser
un futuro Auditor
CISA. En laCISA:
figura adjunta te muestro como es un certificado CISA:
un certificado
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-Inforhttp://www.isaca.org/Certification/CISA-Certified-Information-Systemsmation-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 aseguramiento 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!
13
14
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 aseguramiento 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 enfoque 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 apropiadas 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 informacin 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/Standards-for-IS-Audit-and-Assurance-Spanish.aspx
Asimismo, si deseas profundizar en el framework ITAF (en ingles) lo puedes encontrar en:
http://www.isaca.org/Knowledge-Center/Research/Documents/ITAF-3rd-Edition_fmk_Eng_1014.pdf
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 vulnerabilidad 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 considerada 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.
15
16
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 sensibles.
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 descubiertos 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 audita 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 realizado 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 ejemplo si vamos a auditar un Banco, entonces hay que entender las regulaciones definidas por la Superintendencia de
Banca y Seguros (SBS). Si vamos a auditar una compaa de electricidad hay que identificar la regulacin del Organismo 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.
17
18
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 procesos 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 tecnologas 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 anterior(es) y los papeles de trabajo que se utilizaron en dicha(s) auditoria(s). En ese (esos) documento(s) encontraremos 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 procesos 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 Auditoria. 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.
19
20
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 complementarias.
Ley N. 27170 Ley del Fondo Nacional de Financiamiento de la Actividad Empresarial del Estado-FONAFE, publicado el 09
de Setiembre de 1999.
Ley N. 24948 Ley de la Actividad Empresarial del Estado, publicada el 04 de diciembre de 1988.
Ley N. 26734 Ley que crea el rgano Superior de la 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 Ejecutiva 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 estructura 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.
21
22
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 superacin 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
23
24
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 seguridad, 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 planifique 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 (Microsoft) 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:
Cdigo empleado
Unidad
Organizacional
Nombres
Fecha de Cese
Mdulo SAP
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 mantienen 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 monitoreo 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 ambiental. As tenemos las siguientes debilidades:
- Se encontr que el Centro permanece a una temperatura no adecuada.
- Se encontr un extractor de aire no instalado.
- Todos los equipos del Centro de Datos se encontraba cubiertos de polvo, ya que para ventilar el ambiente se mantiene la ventana
del Centro que da la calle, permanentemente abierta.
- El Centro de Datos no cuenta con un falso piso no falso techo.
- Se cuenta con UPS individuales para cada servidor.
- No existe una bitcora de ingreso.
25
26
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 Informtica 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 recomendaciones deben ser escritas en forma clara y no deben escribirse recomendaciones que puedan significar un desembolso significativo de dinero por parte del Auditado.
Veamos los siguientes ejemplos de recomendaciones:
Tabla 1
Formulaci{on de recomendaciones
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 Gerencia 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

informtico
Evaluar la factibilidad de cambiar el 50% de las computadoras 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 compromete a cumplir con las recomendaciones de los hallazgos en una determinada fecha. Sin embargo, en algunas ocasiones 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
II. INTRODUCCIN
2. Origen del examen
3. Naturaleza y objetivos del examen
4. Alcance del examen
Otros aspectos de importancia
III. HALLAZGOS
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:
27
28
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 destacan 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 cumplimiento 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 actividades 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 comunicados; as como al plazo adicional otorgado a los mencionado funcionarios.
4. Otros aspectos de importancia
Por ser de importancia para los fines del presente informe, es preciso resaltar los siguientes hechos o circunstancias verificados durante
el desarrollo de esta accin de control posterior, relacionados con los objetivos de sta y con las situaciones evidenciadas en la Compaa:
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 Presupuesto. 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 DESASTRES 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.
29
30
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 actualizacin 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 ocurrencia 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 ACTIVIDADES 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 Compaa.
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 autorizado 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 monitoreo 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 Departamento de Informtica basa la ejecucin de sus actividades en un Plan de Actividades anual, el cual contiene la descripcin y cronograma de ejecucin de dichas actividades.
31
32
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 Compaia, 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 pblica 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 Sistema 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 aplicacin 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 Publico.
La Norma que gobierna las actividades de Auditoria son las Normas Generales de Control Gubernamental. Puedes encontrar las Normas Generales en: http://doc.contraloria.gob.pe/libros/2/pdf/RC_273_2014_CG.pdf . Si le das una leda, estas normas tienen muchos de los componentes que revisamos en el acpite 2.2 Estndares de ISACA del tema 1.
33
34
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 Comunicaciones (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 transparencia 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, Apellidos, 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 informacin 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/watch?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
35
36
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 actividades. 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
Gobierno de
Gestin.
Cubrir
totalmente la
empresa.
Principios
Habilitar
un enfoque
holstico.
Aplicar un
nico marco
de referencia
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 colectivamente, 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.
Asimismo, Cobit5 define 7 habilitadores. Este trmino algo extrao no es
ms que los factores que, individual y colectivamente, influyen sobre si algo 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,
optimicen
la inversin
en en
tecnologa
informacin as como su uso
un marco efectivo
de Gobierno
y Gestin
basado
los sietede
habilitadores,
en beneficio de las partespara
interesadas.
que juntos, optimicen la inversin en tecnologa de informacin as
como su
usode
en los
beneficio
de transcendentales
las partes interesadas.
Asimismo,
uno
temas
del CobiT es que separa el
Asimismo, uno de Gobierno
los temas transcendentales
del
CobiT
queDurante
separa elmuchos
Gobiernoaos
de TI se
de la
Gestin
de TI. Durante
de TI de la Gestin deesTI.
us
indistinmuchos aos se us
indistintamente
ambos
conceptos,
pero
ahora
se
tienen
claramente
diferenciados.
tamente ambos conceptos, pero ahora se tienen claramente diferenciados.
Gobierno de TI es la definicin de los objetivos de TI (en funcin de los obGobierno 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:
37
Figura 6 Mapa de Procesos de CobiT. Fuente: ISACA

36
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:
Figura 6. Mapa de Procesos de CobiT.

Fuente: ISACA
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 objetivos de TI.
Si deseas saber ms de CobiT5, te recomiendo el siguiente link: http://www.isaca.org/COBIT/Documents/COBIT5-Introduction-Spanish.ppt
2.3 Familia ISO 27000.
La Familia ISO 27000 es un conjunto de normas internacionales relacionadas a la seguridad de la 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
39
40
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 comnmente conocido como SGSI. La ISO 27001 define un conjunto de requisitos para establecer, implementar, mantener 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: AtenGMD,
Hermes
transportes
Hochschild
Minning PLC, In En el Per lato,
Norma
Tcnica
Peruana
Vigente esblindados,
la NTP ISO/IEC
27001:2014.
decopi, Oficina de Normalizacin Previsional ONP, PMC Latam, Secure
Soft, ms
Telefnica
del Per,enTelefnica
y Telefnica
Gestin
de Entre las que se
A la fecha existen
de 10 compaas
el Per queEmpresas
han obtenido
el certificado
ISO 27001.
Servicios
Compartidos
Per
SAC
pueden mencionar a: Atento, GMD, Hermes transportes blindados, Hochschild Minning PLC, Indecopi, Oficina de Normalizacin Previsional ONP, PMC Latam, Secure Soft, Telefnica del Per, Telefnica Empresas y
Cualquier
compaa
puede tomar
la decisin de certificarse. Existen
Telefnica Gestin
de Servicios
Compartidos
Per SAC
mecanismos de implementacin que requieren el apoyo de la Alta Ge Cualquier compaa
puede
tomar lade
decisin
de certificarse.
que rerencia. Un
ejemplo
la Certificacin
la Existen
puedesmecanismos
observar de
en implementacin
el siquieren el apoyo
de lagrfico:
Alta Gerencia. Un ejemplo de la Certificacin la puedes observar en el siguiente grfico:
guiente
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
a una compaa
que cuenta
el certificado
27001 conozca
es una Auditoria
especializa27001 de
esSistemas
una Auditoria
especializada
quecon
requiere
que elISO
Auditor
y
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 objetivo 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 cotizan 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 acciones siempre estuviese alta. Cuando sucede la quiebra de Enron sus acciones pasaron de costar USD 90 a costar USD
0.30, lo que signific un desastre financiero para sus accionistas. En realidad, Enron fue la gota que derramo el vaso,
toda vez que existieron otras quiebras como las de las 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 realizaban 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 independiente, 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 directivos, ejecutivos y empleados claves de la compaa y consorcios, en el caso de que posean ms de un 10% de acciones 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 financieras.
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 desde 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 instituciones 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.
41
42
2.6 PCI-DSS (Payment Card Industry Data Security Standar).

Las Normas de seguridad de datos de la industria de tarjetas de pago (PCI DSS) se desarrollaron para fomentar y mejorar la seguridad de los datos del titular de la tarjeta y facilitar la 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 todas 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 informacin para todo el personal.
Puedes visitar el sitio web de PCI en: https://www.pcisecuritystandards.org/
Asimismo,
la norma
est disponible en: https://es.pcisecuritystandards.org/minisite/en/pci-dss-v3-0.php
Diagrama
Objetivos
Inicio
Desarrollo
de contenidos
Actividades
Autoevaluacin
Lecturas
seleccionadas
Glosario
Bibliografa
Leer artculo: Auditoria de sistemas.

DSousa, C. (2008). Auditoria de sistemas [Sitio Web]. Disponible en: http://www.gerencie.com/auditoria-de-sistemas.htnl,
Recordatorio
Anotaciones
Diagrama
Objetivos
Inicio
Desarrollo
de contenidos
Actividades
ACTIVIDAD N. 1
Autoevaluacin
Participa en el Foro de discusin sobre Los riesgos originados por el uso de las Tecnologas de Informacin en las
organizaciones.
Lecturas
seleccionadas
Glosario
Bibliografa
INSTRUCCIONES
Lee y analiza un caso sobre riesgos originados por el uso de las TICs.
Recordatorio
Anotaciones
Objetivos
Inicio
Diagrama
Expresa
tus opiniones
en relacin al caso en el foro de discusin que se encuentra en el aula virtual.
Desarrollo
de contenidos
Actividades
Autoevaluacin
Lecturas
seleccionadas
Glosario
Bibliografa
Esta actividad puede consultarla en su Aula virtual.
Recordatorio
Anotaciones
os
UNIDAD I:Inicio
Introduccin a la Auditoria de Sistemas
Diagrama
Objetivos
Desarrollo
de contenidos
Actividades
Lecturas
seleccionadas
Glosario
Autoevaluacin
GLOSARIO DE LA UNIDAD I
Bibliografa
Amenaza: Es cualquier cosa que tenga el potencial de hacer dao.

Recordatorio
Anotaciones
Auditoria
de Sistemas: 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 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 mbito de la Auditoria de Sistemas.
Control: Es cualquier cosa que minimiza un riesgo. Por ejm. escribir un procedimiento, implementar un firewall, instalar un antivirus, ejecutar un respaldo (backup), etc.
Criterio. En el contexto de un hallazgo de Auditoria en el Sector Publico se refiere a la(s) norma(s) transgredida(s).
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
Inicio
Vulnerabilidad:
es cualquier deficiencia que tenga un activo informtico.
Actividades
Autoevaluacin
Glosario
Bibliografa
BIBLIOGRAFA DE LA UNIDAD I
Information systems audit and control association. (2016). CISA Re-view Manual. Chicago: ISACA.
Anotaciones
Information 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.
43
44
Objetivos
Inicio
AUTOEVALUACIN DE LA UNIDAD I
Actividades
Glosario
Anotaciones
Autoevaluacin
1. Ud. est planificando una auditoria al rea de Sistemas de la compaa farmacutica Pharmax. Al respecto, Cul
Bibliografa
de los siguientes NO sera parte de su planificacin de Auditoria?

A) Evaluacin del rea / tema de la auditora
B) 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 Gerente rea de Sistemas est malversando el presupuesto del rea ya que todos los contratos de desarrollo de software
los gana un nico proveedor y este proveedor deja los proyectos inconclusos y aun as, el Gerente 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 compaa 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 acceso 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 contrato 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 Comunicaciones Unificadas.
5. Ud. comprende la importancia de gobernar y gestionar adecuadamente las tecnologas de Informacin. Al respecto. 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
45
46
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 cumplir 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 manera pblica.
D) El derecho de Rectificacin se refiere a que un ciudadano pueda solicitar a una compaa que elimine completamente los datos personales de dicho ciudadano.
10. Una importante grupo industrial que cotiza en la Bolsa de USA ha decidido instalar su oficina principal de Latinoamrica 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
Diagrama
Objetivos
Inicio

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

Lecturas
Diagrama
seleccionadas
Glosario
Objetivos
Bibliografa
Inicio
CONTENIDOS
Desarrollo
Recordatorio
de contenidos
Actividades
Anotaciones
Autoevaluacin
Lecturas
seleccionadas
Glosario
Bibliografa
EJEMPLOS
autoevaluacin
ACTIVIDADES
BIBLIOGRAFA

Recordatorio
Anotaciones
CONOCIMIENTOS
Tema N. 1: Gobierno y Gestin de TI
1. Gobierno Corporativo y Gobierno de TI
2. Practicas Gerenciales de Gestin de TI
3. Auditora al Gobierno y a la Gestin de TI
Lectura seleccionada 1 :
PROCEDIMIENTOS
1. Identifica el gobierno (governance)
corporativo y su relacin con el gobierno
de TI.
2. Formula la estrategia de TI.
3. Identifica el rbol normativo de TI.
4. Aplica las prcticas de inversin y asignacin de recursos.
De gerente de TI a CIO, una evolucin necesaria en el Per
5. Conocimiento de la estructura organizacional, los roles y las responsabilidades

relacionadas con TI.
http://www.esan.edu.pe/conexion/actualidad/2011/11/14/de-gerente-de-ti-a-cio-unaevolucion-necesaria-en-el-peru/
6. Participa en la redaccin de hallazgos

relacionadas al Gobierno y la Gestin de
TI.
Actividad N. 2
Participan en el Foro de discusin sobre las
prcticas gerenciales en el rea de Sistemas.
4 Videoclase
Tema N. 2: Continuidad de Negocio y
Recuperacin de Desastres
1. Gestin de la Continuidad de Negocio
2. Planeacin a la Continuidad de Negocio y
Recuperacin de Desastres
3. Auditoria a la Continuidad de negocio
4. Formulacin del Informe de Auditoria
Ttulo: Lecciones aprendidas para la recuperacin de desastres tras el 9/11
http://www.pcworld.com.mx/Articulos/18319.htm
Autoevaluacin N 2
1. Identifica los riesgos relacionados a la

continuidad de negocio.
2. Identifica los pasos de la ejecucin de un
plan de continuidad de Negocio.
3. Formula hallazgos de auditoria de Sistemas tomando como base los riesgos de la
continuidad de negocio.
Tarea Acadmica N 1
Realiza una Auditoria al caso Recuperacin
de Desastres.
ACTITUDES
tcnicas de auditoria de siste-mas.
a realizar.
5. Participa activamente en el desarrollo de
47
48
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 aprenderemos 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 controla una empresa) la direccin y la administracin de la empresa, a travs de la definicin y separacin de roles estratgicos, 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 Gobierno 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 sociedades, promueve un clima de respeto a los derechos de los accionistas y de los inversionistas en general; contribuye a
generar valor, solidez y eficiencia en las sociedades; trae consigo una mejor 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 Gobierno Corporativo para las sociedades peruanas. Lo puedes encontrar en: http://www.smv.gob.pe/Uploads/CodBGC2013%20_2_.pdf
1.2 Gobierno de TI
Del concepto de Gobierno Corporativo se desprende el concepto de Gobierno de 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
o metas
estratgicas.
Es ms, TI tiene
la obligacin de aporta
UNIDAD II: Auditoria
al Gobierno
y Gestin
de TI
49
valor al negocio.
Al implementar Gobierno de TI, la gerencia general y la gerencia de TI dan

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
y control
del
rea
y gestionando
losderiesgos
relacionados
de TI. Histricamente
las reas
de TI se han
visto
como de
reasTI
de Soporte
Tcnico. El rea
TI debe sacudirse
de
esta forma
de
ser
percibida
y
ser
una
rea
que
ofrece
servicios
que
otorgan
valor
al
negocio,
ya
que
la
forma
cmo
las
con la tecnologa. Los Gerentes de TI exitosos entienden y manejan los riesT.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.
ISACA define al Gobierno de TI como el liderazgo, estructuras y procesos organizacionales que garantizan que la TI
el impulso
TI cumpla
con
los objetivos de la compaa. Para
de la empresa
sostiene y para
extiendeque
las estrategias
y objetivos
organizacionales.
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 trasparencia 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.

Para Implementar el Gobierno de TI existen 2 marcos de
referencia principales.
Evidentemente, el primer marco es el
Fuente:
ISACA.
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,
Implementacin
del
Gobierno
de compaa.
TI.
pueda
dirigir y monitorizar
el uso
de las TI en una
Para Implementar el Gobierno de TI existen 2 marcos de referencia principa

les. Evidentemente, el primer marco es el Cobit5 (Recuerde que el CobiT5
permitedeimplementar
Gobierno y Gestin de TI). El segundo marco es la
2.1 Planeamiento
TI
norma ISO/IEC 38500 Corporate Governance of Information technology
2.1.1 Plan
queEstratgico
es un Empresarial
conjunto(PEE).
de principios para que la Gerencia pueda evaluar, dirigir
y monitorizar
el uso
de las
TI en
una
compaa.
Las
compaas para lograr
sus objetivos
primero
deben
pasar
por un procesos de definicin mediante un Pla2 Practicas Gerenciales de Gestin de TI
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.
50
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 presentaremos 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 negocio. Si un rea de TI no est orientado a ese logro, los objetivos de TI sern puramente tcnicos y no necesariamente 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 Soporte 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:
51
Elaborado
por:
52
Revisado por:
Aprobado por:
Fecha de EmiUNIDAD II: sin:

Auditoria al Gobierno y Gestin de TI
1. PROPSITO
Instalacin de la solucin para realizar copias de seguridad y recu1. PROPSITO
peracin de archivos en los equipos de la compaa.
Instalacin
la solucin para realizar copias de seguridad y recuperacin de archivos en los equipos de la compa2. de
ALCANCE
a. Inicia con la ejecucin de la consola de administracin de RESPALDO
AUTOMTICO DE INFORMACIN y finaliza con el registro del moni2. ALCANCE
toreo en el formato asociado correspondiente.
ACTIVIDADES
Inicia 3.
con laDESCRIPCIN
ejecucin de la consola DE
de administracin
de RESPALDO AUTOMTICO DE INFORMACIN y finaliza 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
deRESPALDO
teclas Windows
+R
mostrara la
ventana
3.1 Para encontrarcombinacin
los instaladores de
AUTOMTICO
DEse
INFORMACIN
para
equipos Windows
, por la ruta
Buscar.
En
el
cuadro
escribimos
la
ruta
\\SERVIDOR08
realizamos la combinacin de teclas Windows + R se mostrara la ventana Buscar. En el cuadro escribimos
\\SERVIDOR08ultimo
, por ultimo
aceptamos como
indica
la secuencia
de la Figura1. de la Imagen 1.
aceptamos
como
indica
la secuencia
3.2
Ingresamos a la carpeta instaladores como se muestra en

la Imagen 2.
Imagen
Figura 1 1
3.2
Ingresamos
a la carpeta
instaladores
como se muestra en
3.2 Ingresamos
a la carpeta instaladores
como se muestra
en la Figura2.
la Imagen 2.
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
2 haciendo
3.3 Una vez dentro ingresamos a la carpeta Imagen
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
Imagen 3
3.4
Figura 3
Hacer click al archivo Setup.exe para comenzar la instalacin del RESPALDO AUTOMTICO
Imagen DE
3 INFORMACIN
3.4
Hacer click al archivo Setup.exe para comenzar la instalacin del RESPALDO AUTOMTICO DE INFORMACIN
Imagen 4
Imagen 3
3.4
Hacer click al archivo Setup.exe para comenzar la instalacin del RESPALDO AUTOMTICO DE INFORMACIN
3.4 Hacer click al archivo Setup.exe para comenzar la instalacin del RESPALDO AUTOMTICO DE INFORMACIN
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 contener pantallazos para que el usuario pueda seguirlo y cumplir con los
pasos
indicados.
2.3 Practicas
Gerenciales de RRHH
ElGerenciales
Gerente de TI enfocado
en que se logren los objetivos de TI alineados con los objetivos del Negocio, debe preocuPracticas
de RRHH
parse de contar con los mejores profesionales. Son las personas las que hacen que las cosas sucedan y son las personas
el factor
determinante
para
logrose
de los
objetivos.
El Gerente
de TI
enfocado
enelque
logren
los objetivos de TI alineados con
os objetivos del Negocio, debe preocuparse de contar con los mejores proParaSon
ello ellas
gerente
de TI debe
a las mejores
relacionadas
a la ygente.
esionales.
personas
lasrecurrir
que hacen
que prcticas
las cosas
sucedan
son las
personas el factor determinante para el logro de los objetivos.
Para ello2.3.1
el gerente
decontratacin.
TI debe recurrir a las mejores prcticas relacionadas
Prcticas de
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 candidatos 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 antecedentes 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 originar un riesgo para la compaa. Su in candidato no honra sus deudas o est atravesando problemas financieros, 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 talentosos siempre estn buscando retos que valgan la pena.
53
54
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 completa. Cuando una persona controla un proceso completo, hay mucha probabilidad de que esa persona cometa
un acto ilegal tarde o temprano. Al controlar un proceso completo, la persona se podra ver tentada de hacer
trampa.
Veamos un ejemplo: Suponga que Ud. es programador de la Municipalidad del distrito donde vive. Ud tiene acceso a los programas fuentes del Sistema 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 funciones 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 inmediatamente 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 relacionadas 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 infraestructura 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 determinado 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
de Nivel
de Servicio
por En
sus siglas
en espaol.
no haya
cortes
en el (ANS),
servicio.
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
enno
el cual
el proveedor
se compromete
a garantizar
un determinado
nivel
esto
es as.
Si e proveedor
nos ofrece
un SLA
de 99.95%
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 servidas. 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
ser inaceptable.
significarapodra
que nosotros
toleraramos cortes al ao que representan como mximo el 0.05%. El 0.05% de 365 das son
Si
el
proveedor
nos
ofrece
un SLA de 99.999%, esto significa que tolerara18 das. Esto es inaceptable para
una
compaa.
mos un corte de 8 horas al ao.
mejor
es el un
SLA,
seresto
el servicio
y evidentemente,
el serviEn cambio,Mientras
el proveedor
nos ofrece
SLAmejor
de 99.99%,
significa que
toleraramos un corte
de 3.65 dias. Depencio
se
encarece
ya
que
el
proveedor
tendr
que
invertir
ms
en
sistemas
de
diendo del tipo de compaa, esto podra ser inaceptable.
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 en
sistemas deaspecto
contingencia.
importante
que un Gerente debe gestionar es velar que la tecnologa 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 Archivos est
al 90%
deGerente
utilizacin.
Otro importante
aspecto
que un
debe gestionar es velar que la tecnologa siempre responda a las necesidades
Para
evitar
esto,
hay
que suceder
estar continuamente
monitoreando
la capacidad
de los usuarios se
del Negocio. Por ejemplo nunca debera
que nos quedemos
sin espacio de disco
duro, ni que
tecnologa
posibles
y tomar
decisiones de
queden sinla
ancho
de bandayo adelantarse
que el CPU delaServidor
de circunstancias
Archivos est al 90%
de utilizacin.
renovar la tecnologa o ampliar la capacidad.
Para evitar Ampliar
esto, hay la
quecapacidad
estar continuamente
monitoreando
capacidad
desila nos
tecnologa
y adelantarse
a posibles
significa adquirir
ms la
GB
de disco
estamos
quecircunstancias
y tomar
renovar podra
la tecnologa
o ampliar
la capacidad.
dando
sin decisiones
espacio. de
Tambin
significar
adquirir
ms memoria RAM si la
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 significar adquirirVeamos
ms memoria
RAM si laTenemos
memoria est
quedando
corta.
Esto
debe hacerse un
de manera
planificada
un ejemplo.
una
compaa
que
experimenta
importante
incremento en ventas en el mes de mayo. SI el Gerente de T.I. realiza un

Veamos unproceso
ejemplo. de
Tenemos
una compaa
que experimenta
un importante
incremento
en ventas en el mes de
monitoreo
de la capacidad,
el grafico
de utilizacin
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 se puede
observar
en elobservar
ejemplo, elen
usoelde
la memoria
aumentando
desde mayo
hasta julio y que de seguir
Como
se puede
ejemplo,
el va
uso
de la memoria
va aumentanas nos quedaremos
sin
memoria
en
el
mes
de
setiembre.
do desde mayo hasta julio y que de seguir as nos quedaremos sin memoria
en el mes de setiembre.
55
Por otro lado, la gestin de la capacidad tambin tiene que ver con no com
56
prar
ms de lo necesario. Imagine
que compramos
un nuevo servidor con
32GB de RAM. Se instala el software y el software consume 8 GB casi de
manera consistente. Qu pasara con los otros 24GB no utilizados? Pues
son Por
capital
muerto,
esla decir
son
soles
que gastamos
y no
utili-que
otro lado,
la gestin de
capacidad
tambin
tiene(o
que dlares)
ver con no comprar
ms de lo necesario.
Imagine
compramos
un
nuevo
servidor
con
32GB
de
RAM.
Se
instala
el
software
y
el
software
consume
8
GB
casi
de
manera
zamos.
consistente. Qu pasara con los otros 24GB no utilizados? Pues son capital muerto, es decir son soles (o dlares) que
gastamos y no utilizamos.
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!
ello, el
el Gerente
de TIde
debeTI
realizar
encuestas
de satisfaccin
peridicas
saber de primera
mano cual es el
ParaPara
ello,
Gerente
debe
realizar
encuestas
depara
satisfaccin
peridicas
grado de satisfaccin de los usuarios con el servicio ofrecido por el rea de TI.
para
A continuacin,
presentaremos
ejemplo de encuesta:
A continuacin, presentaremos
un ejemploun
de encuesta:
Figura 2-Figura
Ejemplo
de
encuesta.
10. Ejemplo de
encuesta.
Fuente:
Elaboracin
propia.
Fuente: Elaboracin propia.
2.7 Benchmarking.
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-
cida del pas, de la regin

mundial.
El benchmarking
es ouna
tcnica de mejora continua. Consiste en comparar
una En
materia
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
En el Per esta
es una prctica
establecida
debido a que las compaas no comparten informacin entre ellas.
reconocida
delnopas,
de la muy
regin
o mundial.
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 Corparaporativo,
que un
Gerente
Ti mejore
gestin.
comparten
muchade
informacin
la cual su
puede
ser aprovechada para hacer benchmarking.
En el Per esta no es una prctica muy establecida debido a que las compaas2.8
noGestin
comparten
de cambios informacin entre ellas. Pero en otros pases como en Estados
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 informque ticos
el modelo
ensistemas
Estados
Unidos
es que
compaas
estn
en acson complejos
que estn
funcionando
en la las
Compaa.
En su definicin
msbasadas
simple, un Sistema
es un
conjunto de
partes
y que interactan
con el propsito
de lograr un objetivo,
En este orden
de ideas,
cionistas,
por
lainterrelacionadas
transparencia
del Gobierno
Corporativo,
comparten
mucha
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-
logran de
otra cambios
cosa. Estas situaciones se originan cuando se realizan cambios a los sistemas y estos cambios impactan en
Gestin
alguna otra parte, lo cual impacta a los usuarios de dicho Sistema.
El rea de TI maneja por su propia naturaleza muchos Sistemas. La infraestructura 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 Cambio (Change Advisory Board CAB por sus siglas en ingles).
Veamos un ejemplo de un RFC:
Requerimiento para Cambio

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

Nombre:
Luis____________
Apellidos:
Iberico__________
Correo:
rea:
Tel.:
a@compaia.com____
Seguridad
IT_________________
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 posibilidad 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:
Servicio
Componentes Impactados:
Antivirus Symantec de Per.
Urgencia
o Emergencia
(Hasta 2 ventanas)
(Mismo
Da)
o Baja
O Media
(Mnimo 2 ventanas)
X Alta
(Inmediata)
Impacto
Urgencia
o Alto
Alto
Impacto
Medio
Bajo
Alta
Media
1
2
2
3
3
3
Baja
o Bajo
Prioridad = Urgencia x Impacto
1: Emergencia
2: Alta
3: Significante
4: Baja Estndar
Consideraciones de Interrupcin de Servicio:
X Medio
57
58
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 utilizado por los usuarios de todas las reas. Entonces, si lo utilizan todas las reas, Por qu solo lo debe pagar T.I.?
Si no hay una adecuada 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 considerar 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 situaciones 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
59
60
- 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
Objetivos
Inicio
Diagrama
- Los
presupuestos
de las reas no consideran los gastos de tecnologa
- Todos los gastos de tecnologa son cargados a TI
Desarrollo
de contenidos
Actividades
Autoevaluacin
Lecturas
seleccionadas
Glosario
Bibliografa
Leer artculo: De gerente de TI a CIO, una evolucin necesaria en el Per

Recordatorio
Anotaciones
Santana
Ormeo, 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 procesos 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 ocurrencia 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 organizacin, 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 & Organizational Continuity.
61
quede inoperativa por un periodo de tiempo que impacte adversamente sus operaciones. Estas interrupciones obligan a la compaa a
tomar acciones para recuperar el estado operativo en el que estaba
antes del desastre.
62
El origen de los desastres puede ser:

a) Naturales. Como por ejemplo terremotos, tsunamis, inundaciones,
huaicos, huracanes, etc.
Tecnolgicos.
esteque
tipo
decompaa
desastres
tenemos
apagones,
Los desastres sonb)
interrupciones
que Entre
ocasionan
una
quede
inoperativa
por un periodo de tiempo que
impacte adversamente
sus operaciones.
Estas
obligan
malware,
fallas en
la interrupciones
infraestructura,
etc.a la compaa a tomar acciones para recuperar el
estado operativo c)
en elHumanos.
que estaba Por
antesejemplo
del desastre.
un incendio provocado por un atentado,
una huelga, entre otros.
El origen de los desastres puede ser:
1.4 Desastres
a) Naturales. Como
por ejemplo
terremotos,
tsunamis,Ainundaciones,
huaicos,
huracanes,
etc.
Ejemplos
de desastres
abundan.
nivel mundial
tenemos,
solo por
derrumbe
de las
torres fallas
gemelas
Nueva
b) Tecnolgicos.citar
Entrealgunos
este tipoejemplos:
de desastres el
tenemos
apagones,
malware,
en la en
infraestructura,
etc.
York, el tsunami en el sudeste asitico, la epidemia SARS, el apagn
c) Humanos. Por
un incendio
provocado
unyatentado,
entre otros.
a ejemplo
gran escala
en el Noreste
depor
USA
Canad,una
loshuelga,
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
etc.
gemelas en Nueva
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 FenEl Per no es ajeno
a losdel
desastres.
Por ejemplo
tenemos
al Fenmeno
Nio que causa
lluvias torrenciales e inunmeno
Nio que
causa lluvias
torrenciales
e del
inundaciones
cada
daciones cada cierto
nmero
de
aos.
cierto nmero de aos.
Seguramente
Ud. recuerda
el el
terremoto
el ao
2007.
Ese compaas entre las
Seguramente Ud. recuerda el terremoto
en Pisco
ao 2007. en
EsePisco
terremoto
afect
a muchas
terremoto
afect
a
muchas
compaas
entre
las
cuales
figuran
emcuales figuran empresas de telecomunicaciones que al verse afectadas, afectaron a sus clientes.
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 comuclientes.
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.
Nextel.
Figura 1 Situacin de la torre deFuente:
comunicaciones
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
13. Vista
lateral
de la torre de
de la compaa Nextel en el terremoto de Pisco.
Nextel
en el
terremoto
decomunicaciones
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 preparados.
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 desastre 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
63
64
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 desastre. 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.
definido
Relacin
entre
los detiempos
la recuperacin
desas UnaFigura
vez que se3
han
los procesos
crticos
negocio y lasde
mtricas
de recuperacin, el de
siguiente
paso es
seleccionar una de las estrategias de recuperacin. En T.I es imposible hablar de recuperacin, si es que no se tiene
tres.
un Centro de Datos de Respaldo.
Fuente: Elaboracin propia
Existen 5 estrategias de recuperacin:
Alta Disponibilidad.
Tambin conocida como High Avalilability (HA). Esta estrategia es utilizada cuando el
b) Estrategias
de recuperacin.
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
el Centro
de Datos
de Respaldo.
Unaen vez
que
se han
definido los procesos crticos de negocio y las
mtricas
de recuperacin,
el Datos
siguiente
paso
es seleccionar
dela replilas
Hot Site. Consiste
en tener un Centro de
alterno similar
al Centro
de Datos principaluna
pero sin
cacin de los datos
en tiempo real.
estrategias
de recuperacin.
En T.I es imposible hablar de recuperacin,
siSite.
es Esque
no se
tiene
Centroparcial
de Datos
deal Respaldo.
Warm
un Centro
de Datos
conun
equipamiento
o inferiores
Centro de Datos principal. Por
ejemplo5
si una
compaa hacede
renovacin
tecnolgica de servidores, los servidores antiguoes pueden ser
Existen
estrategias
recuperacin:
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 realizar la recuperacin.
Acuerdo reciproco. Esta es una estrategia a utilizar cuando la compaa no cuenta con recursos para implementar 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 transportado 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 organizacin
Los Nmeros de telfonos y direcciones del personal crtico, de los proveedores, de los agentes de las compaas 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
65
66
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
67
68
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
Desarrollo
de contenidos
Inicio
Objetivos
Plan desactualizado
Actividades
Autoevaluacin
Lecturas
seleccionadas
Glosario
Bibliografa
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:
Recordatorio
Anotaciones
http://www.pcworld.com.mx/Articulos/18319.html,
Diagrama
Objetivos
Desarrollo
de contenidos
Actividades
Inicio
ACTIVIDAD N. 2
Autoevaluacin
Participa en el Foro de discusin sobre las Prcticas gerenciales en el rea de Sistemas.

Lecturas
seleccionadas
Glosario
Bibliografa
INSTRUCCIONES
Revisa las prcticas gerenciales del rea de Sistemas expuestas en el tema 1.
Recordatorio
Anotaciones
Formula un ensayo sobre si est de acuerdo o no con las prcticas gerenciales mencionadas. Asimismo, plantea nuevas
Diagrama
Objetivos
Inicio que a su juicio deben ser revisadas por un Auditor de Sistemas.
prcticas
gerenciales
Desarrollo
de contenidos
Actividades
Autoevaluacin
TAREA ACADEMICA N. 1
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
Bibliografa
Esta actividad puede consultarla en su Aula virtual.
os
Diagrama
Objetivos
Desarrollo
de contenidos
Actividades
Lecturas
seleccionadas
Glosario
Inicio
UNIDAD
II: Auditoria al Gobierno y Gestin de TI
Autoevaluacin
GLOSARIO DE LA UNIDAD II
Bibliografa
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.
Recordatorio
Anotaciones
BIA. Acrnimo de Business Impact Analysis. Es una fase del proceso de Continuidad de Negocio en donde se identifican 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 comunicacin 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
Inicio
Stand-Alone.
Equipo informtico (PC o laptop) que no cuenta con acceso a la red, funcionando de manera individual.
Actividades
Autoevaluacin
Glosario
Bibliografa
BIBLIOGRAFA DE LA UNIDAD II
Anotaciones
69
70
Objetivos
Inicio
AUTOEVALUACIN DE LA UNIDAD II
Actividades
Glosario
Autoevaluacin
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
Bibliografa
Cul es el mecanismo ms eficaz que Ud. recomendara como auditor para atender y priorizar las distintas necesidades de las reas usuarias?

A) Gestin de Proyectos
B) Plan Estratgico
C) Comit de Sistemas
D) Evaluacin de desempeo
Anotaciones
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 aplicaciones 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 situacin 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 auditor al revisar este documento es que el PETI debe:

A) Orientarse al logro de los objetivos de la empresa
B) Reducir eficientemente los costos
C) Contar con la lista de proyectos de sistemas
D) Contar con un 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
71
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.
Diagrama
Objetivos
Inicio

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

Lecturas
Diagrama
seleccionadas
Glosario
Objetivos
Bibliografa
Inicio
CONTENIDOS
Desarrollo
Recordatorio
de contenidos
Actividades
Anotaciones
EJEMPLOS
Autoevaluacin
autoevaluacin
Lecturas
seleccionadas
ACTIVIDADES
Glosario
BIBLIOGRAFA
Bibliografa

Recordatorio
Anotaciones
CONOCIMIENTOS
Tema N. 1: Etapas del ciclo de vida de Desarrollo de Software
1. Etapas del ciclo de vida
2. Controles de entrada, procesamiento y
salida en el Software
Tema N. 2: Mantenimiento de Sistemas
1. Procedimiento de control de cambios
Lectura seleccionada 1:
Ttulo: Ciclo de Vida del Software. disponible en: http://static.ccm2.net/es.ccm.net/
contents/pdf/ciclo-de-vida-del-software-223k8u3gm.pdf
6 Videoclase
PROCEDIMIENTOS
1. Identifica los riesgos de cada una de las
fases del ciclo de vida de desarrollo de
sistemas.
2. Identifica las metodologas y prcticas de
pruebas relacionadas con el desarrollo de
sistemas de informacin.
3. Identifica los procedimientos de cambios
en los sistemas
4. Aplica los controles en el software.
Actividad N. 3
Participan en el Foro de discusin sobre las
riesgos en el desarrollo de software.
Tema N. 3: Aplicaciones de Negocio
1. Identifica los principales componentes de

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 Sistemas sobre el ciclo de vida y el mantenimiento de sistemas.
3. Control del producto No conforme

4. Anlisis de datos. Mejora
Tema N. 4: Auditoria al ciclo de vida
1. Auditora a ciclo de vida de desarrollo
2. Auditora al mantenimiento de Sistemas
Ttulo: Qu es big data?. Disponible en:
https://www.ibm.com/developerworks/ssa/
local/im/que-es-big-data/
Autoevaluacin N 3
Control de Lectura N 2
Evaluacin escrita de los temas N. 1,2,3, y 4 ,
ms los contenidos de las lecturas seleccionadas 1 y 2 de la Unidad III.
ACTITUDES
tcnicas de auditoria de sistemas.
a realizar.
73
En este tema abordaremos el amplio mundo del desarrollo del softwar

Auditora al Ciclo
Vida de
desarrollo de Software
compaas
gastan cientos de miles UNIDAD
de III:
dlares
en delos
procesos
de desarro
74
software y es conocido que todo desarrollo de software conlleva riesgo
cuales deben ser revisados adecuadamente por los Auditores de Sist
Tambin
abordaremos
eldemantenimiento
de Sistemas y los procedimientos q
TEMA N.
1: Etapas del Ciclo
Vida
Auditores toman en cuenta para asegurar que los cambios al software ex
no introduzcan nuevos riesgos a las compaas.
INTRODUCCIN
1.
En este tema abordaremos el amplio mundo del desarrollo del software. Las compaas gastan cientos de miles de
Ciclo
de Vida de Desarrollo de Software
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
Sistemas y los procedimientos que los Auditores toman en cuenta para asegurar que los cambios al software existente
1.1
Etapas
de Vida Tradicional
no introduzcan
nuevosdel
riesgosCiclo
a las compaas.
Muchas compaas utilizan el Ciclo de Vida tradicional para el de

del software. Este ciclo de vida ha sido utilizado durante muchos
1.1 Etapases
del Ciclo
de Vida
Tradicional que un Auditor de Sistemas se tope con este
muy
probable
vida. utilizan
El Ciclo
de
Vida
tradicional
consta
de Este
fases
secuenciales,
tal
Muchas compaas
el Ciclo
de Vida
tradicional
para el desarrollo
del software.
ciclo de
vida ha sido utilizado durante muchos aos y es muy probable que un Auditor de Sistemas se tope con este ciclo de vida. El Ciclo de Vida
muestra en la figura 1.
tradicional consta de fases secuenciales, tal como se muestra en la figura 1.
1 Ciclo de Vida de Desarrollo de Software
Figura .16. Etapas genricas del Ciclo de Vida de Desarrollo de Software.
Figura
1enla Etapas
genricas
Ciclo
de Vida
de Desarrollo
Como se puede
apreciar
figura 1, el Ciclo
de Vida consideradel
actividades
de adquisicin
de software.
Ud. podra
preguntarse
qu
hace
la
adquisicin
en
un
ciclo
de
vida
de
desarrollo.
Esto
es
lgico
ya
que
mucho
del
software
ya se
Software.
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 relacionados 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 Information (RFI) y enviarlo a proveedores. Este documento solicita a los proveedores que indiquen las capacidades
que tienen sus sistemas y nos permite tener una idea inicial de que existe en el mercado y cunto tiempo y dinero
costara.
Escribir el Business Case (Caso de Negocio). El Business Case es un documento importante en el que se deben definir 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 decisin 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 Requerimientos). Dado que el software a construir es intangible (no se puede tocar, no se puede sentir), no es lo mismo
construir software que construir un tangible como por ejemplo un edificio.
Muchos de los proyectos de desarrollo de software fracasan por que no se logra un entendimiento claro de los requerimientos de los usuarios, por lo que es vital la 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.
75
76
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 evaluadas 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 codificacin 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 conceptualizar desarrollo sin pruebas. Las pruebas son inherentes al desarrollo (por ese motivo no existe una fase de pruebas).
Una pregunta que se debe hacer en esta fase es: 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 correcciones 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 comparar 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 documentar 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 adquirir un software). En esta etapa se adecua el software para que funcione segn los requerimientos de la Compaa.
77
78
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 configurar y personalizar el software.
En esta fase, cabe la pena preguntarse: Hay que adecuar el software a la compaa o adecuar la compaa al software? 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 embargo es vital que se considere la fase de Revisin de Post-Implementacin. Esta revisin es una oportunidad no aprovechada 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 componen 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 incorrectos, 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 predeterminadas. 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 ingresando.
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 mecanismo de clculo para verificar el resultado. Por ejemplo verificando que el resultado de un clculo con una comprobacin 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:
79
80
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, formateados 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, cheques, 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 crdito con asteriscos.
Manejo de Errores en las Salidas. El Sistema debe tener controles para evitar que no se emita un y que ningn reporte 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 software. 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 adversamente en el servicio ofrecido por IT.
Entonces, queda claro que se necesita un proceso de control de cambios en el cual todo cambio requiere de una serie
de actividades y controles hasta que el cambio finalmente pasa a 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.
81
82
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 documentacin 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
Desarrollo
de contenidos
Objetivos
UNIDAD
III:Inicio
Auditora al Ciclo de Vida de desarrollo de Software
Actividades
Autoevaluacin
Lecturas
seleccionadas
Glosario
Bibliografa
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/conRecordatorio
Anotaciones
tents/pdf/ciclo-de-vida-del-software-223-k8u3gm.pdf
Diagrama
Objetivos
Desarrollo
de contenidos
Actividades
Inicio
ACTIVIDAD N. 3
Lecturas
seleccionadas
Autoevaluacin
Participan en el Foro de discusin sobre los Riesgos de desarrollo de software.

Glosario
Bibliografa
INSTRUCCIONES
1. Revisa los temas 1 y 2 y la lectura seleccionada.
Recordatorio
Anotaciones
2. Lee las instrucciones en el Aula Virtual.

3. Participa en el foro de discusin sobre los riesgos de desarrollo de software.
83
84
TEMA N. 3: Aplicaciones de Negocio

INTRODUCCIN
Este tema est enfocado en analizar algunas Aplicaciones de Negocio verticales comunes que comnmente son revisadas 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 aplicaciones 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 incluso millones clientes. El lder de este sector es www.amazon.com quien reinventa este sector con cientos de innovaciones.
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 personal 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 termina 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 conversan 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 proveedores. La tarea de emitir rdenes de Compra para comprar a los proveedores los diversos productos a medida que
se van agotando de los stocks 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 funcin 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 protocolo 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 proteccin 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 intervalos predeterminados.
85
86
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 pagar 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, Financiera 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 momento 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 obtener 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 generan 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 problema 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 cantidad 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
87
88
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 desarrollar 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 procesos 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.
89
90
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 documentacin.
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 objetos fuente y ejecutables
Existencia de cambios sin documentacin.
Diagrama
Objetivos
Inicio
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.
Desarrollo
de contenidos
Actividades
Autoevaluacin
Lecturas
seleccionadas
Glosario
Bibliografa
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/,
Recordatorio
Anotaciones
X
Y (20xy).
os
Diagrama
Desarrollo
de contenidos
Objetivos
UNIDAD
III:Inicio
Auditora al Ciclo de Vida de desarrollo de Software
Actividades
Autoevaluacin
Diagrama
Objetivos
Lecturas
seleccionadas
Inicio
Glosario
Bibliografa
Esta actividad
puede
consultarla en su Aula virtual.
Desarrollo
de contenidos
Actividades
Recordatorio
Lecturas
seleccionadas
Glosario
Autoevaluacin
Anotaciones
GLOSARIO DE LA UNIDAD III

Bibliografa
Big data: Se refiere a la disciplina de recoleccin, almacenamiento, bsqueda, comparticin, anlisis, y visualizacin de
grandes cantidades de informacin.
Recordatorio
Anotaciones
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 software 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 Tecnologa 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 recoger 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 proveedores 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 proceso 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.
Objetivos
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
Inicio
plano
del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programacin, esquemas de bases de datos y reciclaje de
componentes.
Actividades
Autoevaluacin
Glosario
Bibliografa
BIBLIOGRAFA DE LA UNIDAD III

Anotaciones
91
92
Objetivos
Inicio
AUTOEVALUACIN DE LA UNIDAD III

Actividades
Autoevaluacin
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:
Glosario
Bibliografa
A) Los controles de validacin
B)
El cdigo fuente
Anotaciones
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 Intercambio 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 presento 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
93
94
Diagrama
Objetivos
Inicio

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

Lecturas
Diagrama
seleccionadas
Glosario
Objetivos
Bibliografa
Inicio
CONTENIDOS
Desarrollo
Recordatorio
de contenidos
Actividades
Anotaciones
EJEMPLOS
Autoevaluacin
autoevaluacin
Lecturas
seleccionadas
ACTIVIDADES
Glosario
BIBLIOGRAFA
Bibliografa

Recordatorio
Anotaciones
CONOCIMIENTOS
Tema N. 1: Seguridad de la informacin
1. Seguridad de la informacin
2. Seguridad informtica
Tema N. 2: Controles de seguridad I
PROCEDIMIENTOS
seguridad de la informacin


seguridad informtica

tcnicas de auditoria de sistemas.
3. Participa en la redaccin de observaciones relacionadas a la Gestin de Accesos y

Criptografa.

1. Gestin de accesos
2. Criptografa
Actividad N. 4
Elabora un ensayo sobre cuando utilizar los

diversos tipos de criptografa.
Aplicacin de la criptografa. Disponible en:

https://www.icai.es/contenidos/publicaciones/anales_get.php?id=1235
8 Videoclase
Tema N. 3: Controles de Seguridad II
1. Dispositivos de Seguridad Internet
2. Seguridad Cloud
3. Seguridad Mviles
Tema N. 4: Auditora a la Seguridad de la
Informacin
1. Auditora a la seguridad de la informacin
1. Identifica los riesgos relacionados al

Internet
2. Identifica los riesgos relacionados al
Cloud
3. Identifica los riesgos relacionados a los
dispositivos mviles
4. Participa en la redaccin de observaciones relacionadas a la seguridad de
la informacin, poniendo nfasis en la
recomendacin de controles.
2. Auditora a los controles de seguridad.

Tarea Acadmica N 2
Seguridad en dispositivos mviles: Qu

pautas debes seguir?. Disponible en: http://
hipertextual.com/archivo/2013/12/seguridad-dispositivos-moviles-consejos/
Elabora un informe de auditora de controles

de seguridad del caso Auditoria de una
empresa regional.
Autoevaluacin de la unidad IV
ACTITUDES

a realizar.
95
96
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 atributo 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 seguridad 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 seguridad 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 realidad 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 exhaustivo 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
97
98
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 informacin 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 Criptografa.
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 usuarios 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 informacin 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 comprender 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.
99
100
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: Mvpemq100v.
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 contrasea 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 recomendaciones de Edward Snowden en:
http://www.20minutos.es/noticia/2429957/0/edward-snowden/seis-consejos/contrasenas-seguras-internet/#xtor=AD-15&xts=467263
b.2 Autenticacin teniendo algo.
101
Otra forma de autenticacin (menos popular) es la d

autenticacin teniendo algo. Por ejemplo: un token, una tarjeta d
b.2 Autenticacin teniendo algo.
coordenadas o un chip. En la siguiente figura se tiene un ejempl
de tarjeta
de
coordenadas:
Otra forma de autenticacin
(menos
popular)
es la de autenticacin teniendo algo. Por ejemplo: un token, una tarjeta de coordenadas o un chip. En la siguiente figura se tiene un ejemplo de tarjeta de coordenadas:
Figura 20. Tarjeta de coordenadas usada en la 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

B6. E
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
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

Est
puede ser logrado con la huella dactilar, el anlisis del iris, de
retina,
la geometra de la mano. Las venas del dorso, etc.
c.1 Sistema de Control
de Accesos
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.
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
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
102
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 secreto. 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 criptografa 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 criptografas:

Tabla 4
Cuadro Comparativo Criptografas.
atributo
criptografa simtrica
criptografa asimtrica
funcin hash
Nro. de llaves
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
103
104
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 electrnicos.
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 SegunDiagrama
Objetivos
Inicio
da
Guerra
Mundial.
Desarrollo
de contenidos
Actividades
Autoevaluacin
Lecturas
seleccionadas
Glosario
Bibliografa
Leer artculo: Aplicaciones de la Criptografa.

Delgado, V., & Palacios, R. (2006). Aplicaciones prcticas de la criptografa. Anales de Mecnica y Electricidad. DispoRecordatorioen:Anotaciones
nible
http://bit.ly/2bcFvh1
Diagrama
Objetivos
Inicio
ACTIVIDAD N. 4
Desarrollo
de contenidos
Lecturas
seleccionadas
Actividades
Autoevaluacin
Participan en el Foro de discusin subiendo un ensayo sobre cuando utilizar los diversos tipos de criptografa.
Glosario
Bibliografa
INSTRUCCIONES
1. Revisa los temas 1 y 2 y la lectura seleccionada.

Recordatorio
Anotaciones
2.
Lee las instrucciones en el Aula Virtual.
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 necesariamente 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 personal 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 programas de fcil manejo para intentar hackear un objetivo.
Wannabies. Los Wannabies son aquellas personas que estn en proceso de hacerse hackers. Podra tratarse de novatos 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 programas 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 compaas deben protegerse de la competencia.
Las compaas para defenderse de las amenazas de Internet, implementan controles, los cuales veremos a continuacin.
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 implementados 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:
105
106
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 capaces 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_Feature_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 firewalls.
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) I DS 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 cambiar 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 demanda 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 encarga 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
107
108
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_TopThreats.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 informacin 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 publicada en el Apple Store. Esto permite con un cierto grado de confiabilidad que las Apps publicadas en el App Store
son seguras.
A pesar de los controles, los criminales informativos se las han arreglado para meter malware en algunas Apps.
Puede ver un detalle de esto en:
http://www.lavanguardia.com/tecnologia/moviles-dispositivos/iphone-ipad/20150925/54436836215/apple-appsmalware.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.
109
110
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 Informacin:
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 propietario, 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 propietario 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 implementaciones 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 revisar 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 encuentren 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 Auditor revisa que la compaa tenga alguna solucin de control como por ejemplo MDM (Mobile Device Management).
111
os
112
Diagrama
Objetivos
Inicio
Desarrollo
de contenidos
Actividades
Autoevaluacin
Lecturas
seleccionadas
Glosario
Bibliografa
Diagramaartculo:
Objetivos Seguridad
Inicio
Leer
en dispositivos mviles: qu pautas debes seguir?.
Velasco, J. (2013). Seguridad en dispositivos mviles: qu pautas debes seguir?. Disponible en http://bit.ly/2bxHOZZ
Diagrama
Recordatorio
Anotaciones
Desarrollo
de contenidos
Actividades
Objetivos
Autoevaluacin
TAREA ACADEMICA N 2
Inicio
Glosario
Bibliografa
Esta actividad
puede
consultarla en su Aula virtual.
Lecturas
seleccionadas
Desarrollo
de contenidos
Lecturas
seleccionadas
Actividades
Autoevaluacin
Recordatorio
GLOSARIO DE LA UNIDAD IV
Glosario
Anotaciones
Bibliografa
Activo de informacin. Recurso informtico que trata informacin. Puede ser una Base de datos, un Sistema, un Servidor, etc.
Recordatorio
Anotaciones
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.
Objetivos
Cuenta genrica. Es una cuenta utilizada para un usuario para un propsito especfico pero que no cuenta con sus
Inicio
nombres y apellidos. Toda cuenta genrica debe contar con un Propietario.
Propietario. Responsable de otorgar acceso a un Activo de informacin.
Actividades
Autoevaluacin
BIBLIOGRAFA DE LA UNIDAD IV
Glosario
Bibliografa
Anotaciones
Objetivos
Inicio
AUTOEVALUACIN DE LA UNIDAD IV
Actividades
Glosario
Anotaciones
Autoevaluacin
1. Despus de 2 meses, la Universidad Universal, descubre un hueco de seguridad que permiti a 2 alumnos realiBibliografa
zar un ataque informtico y acceder y modificar las notas almacenadas en la Base de Datos del Sistema Acadmico.
El descubrimiento fue accidental. En este caso, la Universidad habra podido detectar oportunamente si es que
tuviese implementado en la Base de datos:

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)
113
114
5. La Ley de Proteccin de datos obliga a las compaas a proteger los datos que se transmiten sobre la red. Ud. encuentra 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 transmisin?

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 autenticacin?

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 aplicaciones 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
115
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
docente, orienta y facilita el auto aprendizaje
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
de los contenidos y el desarrollo de las activi-
El modelo educativo de la Universidad Continental a distancia es innovador, interactivo
dades propuestas en el slabo.
e integral, conjugando el conocimiento, la
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.
investigacin y la innovacin. Su estructu-

A0031 MA Auditoria de Sistemas ED1 V1 2016

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

A0031 MA Auditoria de Sistemas ED1 V1 2016

Enviado por

Direitos autorais:

Formatos disponíveis

Auditora de sistemas

Gonzalo Martin Valdivia Benites

Auditora de sistemas. Manual Autoformativo

TIEMPO MINIMO DE ESTUDIO

UNIDAD I: Introduccin a la Auditoria de Sistemas

DIAGRAMA DE PRESENTACIN DE LA UNIDAD I

ORGANIZACIN DE LOS APRENDIZAJES

TEMA N. 1: Visin de la Auditoria de Sistemas

3  El riesgo como elemento clave de la Auditoria de Sistemas

TEMA N. 2: El proceso de la Auditoria de Sistemas

Formulacin de las Recomendaciones

TEMA N. 4: Marcos de Referencia de Auditoria de Sistemas

UNIDAD II: Auditoria al Gobierno y Gestin de TI

DIAGRAMA DE PRESENTACIN DE LA UNIDAD II

ORGANIZACIN DE LOS APRENDIZAJES

TEMA N. 1: Gobierno y Gestin de T.I.

2 Practicas Gerenciales de Gestin de TI

3 Auditoria al Gobierno y a la Gestin de TI

TEMA N. 2: Continuidad de Negocio y Recuperacin de Desastres

2 Planeacin a la Continuidad de Negocio y Recuperacin de Desastres

3 Auditoria a la Continuidad de negocio

Participa en el Foro de discusin sobre las Prcticas gerenciales en el rea de Sistemas.

UNIDAD III: Auditora al Ciclo de Vida de desarrollo de Software

DIAGRAMA DE PRESENTACIN DE LA UNIDAD III

ORGANIZACIN DE LOS APRENDIZAJES

TEMA N. 1: Etapas del Ciclo de Vida

2 Controles de Entrada, procesamiento y Salida

TEMA N. 2: Mantenimiento de Sistemas

2 Procedimiento de Control de Cambios.

6 Razones por las que suceden los cambios no autorizados

TEMA N. 3: Aplicaciones de Negocio

TEMA N. 4: Auditoria al Ciclo de Vida

2 Auditoria al Mantenimiento de Sistemas

GLOSARIO DE LA UNIDAD III

BIBLIOGRAFA DE LA UNIDAD III

AUTOEVALUACIN DE LA UNIDAD III

UNIDAD IV: Auditora a la seguridad de la informacin

DIAGRAMA DE PRESENTACIN DE LA UNIDAD IV

ORGANIZACIN DE LOS APRENDIZAJES

TEMA N. 1: Seguridad de la Informacin

TEMA N. 2: Controles de Seguridad I

TEMA N. 3: Controles de Seguridad II

2 Seguridad del Cloud

TEMA N. 4: Auditoria a la Seguridad de la Informacin

2 Auditoria a los controles de Seguridad.

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.

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-

3 El riesgo como elemento clave de la Auditoria de Sistemas

2 Practicas Gerenciales de Gestin de TI

3 Auditoria al Gobierno y a la Gestin de TI

2 Planeacin a la Continuidad de Negocio y Recuperacin de Desastres

3 Auditoria a la Continuidad de negocio

UNIDAD III: Auditora al Ciclo de Vida de desarrollo de Software

2 Controles de Entrada, procesamiento y Salida

2 Procedimiento de Control de Cambios.

6 Razones por las que suceden los cambios no autorizados

2 Auditoria al Mantenimiento de Sistemas

2 Seguridad del Cloud

2 Auditoria a los controles de Seguridad.

1. Infiere los procedimientos de auditora a

1. Valora la importancia de la ejecucin de

2. Participa en la definicin de los controles

2. Se auto valora por su aprendizaje de las

3. Identifica las diferentes actividades en la

3. Asume el compro-miso de revisar los

4. Identifica las diferentes actividades en la

4. Valora la importancia de la auditoria de

5. Identifica las diferentes actividades en la

5. Participa activa-mente en el desarrollo de

1. Identifica el riesgo y escribe hallazgos de

2. Analiza y utiliza lo explicado en un caso

1. Formulacin de los hallazgos de Auditoria

3. Identifica los estndares, las directrices y

2. Formulacin de recomendaciones para

4. Identifica leyes, regulaciones y estn-dares

3. Formulacin del Informe de Auditoria

5. Utiliza los marcos de referencia en los

1. Marcos Internacionales: CobiT, Familia

2. Marcos Nacionales: Contralora General

3 El riesgo como elemento clave de la Auditoria de Sistemas

1 Formulacin de los Hallazgos de Auditoria