Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Primera edición
Huancayo, mayo de 2016
De esta edición
© Universidad Continental, Modalidad Virtual
Av. San Carlos 1980, Huancayo-Perú
Teléfono: (51 64) 481-430 anexo 7361
Correo: recursosucvirtual@continental.edu.pe
http://virtual.ucontinental.edu.pe/
Todos los derechos reservados. Cada autor es responsable del contenido de su propio texto.
ACTIVIDAD N.° 1 42
CONTROL DE LECTURA Nº 1 42
GLOSARIO DE LA UNIDAD I 43
BIBLIOGRAFÍA DE LA UNIDAD I 43
AUTOEVALUACIÓN DE LA UNIDAD I 44
INTRODUCCIÓN
B
ienvenido al curso de Auditoria de Sistemas! Gobierno y gestión de TI, las Practicas Gerenciales de
En este curso Ud. aprenderá los conceptos y las Gestión de TI y la forma de ejecución de Auditorias al
técnicas más relevantes para realizar Auditorías Gobierno y a la Gestión 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
nologías de Información más importantes, retadoras y de Negocio y Recuperación 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 también ¿por qué no decirlo?, la Auditoria que cada dia dependen más 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 prácticas 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 institución mundial más importante en Audi- controles que todo software debe implementar. Por otro
toria de Sistemas. lado estudiaremos los procedimientos de Mantenimien-
to de Sistemas y revisaremos algunas aplicaciones de
La asignatura está estructurado en 4 Unidades: Negocio específicas que los Auditores suelen revisar. Al
finalizar esta Unidad revisaremos la Auditoria al Ciclo
La primera Unidad está enfocada en el proceso de Au-
de Vida de Desarrollo de Software y al Mantenimiento
ditoria. En este parte Ud. aprenderá los conceptos bá-
de Software.
sicos y el proceso a seguir para realizar Auditorías de
Sistemas. En la última Unidad nos enfocaremos en la Auditoria a
la Seguridad de la Información. Revisaremos las técni-
También Ud. aprenderá a redactar Hallazgos de Audi-
cas y procedimientos de Seguridad de la Información y
toria así como informes de Auditoria, donde expresa
Seguridad Informática, enfocándonos en temas como
su opinión con respecto a una determinada materia o
encriptación, control de acceso, seguridad de Internet,
situación. L finalizar e esta Unidad revisaremos los prin-
Cloud, Móviles, entre otros. Finalizaremos esta Unidad
cipales Marcos de referencia de auditoria tanto naciona-
con la Auditoria a la seguridad de la información
les como internacionales que utilizan los Auditores en
la ejecución de su Auditoria. Espero que el curso sea de su provecho y que el conte-
nido aporte su granito de arena para que lo ayude a Ud.
En la Unidad II revisaremos la Auditoria al Gobierno y
en un profesional más completo. ¿Y por qué no? Este
Gestión de TI. En esta parte revisaremos el Gobierno
curso puede descubrir que Ud. podría ser un excelente
Corporativo y el Gobierno de TI, las diferencias entre
Auditor de Sistemas.
8
PRESENTACIÓN DE LA ASIGNATURA
Diagrama Objetivos Inicio
COMPETENCIA DE LA ASIGNATURA
Realizar de manera efectiva procesos de auditoría de sistemas a la organización, procesos y soluciones tecnológicas
existentes
Desarrollo en Actividades
las áreas deAutoevaluación
Sistemas, a través de la identificación de los riesgos asociados a las tecnologías de información
de
encontenidos
las organizaciones de hoy; aplicando los principales estándares, normas, metodologías y mejores prácticas a nivel
mundial en auditoria de sistemas.
UNIDADES DIDACTICAS
Lecturas Glosario
seleccionadas
Bibliografía
Introducción a la Auditoria de Auditoria al Gobierno y Gestión Auditoria al Ciclo de Vida de Auditoria a la seguridad de la
Sistemas de TI desarrollo de Software información
Recordatorio Anotaciones
autoevaluación BIBLIOGRAFÍA
Lecturas Glosario Bibliografía
seleccionadas
Video de presentación de la asignatura 1. Infiere los procedimientos de auditoría a 1. Valora la importancia de la ejecución de
Unidad I: Introducción a la Auditoria de aplicar. la auditoria de sistemas.
Sistemas 2. Participa en la definición de los controles 2. Se auto valora por su aprendizaje de las
1° Videoclase (Video conferencia) para minimizar riesgos. técnicas de auditoria de siste-mas.
3. Identifica las diferentes actividades en la 3. Asume el compro-miso de revisar los
ejecución de la Auditoria contenidos del manual.
Tema N.° 1: Tema 1
4. Identifica las diferentes actividades en la 4. Valora la importancia de la auditoria de
1. Visión de la Auditoria planificación de la Auditoria sistemas para el mejora-miento de una
2. Estándares de ISACA 5. Identifica las diferentes actividades en la empresa y para las actividades o procesos
3. El riesgo como elemento clave de la Audi- ejecución de la Auditoria a realizar.
toria de Sistemas 5. Participa activa-mente en el desarrollo de
las actividades de la asignatura.
Actividad N.° 1
Tema N.° 2: El proceso de Auditoria de Participan en el Foro de discusión sobre “Los
Sistemas riesgos originados por el uso de las Tecnolo-
1. Planeamiento de Auditoria gías de Información en las organizaciones”.
2. Programa de Auditoria
Lectura seleccionada 1
Título: Auditoria de Sistemas. Disponible en:
http://www.gerencie.com/auditoria-de-siste-
mas.html
10 UNIDAD I: Introducción a la Auditoria de Sistemas
Autoevaluación Nº 1
Auditoría de sistemas
UNIDAD I: Introducción a la Auditoria de Sistemas MANUAL AUTOFORMATIVO 11
INTRODUCCIÓN
Este tema está preparado para que tengas tu primer contacto con la Auditoria de Sistemas. En este primer tema toca-
remos los puntos más importantes de la Auditoria de Sistemas.
1 V
isión de la Auditoria
La Auditoria es un proceso sistemático de evaluación post-mortem y de formación de opinión sobre una determinada
materia o situación. Para nuestro caso sobre una materia o situación relacionada a Tecnología de Información tal
como un Sistema Informático, una Base de datos, una Infraestructura tecnológica, unos Servidores, la gestión del Ge-
rente de TI, un proceso de atención de soporte técnico a usuarios, etc.
Este proceso es realizado por los Auditores quienes son profesionales que se encargan de realizar la evaluación y en
función su evaluación forma una opinión sobre dicha materia o situación.
Aquí vale la pena mencionar que las auditorias también pueden ser previas o durante la ejecución de una determinada
materia o situación.
• Financieras. En estas Auditorias el Auditor forma una opinión si los estados financieros (balance general, de una
empresa reflejan la realidad financiera de la empresa.
• Operacionales. En estas Auditorias Operacionales se forma una opinión de la efectividad de los controles operati-
vos de los procesos de una compañía. Por ejemplo compras, ventas, producción, etc.
• Cumplimiento. En las Auditorias de Cumplimiento, se forma una opinión de si una empresa cumple con las leyes
y regulaciones que está obligada a cumplir.
• Sistemas. En las Auditorias de Sistemas, el Auditor forma una opinión de la efectividad de los controles tecnológi-
cos para minimizar los riesgos por el uso de la tecnología.
Las Auditorias Financieras se realizan al menos una vez al año. Muchas entidades reguladoras exigen que se realicen
Auditorias Financieras. Por ejemplo la Superintendencia de Mercado de Valores (SMV) exige que se realicen audito-
rias financieras a las compañías que cotizan en la Bolsa. Asimismo la Contraloría General de la Republica (CGR) exige
que las Entidades del Estado realicen una auditoria una vez al año. La Superintendencia de Banca, Seguros y AFP
(SBS) audita que los Bancos e Instituciones Financieras al menos una vez al año.
En el Perú, es frecuente encontrar las auditorias de Sistemas como parte de las Auditorias Financieras.
Las Auditorias de Sistemas no son tan frecuentes y normalmente son realizadas cuando hay algún problema en el área
de TI, o cuando un nuevo Gerente de TI la solicita para tomar conocimiento de la situación que recibe.
Las Auditorias pueden ser internas o externas en función de quien realiza la Auditoria. Así tenemos:
• Auditoria Interna. Una Auditoria es considerada Interna cuando el Auditor o equipo de Auditoria labora dentro de
la misma compañía. En una Auditoria Interna se tiene la ventaja del nivel de profundidad de la auditoria. Dado que
1.3 Auditoria Interna vs. Auditoria Externa.
Las Auditorias pueden ser internas o externas en función de quien realiza la
12 Auditoria. Así tenemos: UNIDAD I: Introducción a la Auditoria de Sistemas
Auditoria Interna. Una Auditoria es considerada Interna cuando el Audi-
tor o equipo de Auditoria labora dentro de la misma compañía. En una
Auditoria Interna se tiene la ventaja del nivel de profundidad de la audi-
toria.
los Auditores son Dadotienen
internos que lalos Auditores
ventaja son internos
de conocer el negociotienen
y pueden la realizar
ventaja de conocer
auditorías más detalladas. Una
el negocio
desventaja podría ser que eny caso
pueden realizar
hubiese auditorías
algún tipo másentre
de relación detalladas.
el AuditorUna desventaja
y la materia auditada, el Auditor
podría ser que en caso hubiese algún tipo de relación entre el Auditor y
perdería su independencia.
la materia auditada, el Auditor perdería su independencia.
En Perú
En Perú los Auditores los laboran
internos Auditores internos
en el área de laboran
Auditoriaen el área
Interna. En de Auditoriadel
las Entidades Interna.
Estado laboran en las
Oficinas de ControlEnInterno
las Entidades
(OCI). del Estado laboran en las Oficinas de Control Interno
(OCI).
Auditoria
• Auditoria Externa. En esteExterna. En este
caso, el Auditor caso,de
o equipo elAuditoria
Auditor pertenece
o equipoade unaAuditoria
compañía perte-
externa que tiene una
nece por
experiencia amplia a una
habercompañía externacompañías
auditado muchas que tiene deuna experiencia
diversos amplia
rubros. Como una por ha- se tiene que
desventaja
ber auditado
la Auditoria Externa podría sermuchas compañías
menos detallada denormalmente
ya que diversos rubros.
cuentanComocon ununa desven-
periodo de tiempo reducido
(semanas o pocostajameses)
se tiene
paraque la Auditoria
realizar la revisión.Externa podría ser menos detallada ya que
normalmente cuentan con un periodo de tiempo reducido (semanas o
pocos meses) para realizar la revisión.
1.4 Las Big Four.
Gráfico
Si te interesa saber más de estas compañías, N° 1 – más
puedes obtener Lasinformación
Big Four. en las siguientes direcciones:
¿Estas 3 situaciones que encontraste pueden originar riesgos? ¿Se cuenta con los controles adecuados para minimizar
los riesgos? ¿O todo lo contrario? ¿Qué opinión te vas formando de esta situación? Ese es el trabajo del Auditor de
Sistemas: encontrar situaciones que originan riesgos.
vidor no cuenta con Antivirus. También encuentras que la contraseña del su-
per usuario de la Base de datos no ha sido cambiada desde hace 3 años y
encuentras que al Sistema Operativo nunca se le han instalado parches del
Auditoría de sistemas
fabricantea la
UNIDAD I: Introducción (Imagina
Auditoria que es un Windows Server).
de Sistemas MANUAL AUTOFORMATIVO 13
¿Estas 3 situaciones que encontraste pueden originar riesgos? ¿Se cuenta
con los controles adecuados para minimizar los riesgos? ¿O todo lo contra-
rio? ¿Qué opinión te vas formando de esta situación? Ese es el trabajo del
Auditor de Sistemas: encontrar situaciones que originan riesgos.
2 Estándares de ISACA
2. Estándares de ISACA
2.1 ISACA
2.1 ISACA
Los Auditores de Sistemas están agrupados en gremios profesionales. A nivel mundial una de las instituciones más
Los
prestigiosas es Auditores de
la Information Sistemas
System están
Audit and agrupados
Control en(ISACA).
Association gremios profesionales. A ni-
vel mundial una de las instituciones más prestigiosas es la Information Sys-
ISACA es unatem Audit and
institución Control
con Sede Association
en Chicago, (ISACA).
Estados Unidos, que agrupa a los profesionales de auditoria, control,
ISACA
riesgo y gobierno dees TI.una institución
Te invito con
a que le desSede en Chicago,
un vistazo Estados Unidos,
a esta institución. que agrupa
Puedes encontrar más ainformación 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 institución. Puedes encontrar más información
Asimismo ISACAen http://www.isaca.org
es uno de las entidades certificadoras de profesionales más importantes del mundo. Actualmente,
ISACA ofreceAsimismo ISACAlasescuales
4 certificaciones, uno son:
de las entidades certificadoras de profesionales más
importantes del mundo. Actualmente, ISACA ofrece 4 certificaciones, las
cualesInformation
• CISA (Certified son: Security Auditor)
CISA (Certified Information Security Auditor)
CISM
• CISM (Certified (CertifiedSecurity
Information Information
Manager)Security Manager)
CGEIT (Certified in the Governance of Enterprise IT)
CRISC
• CGEIT (Certified (Certified
in the in Risk
Governance and Information
of Enterprise IT) Systems Control)
ISACA cuenta con un framework de Auditoria de Sistemas denominado “A Professional practices Framework for IS
Audit/Assurance”, más conocido como el framework ITAF.
A continuación, vamos a detallar los estándares más relevantes para nuestro curso.
10
• Estándar 1003 Independencia profesional. El estándar indica textualmente que: “Los profesionales de auditoría y ase-
guramiento de SI deben ser independientes y objetivos, tanto en actitud como en apariencia, en todos los asuntos relacionados con
las asignaciones de auditoría y aseguramiento”. Esto significa que no debe haber ninguna relación entre al Auditor y la
materia que se está auditando. Por ejemplo, imagínate que estas auditando una compañía y tu esposa trabaja para
dicha compañía. En este caso podría afectarse tu independencia. Si encuentras muchos riesgos, el que pueda estar
en riesgo eres tu!. Espérate al llegar a casa!
14 UNIDAD I: Introducción a la Auditoria de Sistemas
• Estándar 1006 Competencia. “Los profesionales de auditoría y aseguramiento de SI, junto con otras personas que ayudan en
la asignación, deben poseer las habilidades y la competencia adecuadas para realizar las asignaciones de auditoría y aseguramien-
to de SI y ser profesionalmente aptos para realizar el trabajo requerido”. Por ejemplo no podemos hacer una Auditoria de
Sistemas a un cajero automático sino tenemos la mínima idea de cómo funciona por dentro. En este caso no somos
competentes para realizar la evaluación.
• Estándar 1201 Evaluación de riesgo en planificación: “La función de auditoría y aseguramiento de SI debe utilizar un enfo-
que de evaluación de riesgo adecuado y metodología de respaldo para desarrollar el plan completo de auditoría de SI y determinar
las prioridades para la asignación efectiva de los recursos de auditoría de SI”. Como dijimos el riesgo es primordial para el
Auditor de Sistemas. En función del riesgo se planifica que auditar y con qué prioridad.
• Estándar 1204 Materialidad. “Los profesionales de auditoría y aseguramiento de SI deben considerar las debilidades potenciales
o ausencias de controles mientras planifican una asignación y si esas debilidades o ausencias de controles pudieran resultar en
una deficiencia significativa o una debilidad material”.
• Estándar 1205 Evidencia: “Los profesionales de auditoría y aseguramiento de SI deben obtener evidencias suficientes y apropia-
das para llegar a conclusiones razonables sobre las cuales basar los resultados de la auditoria”. El Auditor siempre se respalda
con evidencias, como por ejemplo fotos, videos, actas, documentación, pantallazos, etc.
• Estándar 1207 irregularidad y Actos irregulares: “Los profesionales de auditoría y aseguramiento de SI deben considerar el
riesgo de irregularidades y actos ilegales durante la auditoria.
Los profesionales de auditoría y aseguramiento de SI deben mantener una actitud de escepticismo profesional durante la asignación.
Los profesionales de auditoría y aseguramiento de SI deben documentar y comunicar, de manera oportuna, cualquier acto ilegal o
irregularidad material a la parte apropiada”. Esto significa que si encontramos una irregularidad o un acto ilegal, estamos
en la obligación de obtener la evidencia correspondiente e informarlo, no podemos ignorarlo.
• Estándar 1401 Reportes: “Los profesionales de auditoría y aseguramiento de SI deben proporcionar un reporte para comunicar
los resultados al concluir la auditoria, que incluye:
• Identificación de la empresa, los destinatarios previstos y cualquier restricción sobre el contenido y la circulación
• Alcance, objetivos de la asignación, período de cobertura y la naturaleza, los plazos y el alcance del trabajo realizado
• Cualquier calificación o limitación dentro del alcance que el profesional de auditoría y aseguramiento de SI tenga con respecto a
la asignación
• Firma, fecha y distribución según los términos del estatuto de la función de auditoría o carta de asignación de auditoría”. Como
ves, este estándar nos indica caramente cuales son los entregables de la Auditoria de Sistemas.
• Estándar 1402 Actividades de Seguimiento: “Los profesionales de auditoría y aseguramiento de SI deben monitorear infor-
mación relevante para concluir si la dirección ha planeado/tomado la acción oportuna y apropiada para abordar los hallazgos y
las recomendaciones de la auditoría reportados”. El seguimiento se refiere a revisar que los auditados hayan ejecutado las
recomendaciones de la Auditoria de Sistemas del periodo anterior.
Estos estándares no son los únicos. Una lista completa de los estándares de Auditoria, los puedes encontrar en:
http://www.isaca.org/Knowledge-Center/ITAF-IS-Assurance-Audit-/IS-Audit-and-Assurance/Pages/Stan-
dards-for-IS-Audit-and-Assurance-Spanish.aspx
Asimismo, si deseas profundizar en el framework ITAF (en ingles) lo puedes encontrar en:
http://www.isaca.org/Knowledge-Center/Research/Documents/ITAF-3rd-Edition_fmk_Eng_1014.pdf
Auditoría de sistemas
UNIDAD I: Introducción a la Auditoria de Sistemas MANUAL AUTOFORMATIVO 15
En la sección 1.5 vimos un ejemplo de 3 situaciones que originan riesgo. Ahora imagina que haces la revisión y no
encuentras situaciones de riesgo. Es decir, haces la Auditoria y se “te escapan” estos puntos. Es decir no encuentras las
situaciones que originan los riesgos (que en el ejemplo son muy evidentes). ¿Qué opinión te formarías? Se dice que
Auditor de Sistemas que no encuentra riesgos, no es Auditor de Sistemas. Por eso es muy importante que aprendamos
a identificar los riesgos.
Veamos la definición de la Norma ISO 13335. “El riesgo es la probabilidad que una amenaza se aproveche de una vul-
nerabilidad y nos genera un daño”.
El daño es el impacto negativo que tenemos si la amenaza se aprovecha de la(s) vulnerabilidad(es). El daño pude ser
económico, patrimonial, de imagen, etc.
Volvamos a las tres situaciones identificadas del primer ejemplo. Tenemos que:
• La contraseña del super usuario de la Base de datos no ha sido cambiada desde hace 3 años y
¿Cuál sería la amenaza? Es evidente que lo que nos puede hace daño aquí es el malware.
¿Cuál sería el daño? El ingreso de malware podría originar la inutilización del servidor, el robo de información del
servidor, entre otros.
¿Cuál sería la amenaza? Cualquier persona que tenga acceso al servidor y que conozca o adivine la contraseña es con-
siderada una amenaza.
¿Cuál sería la amenaza? El malware o los criminales informáticos son las amenazas.
Una vez que el riesgo ha sido identificado, el riesgo debe ser tratado.
El término “tratamiento del riesgo” quiere decir que hay que hacer algo con ese riesgo. El tratamiento del riesgo le
corresponde al Auditado.
• Reducirlo. Cuando se decide reducir (o minimizar) el riesgo, se tiene que hacer algo para que ese riesgo se reduzca.
Por ejemplo mantener actualizado un Sistema Operativo actualizado con los parches que emite el fabricante.
• Transferirlo. En algunas situaciones es posible transferir el riesgo a un tercero. Por ejemplo tercerizar un proyecto
de desarrollo de software a un tercero, en lugar de hacerlo nosotros mismos. Otro ejemplo podría ser contratar una
póliza de seguros.
• Aceptarlo. Aceptar un riesgo es lo mismo que no hacer nada. Simplemente, se “le acepta”. Ejemplo de esto es seguir
sin Antivirus a pesar de que se encontró que un computador esta sin Antivirus.
• Cesar la actividad que da origen al riesgo. A esta opción algunos autores le llaman “eliminar” el riesgo. Por ejemplo,
si no se puede instalar un Antivirus (cosa poco probable) siempre queda la alternativa de apagar el computador. Al
apagar el computador, estoy cesando la actividad que da origen al riesgo. Pero esta acción ha tenido un costo muy
alto. Si bien es cierto que “elimine” el riesgo de infección, también inhabilite el uso del computador.
3.3 Controles
Cuando se decide reducir el riesgo, entonces se requiere de un control que haga ese trabajo. Un control en su término
más amplio es cualquier cosa que minimiza un riesgo. Por ejm. escribir un procedimiento, implementar un firewall,
instalar un antivirus, ejecutar un respaldo (backup), etc.
• Preventivos. Siempre se debe preferir este tipo de controles. Su función es detectar problemas antes de que estos
ocurran. Por ejemplo una pantalla de usuario y contraseña de acceso a un Sistema o la encriptación de datos sen-
sibles.
• Detectivos. Estos controles como su nombre lo indica detectan y reportan la ocurrencia de un incidente, error o
situación. Por ejemplo un log de auditoria, una alarma o una función hash.
• Correctivos. Los controles correctivos minimizan el impacto de una amenaza así como corrigen los problemas des-
cubiertos por los controles detectivos. Por ejemplo un respaldo (backup) o un plan de contingencias.
El auditor como parte de su trabajo debe recomendar los mejores controles para reducir el riesgo que identificó.
A lo largo del curso te presentaré muchos ejemplos de las diferentes situaciones que evalúan los Auditores de Sistemas
y los riesgos que se identifican.
Auditoría de sistemas
UNIDAD I: Introducción a la Auditoria de Sistemas MANUAL AUTOFORMATIVO 17
INTRODUCCIÓN
Este tema está enfocado en como efectuar una Auditoria de Sistemas. No se trata de auditar lo primero que veamos. Se
trata de Auditar en función al riesgo y para ello es esencial la planificación y luego de ella, la ejecución de la Auditoria.
1 Planeamiento de la Auditoria
Ahora ya estamos listos para empezar nuestra primera Auditoria. ¿Por dónde empezamos? Pues por el principio. Es
decir, por el Planeamiento. El planeamiento adecuado es el primer paso para efectuar auditorías de TI eficaces.
• Planeamiento a largo plazo. En este planeamiento se define el plan de auditoria anual. El riesgo define que se au-
dita primero y que se audita después.
• Planeamiento individual. Este planeamiento se debe hacer para cada Auditoria definida en el punto anterior.
Según ISACA debemos seguir los siguientes pasos para realizar una planificación de Auditoria.
• Comprender el negocio. Esto significa comprender la misión, los objetivos, y los procesos de negocio.
• Revisar los papeles de trabajo anteriores. Esto significa que el Auditor debe revisar todo el trabajo que se ha reali-
zado en las auditorias anteriores.
• Identificar la estructura organizacional, así como las políticas, normas, procedimientos que le aplican.
Por otro lado es imprescindible que el Auditor considere las leyes y regulaciones que aplican a la compañía. Por ejem-
plo si vamos a auditar un Banco, entonces hay que entender las regulaciones definidas por la Superintendencia de
Banca y Seguros (SBS). Si vamos a auditar una compañía de electricidad hay que identificar la regulación del Orga-
nismo Supervisor de la Inversión en Energía y Minería (OSINERGMIN). Si vamos a auditar una compañía telefónica
la regulación a identificar será la de Organismo Supervisor de Inversión Privada en Telecomunicaciones (OSIPTEL).
Debes tener en cuenta que históricamente existen 2 tipos de industria que son altamente regulados: la banca y finanzas
y las compañías de telecomunicaciones.
18 UNIDAD I: Introducción a la Auditoria de Sistemas
Veamos un ejemplo de la planificación de manera general. Tenemos que planificar una Auditoria de Sistemas Externa
a una compañía de distribución de electricidad ubicada en el sur del país.
• Comprender el negocio. Habíamos dicho que en este punto se debe comprender la misión, los objetivos, y los pro-
cesos de negocio. Una forma inicial es ingresar a la página web de la Compañía. En la sección Conócenos o Quienes
somos o sección similar del sitio Web se puede obtener la Misión, Visión y alcance de lo que hace la compañía. Por
ejemplo de una rápido recorrido a la página Web de nuestra compañía de ejemplo obtuvimos:
Nuestra misión:
“Contribuir con el desarrollo de la región sur, brindando oportunamente productos y servicios eléctricos de calidad a
satisfacción del cliente, con personal comprometido; consolidando de manera sostenida la rentabilidad de la empresa”.
Nuestra visión:
Al revisar la misión se indica que brindan productos y servicios eléctricos, los cuales se soportan en el uso de tecnolo-
gías de Información, que es donde nos enfocaremos para hacer la Auditoria de Sistemas.
• Revisar los papeles de trabajo anteriores. Esto significa que debemos solicitar el(los) Informe(s) de Auditoria ante-
rior(es) y los papeles de trabajo que se utilizaron en dicha(s) auditoria(s). En ese (esos) documento(s) encontrare-
mos mucha información que utilizaremos para nuestra planificación.
• Entender los cambios en el entorno de negocios del auditado. Aquí debemos identificar los riesgos a los que está
expuesta la compañía y el riesgo al que está expuesta por el uso de la tecnología de la información. Asimismo se
debe tener un claro conocimiento de las regulaciones que aplican que para este casos serían las de OSINERGMIN.
• Identificar la estructura organizacional, así como las políticas, normas, procedimientos que le aplican. Para poder
planificar debemos tomar conocimiento de del Organigrama de la compañía, como funciona la compañía, que pro-
cesos tienen y como operan y tomar conocimiento de todo el conjunto de documentos normativos internos. Este
conjunto de documentos lo constituyen las políticas, las normas, las directivas, los estándares, los procedimientos e
instructivos. Cada compañía es diferente y los nombres de los tipos de documentos podrían variar.
• Establecer el alcance y los objetivos de la Auditoria. En función a los puntos anteriores, ya tenemos una buena
idea de los riesgos de la tecnología y en ese contexto podemos planificar el alcance y los objetivos de la Auditoria.
Recuerda que el alcance es igual a trabajo. Eso significa que debemos decidir que trabajo vamos a realizar. Aquí se
decide que vamos a auditar (el alcance) y que queremos lograr con la auditoria (los objetivos).
• Desarrollar el enfoque de la Auditoria. En este punto ya podemos trazar un plan de trabajo con las actividades
generales para nuestra Auditoria.
• Asignar recursos a la Auditoria. En este punto se debe determinar el equipo de trabajo que van a realizar la Audito-
ria. Es evidente que necesitamos a un Auditor con experiencia en sistemas eléctricos.
• Dirigir la logística de trabajo a la Auditoria. Aquí se ven los recursos que necesitamos para ejecutar la Auditoria.
Dado que se va a ejecutar una auditoria en el sur del país hay que trasladar útiles de oficina, personas lo que significa
pasajes, estadía, viáticos y resolver todos los temas como en donde van a trabajar los auditores, la seguridad de la
ubicación de los auditores, su equipamiento informático, su conexión y acceso a la red, entre otros.
2 Programa de Auditoria.
Una vez que hemos planificado la Auditoria, ya estamos listos para ejecutar la Auditoria. Las Auditorias de Sistemas
típicamente siguen las siguientes fases:
Auditoría de sistemas
UNIDAD I: Introducción a la Auditoria de Sistemas MANUAL AUTOFORMATIVO 19
• Seguimiento
Es un requisito que las conclusiones del auditor estén basadas en evidencia suficiente y competente. El Auditor que no
obtiene evidencia no puede escribir sus hallazgos.
• Objetividad de la evidencia
• Oportunidad de la evidencia
• Revisión de la documentación de SI
PROGRAMA DE AUDITORIA
I. INTRODUCCION
Naturaleza
La actividad principal de SuperElectro S.A., es la distribución y comercialización de energía eléctrica, en las unidades de concesión
otorgadas por el Estado Peruano, así como la generación y transmisión eléctrica en los sistemas aislados, siempre que cuente con
las autorizaciones respectivas.
Base Legal
• Decreto Ley N.° 25844 Ley de Concesiones Eléctricas, publicado el 19 de Noviembre de 1992 y modificatorias.
• Decreto Supremo N.° 009-93-EM Reglamento de la Ley de Concesiones Eléctricas, disposiciones, modificatorias y complemen-
tarias.
• Ley N.° 27170 Ley del Fondo Nacional de Financiamiento de la Actividad Empresarial del Estado-FONAFE, publicado el 09
de Setiembre de 1999.
• Ley N.° 24948 Ley de la Actividad Empresarial del Estado, publicada el 04 de diciembre de 1988.
• Ley N.° 26734 Ley que crea el Órgano Superior de la Inversión de Energía OSINERGMIN, 1996.
• Ley N.° 28716 Ley de Control Interno de las Entidades del Estado, publicada el 17 de abril del 2006.
• Modificación al Plan de Gestión Corporativa de Tecnología de Información y Comunicaciones para las empresas bajo el ámbito
de FONAFE (2009-2011) aprobada mediante Resolución de Dirección Ejecutiva Nº 046-2009/DE-FONAFE.
• Aprobar el Nuevo Texto de los Lineamientos para el Uso de las Firmas Digitales e Intercambio Electrónico de Documentos-SIED
entre FONAFE y las empresas bajo su ámbito, que en el anexo 1 forman parte del presente acuerdo. Resolución Dirección Ejecu-
tiva N.° 027-2011/DE-FONAFE.
• Plan de Gestión Corporativa de Tecnología de Información y Comunicaciones para las empresas bajo el ámbito de FONAFE
(2008-2011) aprobada mediante Resolución de Dirección Ejecutiva Nº 059-2008/DE-FONAFE.
• Directiva de uso compartido de software en las empresas bajo el ámbito de FONAFE. Aprobada por Acuerdo de Directorio N.°
004-2007/010-FONAFE.
Auditoría de sistemas
UNIDAD I: Introducción a la Auditoria de Sistemas MANUAL AUTOFORMATIVO 21
El informe de Auditoria se ceñirá a lo dispuesto en las Normas de Auditoria Gubernamental; tanto en lo que se refiere a su estruc-
tura como a su contenido, para lo cual se deberá tener en cuenta lo siguiente:
I. Introducción.
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. Comunicación de Hallazgos.
6. Memorándum de Control Interno.
7. Otros aspectos de importancia.
II. HALLAZGOS
Se incluirán hallazgos determinados como consecuencia del trabajo de campo realizado y la aplicación de los procedimientos de
Auditoria según nuestro programa de trabajo.
Dichas observaciones serán evaluadas con las respuestas de los hallazgos comunicados a las personas comprendidas en los mismos,
así como la documentación y evidencia sustentatoria respectiva.
Cada observación deberá redactarse en forma narrativa, teniendo en cuenta para su presentación los aspectos siguientes:
1) Sumilla.
2) Elementos de la Observación:
2.a) Condición.
2.b) Criterio.
2.c) Efecto.
2.d) Causa.
22 UNIDAD I: Introducción a la Auditoria de Sistemas
Tal como lo dispone las Normas de Auditoria Gubernamental, el contenido del informe revelará cada observación considerando lo
siguiente:
- Las razones fundamentales por la cual ocurrió la condición o el motivo por el que no se cumplió el criterio o la norma (causa).
- Los efectos reales y/o riesgos potenciales cuantitativos o cualitativos que ocasiona el hallazgo (efecto).
III. CONCLUSIONES
Juicios de carácter profesional, sustentados en las observaciones resultantes del examen efectuado.
IV. RECOMENDACIONES
Las recomendaciones constituyen las medidas sugeridas a la Gerencia de la Empresa examinada, orientada a promover la supera-
ción de las observaciones o Hallazgos de la evaluación de la gestión.
V. ANEXOS
Se utilizará los anexos indispensables que competen o amplíen la información de importancia contenida en el mismo.
La exposición respecto a la evaluación del cumplimiento y aplicación de los controles Tecnológicos, deberá contener comentarios por
cada Área y/o sistema examinado, las cuales se citarán en el informe, incluyendo los aspectos de incidencia.
Además deberá darse una apreciación crítica sobre el funcionamiento de cada área y sistema con relación a la Empresa considerada
en su integridad.
Auditoría de sistemas
UNIDAD I: Introducción a la Auditoria de Sistemas MANUAL AUTOFORMATIVO 23
INTRODUCCIÓN
En esta sección de la asignatura aprenderás a escribir hallazgos de Auditoria de Sistemas tal cual lo hacen los Auditores
de Sistemas profesionales.
Como ya se mencionó, el trabajo del Auditor de Sistemas es identificar situaciones que originan riesgo y recomendar
controles adecuados para su minimización.
Cuando el Auditor encuentra una situación de riesgo, escribe un Hallazgo de Auditoria. A continuación te presentaré
los componentes de un Hallazgo de Auditoria:
Titulo
• Descripción
• Riesgo
• Recomendación
• El riesgo se refiere al daño que se ha originado o podría originarse si el riesgo se materializa.
En la Auditoria a una empresa del Estado, se incluyen observaciones determinadas como consecuencia del trabajo de
campo realizado y la aplicación de los procedimientos de Auditoria según el programa de auditoria. Las observaciones
están referidas a asuntos significativos, e incluirán información suficiente y competente.
El formato del hallazgo se amplía a 6 párrafos, esto debido a que así lo exige la normatividad de la Contraloría General
de la Republica.
Titulo
• Condición
• Criterio
• Causa
• Riesgo
• Recomendación
24 UNIDAD I: Introducción a la Auditoria de Sistemas
• Conclusión
• Las razones fundamentales por la cual ocurrió la condición o el motivo por el que no se cumplió el criterio o la
norma (causa).
• Los efectos reales y/o riesgos potenciales cuantitativos o cualitativos que ocasiona el hallazgo (efecto).
• La conclusión es la conclusión del Auditor después de dar la oportunidad de réplica al auditado.
Las observaciones son evaluadas con las respuestas de los hallazgos comunicados a las personas comprendidas en los
mismos, así como la documentación y evidencia sustentatoria respectiva.
Ejemplo 1:
150 PCs del parque informático de la Entidad cuentan con el Sistema Operativo Windows XP que ya no cuenta con
soporte del fabricante.
De la revisión al parque informático de la Entidad, se encontró que existen 150 equipos informáticos que cuentan con el sistema
operativo Windows XP. Dicho sistema operativo ya no es soportado por Microsoft desde el 08 de abril del 2014, lo cual significa
que los equipos que aún cuentan con dicho sistema operativo se encuentran vulnerables, ya que el fabricante ya no emite parches
de seguridad. La información completa del fin del soporte para el sistema operativo Windows XP se encuentra disponible en el sitio
web oficial de Microsoft, en el link. http://windows.microsoft.com/en-us/windows/products/lifecycle#section_2
Esta situación expone a los equipos con dicho sistema operativo ya que no reciben actualizaciones de software ni parches de seguri-
dad, lo que convierte a dichos equipos en altamente vulnerables a las amenazas informáticas tales como virus, gusanos, troyanos,
spyware, rootkits, etc, lo que a su vez, podría originar falta de disponibilidad en dichos equipos y comprometer a los demás equipos
conectados a la red.
Se recomienda que la Gerencia General disponga que la Gerencia de Tecnología de Información y Comunicaciones evalúe y planifi-
que la renovación tecnológica de los equipos vulnerables o en su defecto se programe la migración del sistema operativo Windows XP
instalado en los equipos de la Entidad a una versión más reciente y que cuente con el soporte de parches y actualizaciones vigentes.
Se puede apreciar que el Auditor ha escrito el título de la observación, de tal manera que al leerla no nos quede
duda de que se trata la observación. Como dijimos, el titulo debe ser lo más preciso posible.
Luego del título, el primer párrafo pertenece a la descripción. Aquí el Auditor ha descrito la situación o debilidad
encontrada que origina riesgo. En este caso encontró 150 equipos con Sistema Operativo cuyo fabricante (Micro-
soft) ya no envía parches ya que esta fuera de soporte.
El segundo párrafo se refiere al riesgo que el auditor identificó. En este párrafo se describe claramente el riesgo
identificado, en este caso, los equipos están expuestos a ataques informáticos.
El último párrafo del hallazgo se refiere a la recomendación del auditor. El auditor recomienda la implementación
de algún tipo de control para minimizar el riesgo encontrado. En este caso el Auditor recomienda la renovación de
los equipos o la migración a un Sistema Operativo más seguro.
Veamos un segundo ejemplo.
Auditoría de sistemas
UNIDAD I: Introducción a la Auditoria de Sistemas MANUAL AUTOFORMATIVO 25
Ejemplo 2:
Se identificaron cuentas de personal cesado que permanecen activas en el Sistema ERP SAP.
Durante la revisión a la vigencia de los accesos en el sistema de información SAP, identificamos cuentas de usuarios de personal
cesado, según el reporte de cese emitido por Recursos Humanos, que permanecen activos en el sistema SAP, tales como:
Unidad
Código empleado Nombres Fecha de Cese Módulo SAP
Organizacional
Esta situación incrementa el riesgo de accesos no autorizados al sistema, mediante el uso de cuentas de personal cesado que se man-
tienen activas, después de su fecha de cese. El impacto asociado al riesgo identificado, dependerá de los permisos relacionados a los
accesos asignados a cada una de las cuentas.
Se recomienda realizar un seguimiento sobre la desactivación de dichas cuentas de usuarios en el Sistema SAP y realizar un moni-
toreo continuo sobre las cuentas de usuario de personal cesado.
En este segundo ejemplo, se puede apreciar que el Auditor nuevamente ha escrito el título de la observación, de
tal manera que al leerla no nos quede duda de que se trata la observación. El titulo debe ser lo más preciso posible.
Luego del título, el primer párrafo pertenece a la descripción. Aquí el auditor debe escribir la situación encontrada.
El segundo párrafo se refiere al riesgo que el auditor identifico. En este párrafo se describe el riesgo identificado.
El último párrafo del hallazgo se refiere a la recomendación del auditor. El auditor recomienda la implementación
de algún tipo de control para minimizar el riesgo encontrado.
Ejemplo 3:
De la revisión al Centro de Datos de la Entidad, se encontró que dicho Centro cuenta con deficiencias a nivel de seguridad ambien-
tal. Así tenemos las siguientes debilidades:
- 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.
Esta situación podría originar el riesgo de malfuncionamiento de los Servidores y de los equipos de comunicación ubicados en dicho
Centro, lo que podría originar a mediano plazo, interrupciones de los servicios y sistemas gestionados por la Oficina de Sistemas e
Informática.
Se recomienda que la Gerencia General, disponga la evaluación de las acciones necesarias para que la Oficina de Sistemas e Infor-
mática priorice las acciones necesarias para subsanar las debilidades encontradas.
Es importante que el Auditor escriba racionalmente las recomendaciones de cada uno de sus hallazgos. Las recomen-
daciones deben ser escritas en forma clara y no deben escribirse recomendaciones que puedan significar un desembol-
so significativo de dinero por parte del Auditado.
Tabla 1
Formulaci{on de recomendaciones
Reemplazar un Sistema de Información Disponer que la Gerencia General en conjunto con la Ge-
rencia de TI evalúen la posibilidad de cambiar el Sistema de
Información
Cambiar el 50% de las computadoras actuales del parque Evaluar la factibilidad de cambiar el 50% de las computado-
informático ras actuales del parque informático
El informe de Auditoria es el entregable final del trabajo de un Auditor. Típicamente es escrito en MS-Word y contiene
los siguientes componentes:
• Antecedentes
• Objetivo
• Alcance
• Limitaciones a la auditoria
• Conclusiones
Auditoría de sistemas
UNIDAD I: Introducción a la Auditoria de Sistemas MANUAL AUTOFORMATIVO 27
Una vez que el Auditor escribe el informe, éste estará en modo borrador.
• E
l informe se enviara al auditado (normalmente el Gerente de Sistemas) para darle la posibilidad de que responda
a los hallazgos encontrados.
• E
l Auditado revisará el informe y responderá a los hallazgos encontrados. Normalmente el Auditado se comprome-
te a cumplir con las recomendaciones de los hallazgos en una determinada fecha. Sin embargo, en algunas ocasio-
nes el Auditado podría oponerse a un determinado hallazgo, debido a que el Auditor se equivocó en el hallazgo o
debido a que la recomendación es imposible de ejecutar, ya que podría ser no beneficioso para los intereses de la
compañía.
• 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 más alto nivel de la Compañía (normalmente con el Gerente General)
para la comunicación de los resultados de la auditoría
ÍNDICE
Pág.
I. Síntesis gerencial 2
II. INTRODUCCIÓN 3
III. HALLAZGOS 5
IV. CONCLUSIONES 10
Síntesis Gerencial
El presente Examen Especial comprende la evaluación de los Sistemas Informáticos con los que cuenta la Compañía, los mecanismos
de seguridad informáticos, los mecanismos de contingencias y recuperación de desastres y la implantación del control interno en el
departamento de Informática dentro del período del 01.01.16 al 31.03.16.
1. El departamento de Informática realiza básicamente labores de soporte a los usuarios, no habiendo actividades de
desarrollo de Sistemas.
2. El departamento de Informática no cuenta con normatividad esencial para su funcionamiento. Específicamente
no cuenta con un Plan de Contingencias adecuado y además no cuenta con un Plan Estratégico de Sistemas.
4. La ejecución del proceso del backup se considera expuesta a demasiado riesgo, toda vez que los backups no son
almacenados adecuadamente en un lugar seguro.
Como resultado de esta acción de control se identificaron seis (6) hallazgos, y diversas deficiencias de control interno entre las que des-
tacan las relacionadas con deficiencias en la seguridad física, ejecución de backups de software base y la documentación relacionada,
por lo que con la finalidad de promover la superación de las causas que las motivaron, se proponen las siguientes recomendaciones
tanto al Comité Directivo, Gerencia A, Gerencia B y Gerencia C.
I. INTRODUCCIÓN
A continuación se presenta información general sobre el presente Examen al Departamento de Informática de la Compañía.
El Examen Especial al Departamento de Informática, por el período comprendido entre el 01.01.16 y 30.03.16, se realiza en cumpli-
miento del Plan Anual de Control para el 2016 del Órgano de Control Institucional de la Compañía.
Es importante destacar que las áreas relacionadas con el Departamento de Informática no han sido materia de acciones de control
posterior en los últimos dos años.
Esta acción de control consiste en un Examen Especial y tiene como objetivos generales y específicos los siguientes:
Objetivo General
Evaluar el adecuado uso de las Tecnologías de Información incidiendo en software, hardware, comunicaciones, seguridad y control de
calidad, así como evaluar la adecuada organización, planificación y administración del Área de Informática.
Objetivos específicos
a) Evaluar el Sistema Informático con el que cuenta la Compañía, determinando si los aplicativos actuales satisfacen las necesidades
de la Compañía, la interrelación de sus aplicativos, su grado de funcionamiento y los controles implementados.
b) Evaluar los mecanismos de Seguridad Informáticos implantados en la Compañía para asegurar la integridad de la información
y de los recursos informáticos de la Compañía.
c) Evaluar los mecanismos de Contingencias y recuperación de desastres de la Oficina de Informática para minimizar los riesgos de
interrupciones y/o paralizaciones en el servicio.
d) Determinar el grado de cumplimiento del sistema de Control Interno del departamento de Informática.
El alcance del Examen Especial al Departamento de Informática está referido a todas las acciones de control posterior y demás activida-
des desarrolladas para lograr un adecuado y oportuno funcionamiento de los sistemas de la Compañía, ejecutadas durante el periodo
comprendido entre el 01.01.16 y 30.03.16.
De acuerdo con el Plan Anual de Control 2016, los procesos ó áreas a ser examinados serán la administración eficiente de los recursos
destinados al desarrollo de actividades del Departamento de Informática; el nivel de seguridad de los recursos informáticos, el nivel de
cumplimiento de objetivos del área; aplicación de las normas legales e internas que regulan la labor de informática y la realización de
Auditoría de sistemas
UNIDAD I: Introducción a la Auditoria de Sistemas MANUAL AUTOFORMATIVO 29
El presente examen especial se desarrolló en la ciudad de Lima, en las instalaciones del local institucional de la Compañía. El plazo
inicialmente estimado para el desarrollo de este examen se vio ampliado debido a la solicitud de ampliación de plazo presentada por el
Gerente A y la Directora de Informática para la presentación de sus comentarios y aclaraciones en relación con los hallazgos comuni-
cados; así como al plazo adicional otorgado a los mencionado funcionarios.
Por ser de importancia para los fines del presente informe, es preciso resaltar los siguientes hechos o circunstancias verificados durante
el desarrollo de esta acción de control posterior, relacionados con los objetivos de ésta y con las situaciones evidenciadas en la Compa-
ñía:
a) Durante la revisión del software con el que cuenta la Compañía, se pudo apreciar que la Compañía no cuenta con un aplicativo
que le permita llevar el control de las partidas presupuestales. Se pudo evidenciar que actualmente, el sistema de Contabilidad
SISCONT no cuenta con información de control que sirva como instrumento para la toma de decisiones relacionadas al Presu-
puesto. Las actividades de formulación y control de los montos ejecutados y pendientes son realizadas de forma manual.
II. HALLAZGOS
Durante el desarrollo de esta acción de control se determinaron las siguientes observaciones, las cuales incluyen los comentarios y
aclaraciones de los funcionarios de la Compañía.
De la revisión a la estructura de la Base de Datos del Sistema CORE1 (Sistema de Información Gerencial), se evidenció que de un total
de 90 tablas, 18 tablas no contenían llaves primarias (es la que permite identificar cada registro individual de los demás registros en
una determinada tabla).
Esto se debe a que en el Departamento de Informática no existen procedimientos de monitoreo que permitan asegurar la integridad
referencial de la Base de Datos del Sistema CORE1.
Esta situación podría conllevar a que los registros de información presenten duplicidad en información, incrementa el riesgo de que la
Base de Datos del Sistema CORE1 contenga información no validada o información sujeta a errores.
Se recomienda que la Dirección de Informática priorice la implementación de la integridad referencial en la Base de Datos del Sistema
CORE1.
El Plan de Contingencias formulado por el Departamento de Informática, presenta algunas deficiencias, las cuales se detallan a
continuación:
a) El Plan de Contingencias no cuenta con los procedimientos de recuperación a seguir ante la ocurrencia de una eventualidad.
30 UNIDAD I: Introducción a la Auditoria de Sistemas
d) El Plan de Contingencias, siendo un documento confidencial, ha sido distribuido a todas las Jefaturas
La falta de procedimientos en el Plan de Contingencias origina que la Compañía no esté preparada para afrontar la ocurrencia de una
situación de emergencia o desastre, la cual podría devenir en cortes y/o interrupciones prolongadas del servicio informático ofrecido
por el Departamento de Informática.
Se recomienda que la Gerencia General disponga que la Directora de la Oficina de Informática evalúe la priorización de la actualiza-
ción del Plan de Contingencias, definiendo las siguientes actividades:
De la revisión y evaluación de la documentación de Planeamiento se determinó que el Departamento de Informática no cuenta un Plan
de Sistemas, el cual es una herramienta de gestión que establece las necesidades de información de la Compañía, teniendo el propósito
de prever el desarrollo de los recursos físicos y lógicos con un horizonte temporal determinado, de manera que contribuya efectivamente
con los objetivos de la Compañía.
El Departamento de Informática en la actualidad cuenta con un Plan de Actividades que muestra las actividades realizadas en dicho
periodo.
Esta situación podría conllevar que las actividades del área Informática no se encuentren alineadas con los objetivos institucionales y
estratégicos de la Compañía así como a los requerimientos de la empresa; Además el no contar con un Plan de Sistemas a largo plazo,
origina que la empresa no se comprometa a destinar recursos suficientes para el cumplimiento de los mismos.
Se recomienda que la Dirección de la Oficina de Informática evalúe la priorización de elaborar el Plan de Sistemas de Información, el
cual debe estar alineado con los Objetivos Institucionales trazados en el Plan Estratégico de la Compañía. Específicamente el Plan de
Sistemas debe contener:
• Diagnóstico de la situación informática actual con la finalidad de saber las capacidades actuales de la Compañía;
· Elaboración de objetivos y estrategias del sistema de información que sirva de base para apoyar la misión y los objetivos de la
Compañía;
· Desarrollo del modelamiento de datos para determinar qué información es necesaria para la Compañía;
· Generación, ordenamiento y priorización (por nivel de importancia e inversión) sistemática de los proyectos informáticos;
· Programación de los tiempos requeridos para la puesta en marcha de los proyectos designados, estimando el período de vida de cada
proyecto.
Se comprobó que los backups son elaborados de forma semanal, guardándose en un disco de uno de los Servidores del Departamento
Auditoría de sistemas
UNIDAD I: Introducción a la Auditoria de Sistemas MANUAL AUTOFORMATIVO 31
de Informática. Dichos backups de manera quincenal son almacenados en cinta. Las cintas son luego, guardadas en la Gerencia de
Administración, en un estante que no brinda ninguna seguridad ni protección para el buen estado de las cintas.
Esta situación pone en riesgo la continuidad del servicio ofrecido por el Departamento de Informática, toda vez que ante la ocurren-
cia de un desastre, existe el riesgo de no contar con los recursos necesarios para restaurar el servicio ofrecido por el Departamento de
Informática.
Se recomienda que la Directora de la Oficina Informática defina un procedimiento que garantice el adecuado almacenamiento de los
backups. Se recomienda que los backups se almacenen en la caja fuerte del departamento de Administración. Asimismo definir un
procedimiento que permita a la Directora de Informática contar con el acceso a dicha caja fuerte solo en los casos de la ocurrencia de
alguna eventualidad.
De la revisión a los procedimientos de monitoreo de la seguridad lógica, se evidenció que el Departamento de Informática no realiza
ningún monitoreo periódico de actividades de uso y acceso a los recursos informáticos de la Compañía, con el fin de determinar el uso
correcto de dichos recursos, así como detectar intentos de violación y/o acceso no autorizados a los recursos informáticos de la Compa-
ñía.
Así tenemos que no se encontró evidencia de la realización de un monitoreo periódico a las actividades de uso de Internet, tráfico de
correo, tráfico sospechoso por la red, actualización de cliente antivirus, cambio de passwords, ni de intentos de acceso o acceso no au-
torizado a los recursos informáticos administrados por el Departamento de Informática.
Esta situación origina que no se detecten los intentos de acceso o los accesos no autorizados a los recursos informáticos de la Compañía
e incluso podría devenir en fuga de información sensitiva fuera de la Compañía.
Se recomienda que la Directora de la Oficina de Informática elabore un calendario periódico que permita definir fechas de realización
del monitoreo de las actividades de uso y acceso a los recursos informáticos de la Compañía. Asimismo como resultado de dicho moni-
toreo se debe informar a la Gerencia de las actividades encontradas en dicho monitoreo, con el objeto de realizar las acciones correctivas
correspondientes contra el o los infractores.
6. NO EXISTE UN PROCEDIMIENTO FORMAL QUE REGULE EL ACCESO REMOTO A LOS SERVIDORES DE
LA COMPAÑIA
Durante la inspección realizada para verificar los controles de acceso lógico implementados en la Compañía, se pudo verificar que la
Directora de Informática ha realizado en un par de ocasiones el acceso remoto a los recursos de la Compañía. Este acceso remoto se
realiza a través de Internet. A la fecha de nuestra revisión, este acceso no se encontraba normado.
Esta situación podría ocasionar un acceso no autorizado de información, toda vez que al tratarse de un acceso remoto, no se necesita
estar dentro de las instalaciones de la Compañía.
Se recomienda que la Dirección de la Oficina de Informática defina un procedimiento que regule el acceso a los recursos informáticas
vía acceso remoto. Asimismo como parte de las actividades del procedimiento se debe emitir un informe a la Gerencia ha, informando
las actividades realizadas para cada uno de los accesos remotos ocurridos.
III. CONCLUSIONES
Como resultado del examen especial realizado, arribamos a las siguientes conclusiones:
1. El departamento de Informática no cuenta con un Plan de Contingencias actualizado y completo, debido a que no
se ha priorizado la definición de los procedimientos de recuperación del Plan de Contingencias.
2. El departamento de Informática no cuenta con un Plan de Sistemas de Información, debido a que el Departamen-
to de Informática basa la ejecución de sus actividades en un Plan de Actividades anual, el cual contiene la descrip-
ción y cronograma de ejecución de dichas actividades.
32 UNIDAD I: Introducción a la Auditoria de Sistemas
3. Los respaldos de información (backups) no son almacenados en un lugar seguro, debido a que no se han tomado
todas las medidas necesarias para garantizar la disponibilidad, protección y buen estado de las cintas, necesarias
ante la ocurrencia de alguna contingencia.
4. No se ejecuta un monitoreo periódico de las actividades de uso y acceso a los recursos informáticos de la Compa-
ñia, debido a que no se ha previsto la realización de un cronograma de monitoreo de uso y acceso a los recursos ni
al seguimiento del cumplimiento de normas y políticas del Departamento.
5. No existe un procedimiento formal que regule el acceso remoto a los servidores de la Compañia, debido a que no
se ha previsto la formulación de un procedimiento que regule el acceso remoto a los recursos informáticos de la
Compañía.
En conclusión, se advierte que los sistemas de información y la infraestructura tecnológica que administra la Oficina de Informática
cuentan con controles deficientes que necesitan ser subsanados para proteger adecuadamente a la Compañía.
Auditoría de sistemas
UNIDAD I: Introducción a la Auditoria de Sistemas MANUAL AUTOFORMATIVO 33
INTRODUCCIÓN
En esta sección revisaremos los principales marcos de referencia internacionales que son utilizados por el Auditor de
Sistemas.
1 Regulaciones Internas
La SBS es una entidad reguladora que supervisa el funcionamiento de las entidades financieras que incluye la banca,
seguros y sistema privado de pensiones; así como la de prevenir el lavado de activos. Todo esto para lograr el objetivo
de preservar los intereses de los depositantes, asegurados y afiliados a las AFPs.
Entre sus funciones está a función de supervisión de dichas entidades en función a los diferentes tipos de riesgos tales
como riesgo crediticio, de mercado, de liquidez, operacional y legal.
Dentro del riesgo operacional está el riesgo relacionado a las tecnologías de información. En ese contexto, la SBS pú-
blica normas que son de carácter obligatorio para las entidades mencionadas. Entre las normas más relevantes para la
Auditoria de Sistemas se tiene las circulares G-139 y G-140.
La circular G-139-2009-SBS obliga a las entidades financieras a mantener una gestión de la continuidad del negocio
como un proceso, efectuado por el Directorio, la Gerencia y el personal, que implementa respuestas efectivas para que
la operatividad del negocio de la empresa continúe de una manera razonable, con el fin de salvaguardar los intereses
de sus principales grupos de interés, ante la ocurrencia de eventos que pueden crear una interrupción o inestabilidad
en las operaciones de la empresa.
Las empresas deben realizar una gestión de la continuidad del negocio adecuada a su tamaño y a la complejidad de
sus operaciones y servicios.
Por su lado, la circular G-140-2009-SBS obliga a las entidades financieras establecer, mantener y documentar un Sis-
tema de Gestión de Seguridad de la Información (SGSI) tomando como referencia las normas internacionales ISO
17799 e ISO 27001.
La CGR es la máxima autoridad del Sistema Nacional de Control. La CGR supervisa, vigila y verifica la correcta apli-
cación de las políticas públicas y el uso de los recursos y bienes del Estado Peruano. Para realizar con eficiencia sus
funciones, cuenta con autonomía administrativa, funcional, económica y financiera
En ese contexto, la Contraloría emite normas que son de cumplimiento obligatorio para las entidades del Sector Pu-
blico.
La Norma que gobierna las actividades de Auditoria son las Normas Generales de Control Gubernamental. Puedes en-
contrar las Normas Generales en: http://doc.contraloria.gob.pe/libros/2/pdf/RC_273_2014_CG.pdf . Si le das una leí-
da, estas normas tienen muchos de los componentes que revisamos en el acápite 2.2 Estándares de ISACA del tema 1.
34 UNIDAD I: Introducción a la Auditoria de Sistemas
A nivel de Auditoria de Sistemas, las Normas que debemos tomar en cuenta son las Normas de Control Interno que
están vigentes desde el 2006. En este documento en la sección III tenemos 3 cláusulas que se deben tener en cuenta:
“El componente evaluación de riesgos abarca el proceso de identificación y análisis de los riesgos a los que está
expuesta la entidad para el logro de sus objetivos y la elaboración de una respuesta apropiada a los mismos. La
evaluación de riesgos es parte del proceso de administración de riesgos, e incluye: planeamiento, identificación,
valoración o análisis, manejo o respuesta y el monitoreo de los riesgos de la entidad”.
“Los sistemas de información diseñados e implementados por la entidad constituyen un instrumento para el
establecimiento de las estrategias organizacionales y, por ende, para el logro de los objetivos y las metas. Por
ello deberá ajustarse a las características, necesidades y naturaleza de la entidad. De este modo, el sistema de
información provee la información como insumo para la toma de decisiones, facilitando y garantizando la trans-
parencia en la rendición de cuentas”.
El texto completo del documento Normas de Control Interno lo puedes ubicar en:
http://controlinterno.concytec.gob.pe/images/stories/2012/normatividad/RCG_320_2006_CG.pdf
http://doc.contraloria.gob.pe/documentos/PREGUNTAS_FRECUENTES_2015.pdf
Esta ley obliga a las compañías a tomar medidas para preservar los datos personales que las compañías tienen de las
personas naturales, es decir proteger la privacidad de las personas. ¿Qué se entiende por privacidad? Se refiere al
ámbito de la vida personal de un individuo que se desarrolla en un espacio reservado y debe mantenerse de manera
confidencial.
La ley define a los datos personales a toda aquella información sobre una persona natural que la identifica o la hace
identificable a través de medios que pueden ser razonablemente utilizados. Así por ejemplo tenemos Nombres, Apelli-
dos, DNI, teléfonos, dirección domicilio, correo electrónico, fecha de nacimiento, sexo, Nro. Identificación tributaria,
Razón Social, Nro. De cuenta bancaria.
Asimismo, la ley define un tipo especial de datos personales. Nos referimos a los datos sensibles. Los Datos Sensibles
son los Datos personales constituidos por los datos biométricos que por sí mismos pueden identificar al titular; datos
referidos al origen racial y étnico; ingresos económicos, opiniones o convicciones políticas, religiosas, filosóficas o
morales; afiliación sindical; e información relacionada a la salud o a la vida sexual. Un claro ejemplo de datos sensibles
son los Sueldos de los trabajadores en una compañía.
Auditoría de sistemas
UNIDAD I: Introducción a la Auditoria de Sistemas MANUAL AUTOFORMATIVO 35
Las compañías están obligadas a inscribir los Bancos de datos que contienen datos personales. Un banco de Datos es
un conjunto de datos personales. De nuestra experiencia, hemos podido identificar que toda compañía tiene al menos
4 Bancos de Datos que contienen datos personales:
• Clientes
• Trabajadores
• Visitantes
Uno de los temas más importantes de la Ley son los Derechos ARCO. Estos son los derechos fundamentales a los que
una persona tiene derecho y que pueden ser usados con una compañía que tiene sus datos personales. Los derechos
son:
• Acceso. Una persona tiene derecho a saber que datos tiene una compañía de ella.
• Rectificación. Una persona tiene el derecho a rectificar cualquier dato erróneo que una compañía tenga de ella.
• C
ancelación. La persona tiene derecho a que la compañía borre la información de ella. Esto, siempre y cuando,
no haya una relación existente. Por ejemplo un trabajador no puede pedir a su compañía que borre toda la infor-
mación de ella.
• O
posición. Un apersona puede oponerse a que una compañía use sus datos personales para un uso particular. Por
ejemplo, una persona puede oponerse a que le envíen publicidad.
El cumplimiento de la Ley está a cargo de la Autoridad Nacional de Protección de datos personales (ANPDP) que
depende del Ministerio de Justicia. La ANPDP emitió la Directiva de Seguridad que define los controles tecnológicos,
legales y administrativos que las compañías deben seguir para proteger los datos personales.
Entre los controles tecnológicos más importantes esta la implementación de un Sistema de Gestión de Seguridad de la
Información, controles criptográficos, controles de acceso, respaldo, entre otros.
Puedes ver un video de la Autoridad nacional de Protección de datos personales en: https://www.youtube.com/wat-
ch?v=1c4YMd_YaRs
2 Regulaciones externas
El Committee of Sponsoring Organizations of the Treadway – Enterprise Risk Management, más conocido como
COSO ERM es una marco de referencia (framework) de riesgos empresariales. Actualmente está en la versión 3. El
marco es formulado por la Organización COSO que es un comité voluntario de 5 instituciones y que está orientado
a gestionar tres temas fundamentales: la gestión del riesgo empresarial (ERM), el control interno, y la disuasión del
fraude en las compañías.
La idea del COSO es promover la gestión de riesgos en todos los niveles de la compañía y establece directrices para la
toma de decisiones de los líderes de las compañías para el control de los riesgos y la asignación de responsabilidades.
• Entorno de control
• Evaluación de riesgos
• Actividades de Control
36 UNIDAD I: Introducción a la Auditoria de Sistemas
• Información y Comunicación
• Actividades de supervisión
Todas las compañías que gestionan el riesgo (no solo el riesgo de TI) utilizan este framework como guía para sus ac-
tividades. Si deseas saber más sobre el COSO ERM, puedes acceder a un resumen ejecutivo en la siguiente dirección:
http://doc.contraloria.gob.pe/Control-Interno/Normativa_Asociada/coso_2013-resumen-ejecutivo.pdf
2.2 CobiT 5.
Es el marco de referencia (framework) más importante de TI para el gobierno y la gestión de las TI en una compañía.
No existe documento más importante en TI que el CobiT.
Según el documento Cobit5 Introducción:”COBIT 5 ayuda a las Compañías a crear un valor óptimo a partir de la TI,
al mantener un equilibrio entre la realización de beneficios y la optimización de los niveles de riesgo y utilización de
los recursos.
COBIT 5 permite que las tecnologías de la información y relacionadas se gobiernen y administren de una manera holística
a nivel de toda la Organización, incluyendo el alcance completo de todas las áreas de responsabilidad funcionales y de
negocios, considerando los intereses relacionados con la TI de las partes interesadas internas y externas”.
Satisfacer las
necesidades
de los
stackeholders.
Separar Cubrir
Gobierno de totalmente la
Gestión. empresa.
Principios
Aplicar un
Habilitar
único marco
un enfoque
de referencia
holístico.
integrado.
Asimismo, Cobit5 define 7 habilitadores. Este término algo extraño no es más que los factores que, individual y colec-
tivamente, influyen sobre si algo funcionarán – en este caso, el Gobierno y la Gestión de la TI.
Gráfico 3 - Los 5 principios de Cobit5.
Fuente: ISACA. Auditoría de sistemas
UNIDAD I: Introducción a la Auditoria de Sistemas MANUAL AUTOFORMATIVO 37
Asimismo, Cobit5 define 7 habilitadores. Este término algo extraño no es
más que los factores que, individual y colectivamente, influyen sobre si al-
go funcionarán – en este caso, el Gobierno y la Gestión 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.
COBIT 5 une los cinco principios que permiten a la Organización construir un marco efectivo de Gobierno y Gestión
COBIT 5 une los cinco principios que permiten a la Organización construir
basado en los siete habilitadores, para que juntos,
un marco efectivo optimicen
de Gobierno la inversión
y Gestión basadoen en
tecnología
los sietede información así como su uso
habilitadores,
en beneficio de las partespara
interesadas.
que juntos, optimicen la inversión en tecnología de información así
Asimismo,como su usode
uno en los
beneficio
temas de transcendentales
las partes interesadas.
del CobiT es que separa el
Asimismo, uno de Gobierno
los temas transcendentales
de TI de la Gestión deesTI.
del CobiT queDurante
separa elmuchos
Gobiernoañosde TI se
de la
usóGestión de TI. Durante
indistin-
muchos años se usó indistintamente ambos conceptos, pero ahora se tienen claramente
tamente ambos conceptos, pero ahora se tienen claramente diferenciados. diferenciados.
Gobierno de TI es la definición de los objetivos de TI (en función de los ob-
Gobierno de TI es jetivos
la definición de los objetivos de TI (en función de los objetivos de Negocio). 35
de Negocio).
Gestión de TI es el logro de los objetivos trazados. Por tanto un gestor es
Gestión de TI es el logro de los objetivos trazados. Por tanto un gestor es aquel que logra que las cosas se hagan. ¿Qué
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 separación de los dominios de CobiT separando el
La figura 5 presenta la separación de los dominios de CobiT separando el Gobierno de la Gestión
Gobierno de la Gestión
Fuente: ISACA
Figura 6. Mapa de Procesos de CobiT.
En función a ello, CobiT define un conjunto de 37 procesos, tal como se presentan a continuación:
36
Auditoría de sistemas
UNIDAD I: Introducción a la Auditoria de Sistemas MANUAL AUTOFORMATIVO 39
Para los Auditores, los temas de Gobierno de TI son de mucha utilidad ya que el Auditor puede evaluar la definición
de objetivos de TI en función de los Objetivos de Negocio.
Por el lado de Gestión de TI, el Auditor puede evaluar los procesos que en su conjunto persiguen el logro de los ob-
jetivos de TI.
La Familia ISO 27000 es un conjunto de normas internacionales relacionadas a la seguridad de la Información. Esta
familia tiene cerca de 40 normas. En este curso nos centraremos en las 2 normas más importantes de la familia: La
Norma ISO 27001 y la norma ISO 27002.
No, no nos hemos equivocado en la numeración. Primero vamos a presentar la ISO 27002 y lo vamos a hacer
antes de la ISO 27001.
La Norma ISO 27002:2013 define un conjunto de requisitos presenta un total de 14 Capítulos (en la norma se
llaman Dominios), 35 Objetivos de Control y 114 Controles que una compañía debe implementar para proteger
su información.
–– Política de Seguridad
–– Gestión de Activos
–– Control de Accesos
–– Criptografía
–– Cumplimiento
http://www.iso27000.es/download/ControlesISO27002-2013.pdf
Antes esta norma se llamaba ISO 17799, a veces los cambios de numeración confunden. En el Perú existe la Norma
40 UNIDAD I: Introducción a la Auditoria de Sistemas
Técnica Peruana NTP ISO/IEC 17799, que es el equivalente a la ISO 27002:2013. Que no te sorprenda la numeración!
La Presidencia del Consejo de Ministros obliga a las Entidades del Estado a cumplir con esta Norma.
Esta norma pretende la implementación de un Sistema de Gestión de Seguridad de la Información, más común-
mente conocido como SGSI. La ISO 27001 define un conjunto de requisitos para establecer, implementar, man-
tener y mejorar un SGSI dentro de una Compañía. Asimismo define requisitos para la evaluación y tratamiento
de riesgos de seguridad de la información.
En el Perú la Norma Técnica Peruana Vigente es la NTP ISO/IEC
27001:2014.
El Sistema de Gestión de la Seguridad de la Información (SGSI) en las compañías ayuda a establecer políticas,
A la fecha existen más de 10 compañías en el Perú que han obtenido
procedimientos y controles en relación a los objetivos de negocio.
el certificado ISO 27001. Entre las que se pueden mencionar a: Aten-
En el Perú lato, GMD,
Norma Hermes
Técnica transportes
Peruana Vigente esblindados, Hochschild
la NTP ISO/IEC Minning PLC, In-
27001:2014.
decopi, Oficina de Normalización Previsional ONP, PMC Latam, Secure
Soft, más
A la fecha existen Telefónica del Perú,enTelefónica
de 10 compañías el Perú queEmpresas y Telefónica
han obtenido Gestión
el certificado de Entre las que se
ISO 27001.
Servicios Compartidos Perú SAC
pueden mencionar a: Atento, GMD, Hermes transportes blindados, Hochschild Minning PLC, Indecopi, Ofi-
cina de Normalización Previsional ONP, PMC Latam, Secure Soft, Telefónica del Perú, Telefónica Empresas y
Cualquier
Telefónica Gestión compañía
de Servicios puede tomar
Compartidos la decisión de certificarse. Existen
Perú SAC
mecanismos de implementación que requieren el apoyo de la Alta Ge-
rencia. Un
Cualquier compañía ejemplo
puede tomar lade la Certificación
decisión la Existen
de certificarse. puedesmecanismos
observar deen implementación
el si- que re-
guiente
quieren el apoyo de lagráfico:
Alta Gerencia. Un ejemplo de la Certificación la puedes observar en el siguiente gráfico:
La Ley Sarbanex-Oxley es una ley federal de los Estados Unidos cuyo objetivo es monitorear a las compañías que coti-
zan en la Bolsa de valores, a través de controles contables para que el valor de las acciones no sean “manipuladas” en
deterioro de los accionistas. Esta ley fue aprobada en el año 2002 después de la quiebra en el 2001 de la gigantesca
compañía energética Enron que manipulo escandalosamente sus cifras contables para que la cotización de sus accio-
nes siempre estuviese alta. Cuando sucede la quiebra de Enron sus acciones pasaron de costar USD 90 a costar USD
0.30, lo que significó un desastre financiero para sus accionistas. En realidad, Enron fue “la gota que derramo el vaso”,
toda vez que existieron otras quiebras como las de las compañías Tyco International, WorldCom y Peregrine Systems
que aumentaron la desconfianza en las compañías que cotizaban en bolsa y en las compañías de Auditoria que realiza-
ban la Auditoria Financiera. De hecho, una de las grandes compañías de Auditoria quebró también. La compañía se
llamaba Arthur Andersen, quienes se hicieron “de la vista gorda” con las prácticas contables de Enron.
Los puntos más importantes que introdujo la Ley Sarbanes-Oxley fueron de índole contable, que afectan a la TI ya que
los sistemas contables corren en ambientes tecnológicos.
• S
e creó la Public Company Accounting Oversight Board (PCAOB por sus siglas en inglés), que es una Entidad que
debe supervisar las auditorías de las compañías que cotizan en bolsa.
• E
s obligatorio que las compañías que cotizan en bolsa garanticen la veracidad de las evaluaciones de sus controles
internos en sus informes financieros, así como que los auditores independientes de estas compañías constaten esta
transparencia y veracidad.
• Los estados financieros deben estar certificados por parte del comité ejecutivo y financiero de la compañía.
• S
e exige que las compañías que cotizan en bolsa tengan un comité de auditoría, con personal completamente in-
dependiente, que supervisen la relación entre la compañía y sus auditores externos
• Transparencia de la información de acciones y opciones, de la compañía en cuestión, que puedan tener los directi-
vos, ejecutivos y empleados claves de la compañía y consorcios, en el caso de que posean más de un 10 % de accio-
nes de la compañía. Asimismo estos datos deben estar reflejados en los informes de las compañías.
• E
ndurecimiento de la responsabilidad civil y penal por incumplimiento de la Ley Sox. La ley amplia las penas de
prisión y las multas a los altos ejecutivos que incumplen y/o permiten el incumplimiento de las exigencias finan-
cieras.
Dado que en el Perú operan filiales de compañías estadounidenses que cotizan en bolsa, es común auditar a las filiales
peruanas en el cumplimiento de la Ley Sox.
Para terminar sobre la ley, te recomiendo que veas el famoso documental sobre el caso Enron: Los tipos que estafaron
América. Lo puedes encontrar en: https://www.youtube.com/watch?v=mnyzZ7r1zdA
Son un conjunto de normas de regulación bancaria para las instituciones bancarias, que se encuentran vigentes des-
de el 2010, orientadas a proporcionar las mecanismos eficientes para mejorar la capacidad de respuesta del sistema
bancario ante perturbaciones económicas y financieras (burbujas, debacles, etc) y conseguir así una mayor estabilidad
financiera mundial.
Estas normas reemplazan a Basilea II, y fueron la respuesta regulatoria para superar los riesgos que sufrieron las insti-
tuciones financieras debido a la crisis hipotecaria que golpeó a Estados Unidos y se esparció por todo el mundo en el
año 2008.
Las Normas son emitidas por el Comité de Supervisión Bancaria de Basilea del Bank of International Settlements( BIS)
o Banco de Pagos Internacionales, que es el Banco Central de los Bancos Centrales, cuya sede está en Basilea, Suiza.
42 UNIDAD I: Introducción a la Auditoria de Sistemas
Las Normas de seguridad de datos de la industria de tarjetas de pago (PCI DSS) se desarrollaron para fomentar y me-
jorar la seguridad de los datos del titular de la tarjeta y facilitar la adopción de medidas de seguridad uniformes a nivel
mundial. Las PCI DSS proporcionan una referencia de requisitos técnicos y operativos desarrollados para proteger los
datos de los titulares de tarjetas.
Las PCI DSS se aplican a todas las entidades que participan en el procesamiento de tarjetas de pago, entre las que se
incluyen comerciantes, procesadores, adquirientes, entidades emisoras y proveedores de servicios, como también to-
das las demás entidades que almacenan, procesan o transmiten CHD (datos del titular de la tarjeta) o SAD (datos de
autenticación confidenciales).
Las normas abarcan 12 la seguridad de las redes, la seguridad del titular de la tarjeta, gestionar las vulnerabilidades,
medidas de control de acceso, la supervisión y evaluación periódica de las redes, y políticas de seguridad de la infor-
mación para todo el personal.
Asimismo,
Diagrama
la norma
Objetivos Inicio
está disponible en: https://es.pcisecuritystandards.org/minisite/en/pci-dss-v3-0.php
ACTIVIDAD N.° 1
Desarrollo Actividades Autoevaluación
de contenidos
Participa en el Foro de discusión sobre “Los riesgos originados por el uso de las Tecnologías de Información en las
organizaciones”.
Lecturas Glosario Bibliografía
seleccionadas INSTRUCCIONES
• Lee y analiza un caso sobre riesgos originados por el uso de las TICs.
Recordatorio Anotaciones
• Diagrama
Expresa tus opiniones
Objetivos Inicio en relación al caso en el foro de discusión que se encuentra en el aula virtual.
CONTROL DE LECTURA Nº 1
Lecturas Glosario Bibliografía
seleccionadas
Recordatorio Anotaciones
Auditoría de sistemas
Diagrama
UNIDAD I:Inicio
Objetivos
Introducción a la Auditoria de Sistemas MANUAL AUTOFORMATIVO 43
GLOSARIO DE LA UNIDAD I
Lecturas Glosario Bibliografía
seleccionadas
Causa: En el contexto de un hallazgo de Auditoria en el Sector Publico se refiera a la(s) razón(es) fundamental(es)
por la cual ocurrió la condición o el motivo por el que no se cumplió el criterio o la norma.
CISA: Acrónimo de Certified Information Systems Auditor. Es la certificación internacional más reconocida en el ám-
bito de la Auditoria de Sistemas.
Control: Es cualquier cosa que minimiza un riesgo. Por ejm. escribir un procedimiento, implementar un firewall, ins-
talar un antivirus, ejecutar un respaldo (backup), etc.
Criterio. En el contexto de un hallazgo de Auditoria en el Sector Publico se refiere a la(s) norma(s) transgredida(s).
Daño: Es el impacto negativo que tenemos si la amenaza se aprovecha de la(s) vulnerabilidad(es). El daño pude ser
económico, patrimonial, de imagen, etc.
Hallazgo de Auditoria: Es la descripción que hace un Auditor de Sistemas para dar a conocer una situación de riesgo.
ISACA. Acrónimo de Information Systems Audit and Control Association(ISACA) que es la institución mundial más
importante en Auditoria de Sistemas.
Riesgo: Es la probabilidad que una amenaza se aproveche de una vulnerabilidad y nos genera un daño.
Objetivos Vulnerabilidad:
Inicio es cualquier deficiencia que tenga un activo informático.
Actividades Autoevaluación
os
BIBLIOGRAFÍA DE LA UNIDAD I
Glosario Bibliografía
s
Information systems audit and control association. (2016). CISA Re-view Manual. Chicago: ISACA.
o Anotaciones
Information systems audit and control association. (2012) COBIT 5 Un marco de negocio para el Gobierno y la Gestión de la
TI en la Empresa. USA: ISACA.
44 UNIDAD I: Introducción a la Auditoria de Sistemas
Objetivos Inicio
AUTOEVALUACIÓN DE LA UNIDAD I
Actividades Autoevaluación
s
1. Ud. está planificando una auditoria al área de Sistemas de la compañía farmacéutica Pharmax. Al respecto, ¿Cuál
s
Glosario
de los siguientes NO sería parte de su planificación de Auditoria?
Bibliografía
D) Demuestre lo indicado
3. Ud. está realizando el seguimiento a observaciones de auditoria de sistemas del periodo anterior para una compa-
ñía del sector público, Ud. encuentra que solo existe una observación por subsanar y que dicha observación cuenta
con la siguiente estructura:
Descripción
Criterio
Riesgo
Causa
Recomendación
Conclusión
C)
La clasificación del riesgo encontrado por el auditor
D) La amenaza
Auditoría de sistemas
UNIDAD I: Introducción a la Auditoria de Sistemas MANUAL AUTOFORMATIVO 45
Durante la visita efectuada al área de TI, se observó que no existe una configuración de redes virtuales (VLANs)
en las sedes de la compañía, que permitan segmentar el enrutamiento de los datos y mitigar el riesgo de un ac-
ceso ilimitado a toda la red. Recientemente, el área de TI evidenció la adquisición de 2 switches (por renovación
tecnológica), que permitirían la configuración de dichas redes virtuales. El Gerente de TI indicó que las VLANs
serán implementadas como parte del proyecto de Comunicaciones Unificadas (CISCO Telephony) la cual estará
programada para finales de enero 2016 o inicios de febrero 2016. Si bien existe una propuesta técnica y un contra-
to elaborado para iniciar la implementación, al cierre de la revisión aún se encuentra pendiente la formalización
e inicio del Proyecto Comunicaciones Unificadas.
El riesgo ya se ha materializado, ya que se evidenció que hace 3 meses, un atacante logro acceder a la red desde el
exterior y tuvo acceso a los servidores de la compañía, lo que significó una paralización de la red por 2 días. Esto
se debió a que la red no cuenta con las VLANs implementadas.
A) Se recomienda que el Gerente General contrate los servicios de una empresa especializada en implementación
de redes virtuales.
B) Se recomienda que el Gerente de TI tenga listo un script para configurar los switches para ganar tiempo apenas
aprueben el proyecto de Comunicaciones Unificadas.
C) Se recomienda que el Gerente General disponga que el Gerente de TI priorice la implementación de las redes
virtuales, sin esperar el inicio del proyecto de Comunicaciones Unificadas.
D) Se recomienda que el Gerente de TI logre la autorización del Gerente General para el proyecto de Comunica-
ciones Unificadas.
5. Ud. comprende la importancia de gobernar y gestionar adecuadamente las tecnologías de Información. Al respec-
to. Ud principalmente recomendaría utilizar el marco de referencia:
A) ITIL
B) CobiT
C) PMBOK
D) ISO 27002
A) ISO 27002
B) ISO 27001
C) Cobit5
D) COSO ERM
46 UNIDAD I: Introducción a la Auditoria de Sistemas
7. Una empresa trasnacional de alimentos con sede en Estados Unidos que cotiza en la Bolsa de New York (NYSE),
cuenta con una importante operación en Perú. ¿Cuál de las siguientes regulaciones estaría en obligación de cum-
plir la oficina en Perú?
A) CobiT
B) ISO 27001
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
D) Gobierno y Gestión
9. ¿Cuál de los siguientes es VERDADERO en relación a los derechos ARCO que tiene un ciudadano con respecto a
sus datos en poder tienen las compañías en el Perú en el marco de la Ley 29733 de Protección de Datos personales?
A) El derecho de Cancelación se refiere a que un ciudadano puede solicitar a una compañía que le cancele un
monto de dinero por el uso de sus datos.
B) El derecho de Oposición se refiere a que un ciudadano puede oponerse a algún tratamiento de sus datos como
por ejemplo no recibir publicidad de dicha compañía.
C) El derecho de Acceso se refiere a que un ciudadano puede solicitar que sus datos puedan ser accedidos de ma-
nera pública.
D) El derecho de Rectificación se refiere a que un ciudadano pueda solicitar a una compañía que elimine comple-
tamente los datos personales de dicho ciudadano.
10. Una importante grupo industrial que cotiza en la Bolsa de USA ha decidido instalar su oficina principal de Lati-
noamérica en el Perú y está revisando los temas regulatorios que debe cumplir para su correcto funcionamiento en
el país. Al respecto, ¿De Cuál de las siguientes regulaciones estará la compañía preocupada debido a que maneja
datos como pruebas de reacciones alérgicas en personas voluntarias a las pruebas?
B) Basilea III
C) SOX
D) ISO 27001
Auditoría de sistemas
UNIDAD II: Auditoria al Gobierno y Gestión de TI MANUAL AUTOFORMATIVO 47
autoevaluación BIBLIOGRAFÍA
Lecturas Glosario Bibliografía
seleccionadas
Actividad N.° 2
Participan en el Foro de discusión sobre “las
prácticas gerenciales en el área de Sistemas”.
INTRODUCCIÓN
En este tema nos iremos a 10,000 metros de altura para presentar los tópicos que gestiona un Gerente de Tecnología
de Información. Revisaremos los conceptos de Gobierno Corporativo, como impacta en la Organización y como la
gerencia de TI debe asegurar el Gobierno de TI en donde se definen los objetivos de TI alineados al Negocio. Luego
revisaremos las practicas Gerenciales que todo Gerente de TI debe aplicar para su adecuada gestión y luego aprende-
remos a auditar el Gobierno y la Gestión de TI.
El Gobierno Corporativo (Corporate Governace) es un conjunto de buenas prácticas que deben ser seguidos por una
compañía para alinear los objetivos de los accionistas o a los propietarios (en Perú normalmente una familia que con-
trola una empresa) la dirección y la administración de la empresa, a través de la definición y separación de roles estra-
tégicos, operativos, de vigilancia y gestión. Estas prácticas están orientadas a lograr una trasparencia sobre los riesgos
de una empresa, protegiendo a los inversionistas o a los propietarios evitando actos ilícitos o fraudulentos (Recuerde
el Caso Enron).
El Gobierno corporativo responde a la pregunta: ¿Qquien controla la empresa y porque? Las buenas prácticas de Go-
bierno Corporativo nacen como respuesta a la Crisis de los inversionistas (alineando los intereses de todas las partes
dentro de una Compañía.
En Perú, la Superintendencia del Mercado de Valores, precisa en el documento Código de Buen Gobierno Corporativo
para las Sociedades Peruanas que : “La adopción de prácticas de buen gobierno corporativo por parte de las socieda-
des, promueve un clima de respeto a los derechos de los accionistas y de los inversionistas en general; contribuye a
generar valor, solidez y eficiencia en las sociedades; trae consigo una mejor administración de los riesgos a los cuales
se encuentran expuestas; facilita el acceso al mercado de capitales; lleva a una reducción del costo de capital, así como
a un mayor y mejor acceso a fuentes de financiamiento y de inversión a largo plazo; entre otras ventajas. Asimismo, la
experiencia ha demostrado que en la medida que exista mayor transparencia e información, mayor es la confianza que
desarrollan los inversionistas en los mercados. Las prácticas de buen gobierno corporativo ayudan a mitigar las fallas
que existen en los mercados financieros por la asimetría de información”.
Asimismo, el citado documento indica que el Gobierno Corporativo se divide en cinco pilares:
• Riesgos y cumplimiento; y
• Transparencia de la Información.
Si te interesa aprender más sobre Gobierno Corporativo, puedes descargar el Código de Buenas Prácticas de Go-
bierno Corporativo para las sociedades peruanas. Lo puedes encontrar en: http://www.smv.gob.pe/Uploads/CodB-
GC2013%20_2_.pdf
1.2 Gobierno de TI
Al implementar Gobierno de TI, la gerencia general y la gerencia de TI dan el impulso para que TI cumpla con los
objetivos de la compañía. Para ello el Gerente de TI debe cambiar la forma como la TI ejecuta, permitiendo la traspa-
rencia y control del área de TI y gestionando los riesgos relacionados con la tecnología. Los Gerentes de TI exitosos
entienden y manejan los riesgos relacionados con la implementación de nuevas tecnologías.
Normalmente, estos planes son formulados en reuniones de los más altos directivos de la compañía (entre los
que debería participar el Gerente de TI) y definen el Plan del negocio a un horizonte de 5 años como máximo.
Es muy común encontrar Objetivos como ampliación de las ventas, ampliación de la participación del mercado,
expansión a otros países, regiones, reducción de costos, lanzamiento de nuevos productos o servicios, entre otros.
El Planeamiento de Tecnologías de Información se debe realizar poniendo el foco del plan en coherencia con
el Plan Estratégico Empresarial, que vimos en la Unidad anterior.
50 UNIDAD II: Auditoria al Gobierno y Gestión de TI
Cuando hablamos de Planeamiento de TI, los Gerentes de TI se preocupan de hacer un Plan a largo Plazo, para
definir como las TI impactaran en el Negocio.
Este plan se refleja en el llamado PETI, el cual es el acrónimo de Planeamiento Estratégico de TI, que es un
documento en el cual se plasma la visión, misión, objetivos de TI, el alineamiento de los objetivos de TI con el
negocio, y en función a ello, las metas y proyectos del área de TI.
Usualmente el PETI es formulado con un alcance de tres años de duración, ya que es imposible prever que
nuevas tecnologías aparecerán en los siguientes años.
Como recordará el Gobierno de TI tiene que ver con la definición de Objetivos de TI. A continuación presen-
taremos una tabla conteniendo ejemplos de alineamiento de TI con el Negocio.
Tabla 2
Ejemplos de Alineamiento de TI con el Negocio
Abrir oficinas en 3 nuevos países Ampliar la infraestructura tecnológica para el soporta de las
nuevas oficinas
Como se puede apreciar, los Objetivos de TI siempre deben estar orientados al logro de los objetivos del nego-
cio. Si un área de TI no está orientado a ese logro, los objetivos de TI serán puramente técnicos y no necesaria-
mente los intereses de TI coincidirán con los intereses del negocio, lo cual puede ser fatal para el negocio.
Cuando los intereses de TI no coinciden con los intereses del Negocio, el Negocio percibe que TI no da valor,
dando como resultado que nadie entiende que es lo que se hace en TI y eso aumenta la percepción de que TI
solo está para “arreglar teclados y corregir la impresora”, es decir el área de TI se convierte en un área de Sopor-
te Técnico.
Otro de los mecanismos de Planeamiento muy utilizados es el Comité de Sistemas. Este Comité de Sistemas es una
mejor práctica de la industria, en la cual de manera periódica (por ejemplo, trimestral) se reúnen la Alta Gerencia
con los Gerentes de la Compañía para supervisar el logro de los objetivos y el desempeño del área de TI.
Evidentemente, el Gerente de TI participa de estas reuniones de Alto Nivel en la cual se revisan los objetivos de
TI y los proyectos y se repriorizan los proyectos en función a las necesidades de la compañía.
Un ejemplo de conformación de un Comité de Sistemas podría ser: Presidente, Vicepresidente de Finanzas,
Vicepresidente de TI, Gerente de Marketing, Gerente de Ventas, Gerente de Producción, entre otros.
2.2 Normatividad
Una práctica importante para el Gerente de TI para optimizar su gestión es contar con la Normatividad adecuada.
Para ello, el Gerente de TI debe preocuparse que exista el árbol normativo adecuado.
2.2.1 Políticas.
Una política es una declaración de una intención o comportamiento de una compañía sobre un determinado tema.
Auditoría de sistemas
UNIDAD II: Auditoria al Gobierno y Gestión de TI MANUAL AUTOFORMATIVO 51
Como se puede apreciar, la política declara la intención de la compañía, en este caso declara la intención de respaldar.
La política no dice que se va a respaldar ni cómo se va a respaldar.
2.2.2 Normas.
Una Norma es el segundo peldaño en el Árbol Normativo. Una Norma es como una Ley, es decir tiene que
cumplirse obligatoriamente. El objetivo de una Norma es hacer cumplir una Política.
“Todos los días a las 10pm se realizará el respaldo de información de las Bases de Datos de los Sistemas Críticos
de la Compañía”.
Como se puede apreciar la Norma obliga a que se realice un backup a las 10 de la noche de las Bases de datos
de los sistemas Críticos. La Norma es vinculante y está orientada a cumplir la Política, en este caso la política de
respaldo de información.
2.2.3 Procedimientos
Un Procedimiento es un conjunto de pasos generales que se siguen para lograr un determinado resultado. El
objetivo de un procedimiento es hacer cumplir una Norma.
2.2.4 Instructivos
Un instructivo es el último peldaño en el Árbol Normativo. El instructivo es similar al procedimiento, pero a
diferencia del procedimiento, contiene el conjunto de pasos detallados para lograr un determinado resultado.
El procedimiento contiene los pasos generales, mientras que el instructivo contiene los pasos detallados. El
instructivo puede contener instrucciones o comandos de sistema y puede ir acompañado de pantallazos.
1. PROPÓSITO
Instalación de la solución para realizar copias de seguridad y recu-
1. PROPÓSITO
peración de archivos en los equipos de la compañía.
2. de
Instalación ALCANCE
la solución para realizar copias de seguridad y recuperación de archivos en los equipos de la compa-
ñía. Inicia con la ejecución de la consola de administración de RESPALDO
AUTOMÁTICO DE INFORMACIÓN y finaliza con el registro del moni-
toreo en el formato asociado correspondiente.
2. ALCANCE
Inicia 3.
con laDESCRIPCIÓN
ejecución de la consola DE ACTIVIDADES
de administración de RESPALDO AUTOMÁTICO DE INFORMACIÓN y fina-
liza con el registro del monitoreo en el formato asociado correspondiente.
3.1 Para encontrar los instaladores de RESPALDO AUTOMÁTICO
3. DESCRIPCIÓNDE DE INFORMACIÓN
ACTIVIDADES para equipos Windows realizamos la
3.1 Para encontrarcombinación deRESPALDO
los instaladores de teclas Windows
AUTOMÁTICO +R DEse mostrara la
INFORMACIÓN ventana
para equipos Windows
Buscar. En el cuadro escribimos la ruta \\SERVIDOR08 , por la ruta
realizamos la combinación de teclas Windows + R se mostrara la ventana Buscar. En el cuadro escribimos
\\SERVIDOR08ultimo aceptamos
, por ultimo como
aceptamos como indica
indica la secuencia
la secuencia de la Figura1. de la Imagen 1.
Imagen 2
Figura 3
Imagen 3
Imagen 4
Auditoría de sistemas
UNIDAD II: Auditoria al Gobierno y Gestión de TI MANUAL AUTOFORMATIVO 53
Imagen 3
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.
ElGerenciales
Practicas Gerente de TI enfocado
de RRHH en que se logren los objetivos de TI alineados con los objetivos del Negocio, debe preocu-
parse de contar con los mejores profesionales. Son las personas las que hacen que las cosas sucedan y son las personas
el factor
El Gerente de TIdeterminante
enfocado para
enelque
logrose
de los objetivos.
logren los objetivos de TI alineados con
os objetivos del Negocio, debe preocuparse de contar con los mejores pro-
ParaSon
esionales. ello ellas
gerente de TI debe
personas lasrecurrir a las mejores
que hacen que prácticas relacionadas
las cosas sucedan a la ygente.
son las
personas el factor determinante para el logro de los objetivos.
Para ello2.3.1
el gerente decontratación.
Prácticas de TI debe recurrir a las mejores prácticas relacionadas
a la gente.
El gerente de TI debe asegurarse de que el área de RRHH cuente con mecanismos de contratación eficientes
que filtrarán al mejor candidato posible.
b) Verificación de Logros Académicos. También hay que revisar si los grados, títulos y certificaciones de los
candidatos son veraces. Cuantas veces se han visto casos que incluso han salido a la luz pública, de gente que
dice tener una maestría o doctorado sin tenerlo.
c) Verificación de Antecedentes. A cada uno de los candidatos se les debe solicitar que presenten sus antece-
dentes penales, policiales y judiciales. Un profesional serio no debería tener este tipo de antecedentes.
d) Verificación domiciliaria. La verificación domiciliara es importante para conocer el ambiente donde viven
los candidatos y si este ambiente podría ser riesgoso. Por ejm. se suele contratar a una compañía para realizar
las verificaciones domiciliarias.
e) Verificación crediticia. La verificación crediticia es importante ya que un candidato con deudas podría ori-
ginar un riesgo para la compañía. Su in candidato no honra sus deudas o está atravesando problemas fi-
nancieros, podría ser tentado a cometer un acto ilícito. Por ejm. se debe consultar a las centrales de riesgo
crediticias como Experian o Infocorp.
f) Prueba del polígrafo. En algunos casos, algunos puestos críticos para el área de IT podrían requerir de una
prueba del polígrafo(detector de mentiras).
Una vez que tenemos el mejor profesional, un reto mayo es retenerlo en la Compañía. Los profesionales talen-
tosos siempre están buscando retos que valgan la pena.
54 UNIDAD II: Auditoria al Gobierno y Gestión de TI
a) Línea de carrera. El profesional debe conocer cuál es la línea de carrera en la compañía. El no contar con
una línea de carrera origina que los trabajadores se aburran y busquen nuevas oportunidades fuera de la
Compañía.
b) Recompensa. Los mejores profesionales siempre esperan estar bien recompensados. No solo se trata del
monto mensual sino de conocer los márgenes de Utilidades y bonos que la compañía le puede proporcionar.
c) Clima Laboral. Otro aspecto importante es el clima laboral. El profesional talentoso espera que la compañía
sea un lugar donde sea fácil trabajar, que su jefe le de libertad, que se reconozcan sus logros.
La segregación de funciones es una práctica importante para prevenir actos ilícitos o fraudulentos. Cuando
existe segregación de funciones un trabajador no puede controlar un proceso o transacción de manera com-
pleta. Cuando una persona controla un proceso completo, hay mucha probabilidad de que esa persona cometa
un acto ilegal tarde o temprano. Al controlar un proceso completo, la persona se podría ver tentada de hacer
“trampa”.
Veamos un ejemplo: Suponga que Ud. es programador de la Municipalidad del distrito donde vive. Ud tiene ac-
ceso a los programas fuentes del Sistema Informático. En esta municipalidad aplican la práctica de segregación
de funciones por lo que Ud. no tiene acceso a la Base de Datos. ¿Qué podría pasar si Ud. tuviese acceso a la Base
de Datos? ¿Qué le impediría que acceda a la tabla de Arbitrios y “pagar” los arbitrios de su casa?. Lo único que
lo detendría es su ética. Pero, ¿Qué pasaría si un vecino le dice que le da s/. 300 si le borra toda la deuda?
Para evitar estas (y muchas otras situaciones), el gerente de TI debe preocuparse que exista segregación de fun-
ciones en su área.
El Gerente de TI debe tener definidos los procedimientos de cese de su personal. La mejor práctica indica que
se deben cortar inmediatamente los accesos a todos los recursos informáticos una vez que una persona se retira
de la compañía. Esto aplica para todos los trabajadores de la compañía.
Es posible que un trabajador “se retire mal” de la compañía, es decir que se le detecte en un acto ilegal o tenga
un problema laboral que exija que se retire inmediatamente de la compañía y se le retiren también inmediata-
mente todos los accesos.
2.4 Tercerización
La tercerización es una de las mega-tendencias tecnológicas y los Gerentes de TI deben aprovechar muy bien esta
oportunidad.
La tercerización tiene que ver con pasar a una compañía especialista actividades que no están directamente relaciona-
das con la misión del negocio (algunos autores le llaman el core del negocio). En ese contexto, muchas actividades de
TI pueden ser tercerizadas. Se puede tercerizar el Soporte Técnico, el desarrollo de software, la gestión de la infraes-
tructura tecnológica, entre otros. Incluso en Perú hay algunos casos en donde se ha tercerizado la gran matoria de TI
e incluso hay un par de compañías que han tercerizado todo TI!
Entre las ventajas de tecerizar, se tiene que al tercerizar el Gerente de TI “reduce puntos de stress”, es decir, tiene
menos cosas de las que preocuparse, ya que ha contratado a una empresa especializada para que se ocupe de un deter-
minado tema. Asimismo, la tercerización permite concentrase en las cosas importantes (como por ejemplo apuntar al
logro de los objetivos de TI) y no “desenfocarse” en temas que no son importantes. También se dice a menudo que la
tercerización reduce costos, pero no siempre es así. A veces incluso puede salir más caro.
Uno de los aspectos más importantes que el Gerente de T.I. debe tener en cuenta al momento de tercerizar es que el
servicio que contratemos sea de mejor calidad que haciéndolo internamente. Es decir no tiene sentido, contratar a un
Auditoría de sistemas
UNIDAD II: Auditoria al Gobierno y Gestión de TI MANUAL AUTOFORMATIVO 55
proveedor especializado para que haga las cosas “peor” que nosotros. En ese sentido, para garantizar que el servicio
prestado sea de calidad, el Gerente de TI debe exigir a todos los terceros que firmen un Service Level Agreement
(SLA) o Acuerdo
no haya de Nivel de Servicio
cortes en el (ANS), por En
servicio. sus siglas en español.
un mundo ideal, el SLA debería ser de
100% lo que significa que los aparatos siempre estarán funcionando. Sin
Un SLA es emabrgo,
un documento estoennoel cual el proveedor
es así. se compromete
Si e proveedor a garantizar
nos ofrece un SLAun determinado
de 99.95% nivel
dede servicio. En
caso de quedisponibilidad
el proveedor noal cumpla con dicho nivel, le aplicaremos una penalidad.
año, esto significaría que nosotros toleraríamos cortes al
año que representan como máximo el 0.05%. El 0.05% de 365 días son 18
Por ejemplo, si contratamos un proveedor para que nos gestione la infraestructura tecnológica compuesta por servi-
días. Esto es inaceptable para una compañía.
dores, switches y routers, deberíamos exigir que estos aparatos siempre estén 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 debería ser de 100% lo que significa que los aparatos siempre estarán
toleraríamos un corte de 3.65 dias. Dependiendo del tipo de compañía, esto
funcionando. Sin emabrgo, esto no es así. Si e proveedor nos ofrece un SLA de 99.95% de disponibilidad al año, esto
significaríapodría ser inaceptable.
que nosotros toleraríamos cortes al año que representan como máximo el 0.05%. El 0.05% de 365 días son
Si el proveedor
18 días. Esto es inaceptable para nosunaofrece un SLA de 99.999%, esto significa que toleraría-
compañía.
mos un corte de 8 horas al año.
En cambio,Mientras
el proveedormejor es el un
nos ofrece SLA,
SLAmejor seráesto
de 99.99%, el servicio y evidentemente,
significa que el servi-
toleraríamos un corte de 3.65 dias. Depen-
cio se encarece ya que el proveedor
diendo del tipo de compañía, esto podría ser inaceptable. tendrá que invertir más en sistemas de
contingencia.
Si el proveedor nos ofrece un SLA de 99.999%, esto significa que toleraríamos un corte de 8 horas al año.
2.5 Capacidad y planeación del crecimiento
Mientras mejor es el SLA, mejor será el servicio y evidentemente, el servicio se encarece ya que el proveedor tendrá
que invertirOtro
más enimportante
sistemas deaspecto que un Gerente debe gestionar es velar que la tec-
contingencia.
nología siempre responda a las necesidades del Negocio. Por ejemplo nunca
debería suceder que nos quedemos sin espacio de disco duro, ni que los
2.5 Capacidad y planeación del crecimiento
usuarios se queden sin ancho de banda o que el CPU del Servidor de Archi-
vos esté
Otro importante al 90%
aspecto que un deGerente
utilización.
debe gestionar es velar que la tecnología siempre responda a las necesidades
Para evitar esto, hay
del Negocio. Por ejemplo nunca debería que suceder
estar continuamente
que nos quedemos monitoreando la capacidad
sin espacio de disco de los usuarios se
duro, ni que
queden sinla tecnología
ancho de bandayo adelantarse
que el CPU delaServidor
posibles de circunstancias
Archivos esté al 90% y tomar decisiones de
de utilización.
renovar la tecnología o ampliar la capacidad.
Para evitar Ampliar
esto, hay laquecapacidad significa adquirir
estar continuamente más la
monitoreando GB de disco
capacidad desila nos estamos
tecnología que-
y adelantarse a posibles
dando
circunstancias sin decisiones
y tomar espacio. de También
renovar podría significar
la tecnología adquirir
o ampliar más memoria RAM si la
la capacidad.
memoria está quedando corta. Esto debe hacerse de manera planificada
Ampliar la capacidad significa adquirir más GB de disco si nos estamos quedando sin espacio. También podría signifi-
car adquirirVeamos
más memoria RAM si laTenemos
un ejemplo. memoria está una quedando
compañía corta.
que Esto debe hacerse un
experimenta de manera planificada
importante
incremento en ventas en el mes de mayo. SI el Gerente de T.I. realiza un
Veamos unproceso
ejemplo. de
Tenemos una compañía
monitoreo que experimenta
de la capacidad, un importante
el grafico incremento
de utilización en ventas en el mes de
de memoria
mayo. SI el Gerente de T.I. realiza un proceso de monitoreo de la capacidad, el grafico de utilización de memoria se
se vería de la siguiente manera:
vería de la siguiente manera:
Como
Como se puede se puede
observar en elobservar
ejemplo, elen
usoelde
ejemplo, el va
la memoria uso de la memoria
aumentando va aumentan-
desde mayo hasta julio y que de seguir
do desde mayo hasta julio y que de seguir así nos quedaremos sin memoria
así nos quedaremos sin memoria en el mes de setiembre.
en el mes de setiembre.
Por otro lado, la gestión de la capacidad también tiene que ver con no com-
56
prar más de lo necesario. Imagine
que compramos UNIDAD II: Auditoria al Gobierno y Gestión de TI
un nuevo servidor con
32GB de RAM. Se instala el software y el software consume 8 GB casi de
manera consistente. ¿Qué pasaría con los otros 24GB no utilizados? Pues
son Por
capital muerto,
otro lado, esla decir
la gestión de son
capacidad soles
también tiene(o
que dólares) que gastamos
ver con no comprar y no
más de lo necesario. utili-que
Imagine
zamos.
compramos un nuevo servidor con 32GB de RAM. Se instala el software y el software consume 8 GB casi de manera
consistente. ¿Qué pasaría con los otros 24GB no utilizados? Pues son capital muerto, es decir son soles (o dólares) que
gastamos y no utilizamos.
6 Satisfacción de usuarios.
2.6 Satisfacción de usuarios.
El Gerente de TI debe estar comprometido en lograr la satisfacción de los
El Gerente de TI debe estar comprometido en lograr la satisfacción de los usuarios con los servicios que TI entrega. La
usuarios con los servicios que TI entrega. La forma más efectiva de saber
forma más efectiva de saber cuál es la percepción de nuestros usuarios es… preguntándoles!
cuál es la percepción de nuestros usuarios es… preguntándoles!
ParaPara
ello,
ello, el Gerente
el Gerente de TIdedebeTI debe
realizar realizar
encuestas encuestas
de satisfacción depara
periódicas satisfacción
saber de primeraperiódicas
mano cual es el
grado de satisfacción de los usuarios con el servicio ofrecido por el área de TI.
para
A continuación, presentaremos
A continuación, presentaremos un ejemploun ejemplo de encuesta:
de encuesta:
Figura 2-Figura
Ejemplo de
10. Ejemplo de encuesta.
encuesta.
Fuente: Elaboración propia.
Fuente: Elaboración propia.
2.7 Benchmarking.
7 Benchmarking.
El benchmarking es una técnica de mejora continua. Consiste en comparar una materia o un proceso que se realiza
dentro de la compañía y hacer la comparación entre como lo hacemos nosotros y como lo hace una compañía recono-
El benchmarking es ouna
cida del país, de la región técnica de mejora continua. Consiste en comparar
mundial.
una Enmateria o un proceso que se realiza dentro de la compañía y hacer la
función a la comparación, se pueden muchas oportunidades de mejora para que un Gerente de TI mejore su gestión.
comparación entre como lo hacemos nosotros y como lo hace una compañía
reconocida delnopaís,
En el Perú esta de la muy
es una práctica región o mundial.
establecida debido a que las compañías no comparten información entre ellas.
Pero en otros países como en Estados Unidos, es normal que las compañías comparten su información. Dado que el
En función a la comparación, se pueden muchas oportunidades de mejora
modelo en Estados Unidos es que las compañías están basadas en accionistas, por la transparencia del Gobierno Cor-
paraporativo,
que un Gerente
comparten muchade Ti mejore
información la cual su gestión.
puede ser aprovechada para hacer benchmarking.
En el Perú esta no es una práctica muy establecida debido a que las compa-
ñías2.8
noGestión
comparten
de cambios información entre ellas. Pero en otros países como en Es-
tados Unidos, es normal que las compañías comparten su información. Dado
El área de TI maneja por su propia naturaleza muchos Sistemas. La infraestructura tecnológica, los sistemas informá-
que ticos
el modelo
son complejosensistemas
Estados Unidos
que están es que
funcionando en la las compañías
Compañía. están
En su definición másbasadas en ac-
simple, un Sistema es un
cionistas, por
conjunto de lainterrelacionadas
partes transparencia del Gobierno
y que interactúan Corporativo,
con el propósito comparten
de lograr un objetivo, mucha
En este orden de ideas,
un cambio a alguna parte de un sistema podría afectar al Sistema en su conjunto.
información la cual puede ser aprovechada para hacer benchmarking.
Es muy frecuente escuchar a los usuarios decir que: “Los del área de TI o Sistemas cuando corrigen alguna cosa ma-
8 Gestión
logran de
otra cambios
cosa”. Estas situaciones se originan cuando se realizan cambios a los sistemas y estos cambios impactan en
alguna otra parte, lo cual impacta a los usuarios de dicho Sistema.
Para responder a este reto, los Gerentes de TI deben implementar un Comité de Control de Cambios, en el cual se
analicen los cambios a realizar, se revisen los riesgos, los impactos y se autoricen los cambios, y se tenga un plan de
retorno a la situación anterior, en caso de que las cosas salgan mal.
Esto significa que no se deben introducir cambios a los Sistemas sin un proceso formal. Lo que el gerente de TI debe
promover son procedimientos estrictos de control de cambios y que todo cambio planificado se plasme en el Request
for Change (RFC), que es el documento donde se deben registrar los cambios para su revisión por el Comité de Cam-
bio (Change Advisory Board CAB por sus siglas en ingles).
Urgencia
o Emer- O Media
gencia (Hasta 2 ventanas)
(Mismo
Día)
o Baja
(Mínimo 2 ventanas)
X Alta
(Inmediata)
Impacto
o Alto
Impacto
Alto Medio Bajo
Alta 1 2 3
Urgencia
Media 2 3 3
Baja 3 4 4 X Medio
o Bajo
Prioridad = Urgencia x Impacto
1: Emergencia
2: Alta
3: Significante
4: Baja ó Estándar
Consideraciones de Interrupción de Servicio:
58 UNIDAD II: Auditoria al Gobierno y Gestión de TI
N.A
Una de las principales preocupaciones de un Gerente de TI es optimizar los recursos. Es decir hacer más cosas con
menos presupuesto.
El Gerente de TI debe preocuparse de que exista un presupuesto, y que éste responda a las necesidades del Negocio.
Asimismo. El Gerente de TI debe preocuparse por que los gastos de tecnología se carguen no solamente a TI, sino que
se carguen contablemente a quienes utilizan la tecnología.
Veamos un ejemplo. Considere que un Gerente de TI de una compañía que tiene 500 usuarios necesita comprar un
nuevo switch para la red. En primer lugar, esta compra debería estar en el presupuesto. Si está en el presupuesto,
entonces nos deberían aprobar la compra del Switch sin mayores problemas. Ahora la pregunta es: ¿Qué área debe
asumir el gasto del Switch?. ¿El área de T.I.? Si le preguntamos a un usuario, nos responderá: Claro! Si es tecnología!
Lo debe pagar T.I. !!!
Ahora repensemos: ¿Quién o quienes utilizan el switch? ¿Es solo el área de TI? Por supuesto que no. El switch es utili-
zado por los usuarios de todas las áreas. Entonces, si lo utilizan todas las áreas, ¿Por qué solo lo debe pagar T.I.?
Si no hay una adecuada gestión financiera, el Switch lo pagará contablemente el centro de Costos del área de T.I. El
problema de esto es que si toda la tecnología que una compañía adquiere, se carga al Centro de Costos del área de T.I.,
terminaremos con que el área de T.I. es una de las áreas más gastadoras de toda la compañía.
Muchas de las compañías cuando compran tecnología cargan todo el gasto de la tecnología al área de T.I. Es labor
del gerente de T.I. educar a los ejecutivos de alto nivel de la compañía que si bien T.I. hace la adquisición, pero la
utilización es de todas las áreas de la compañía y por tanto se debe cargar contablemente a todas las áreas de manera
proporcional, el consumo del switch.
El gerente de T.I. debe contar un presupuesto interno y comunicar a las demás áreas del presupuesto que deben con-
siderar en sus presupuestos por la parte que les toca de los gastos de tecnología.
3.1 La Auditoria
Para auditar el Gobierno y la Gestión de TI, el Auditor debe conocer los conceptos de Gobierno y gestión de TI; así
como las prácticas gerenciales presentadas en este tema.
El Auditor debe recabar la documentación de Gobierno y Gestión, tal como planes, actas, presupuestos, contratos,
reunirse con el Gerente de T.I. y los profesionales que le reportan al Gerente de T.I.
Auditoría de sistemas
UNIDAD II: Auditoria al Gobierno y Gestión de TI MANUAL AUTOFORMATIVO 59
Con toda esta información y de acuerdo al Plan de Auditoria, el Auditor de Sistemas se enfocará en encontrar situa-
ciones que puedan originar riesgos.
a) Planeamiento Estratégico
- El Plan Estratégico de Sistemas no está alineado con los objetivos del negocio
b) Comité de Sistemas
c) Normatividad
e) Gestión de la capacidad
f) Satisfacción de usuarios
g) Benchmarking
h) Gestión de cambios
- Si sucede un error, los usuarios son los que pagan las consecuencias.
i) Gestión Financiera
Diagrama
- Los presupuestos
Objetivos Inicio de las áreas no consideran los gastos de tecnología
Santana
Recordatorio
Ormeño, M. (2011). De gerente de TI a CIO, una evolución necesaria en el Perú. Disponible en http://bit.
Anotaciones
ly/2bdRZE5
Auditoría de sistemas
UNIDAD II: Auditoria al Gobierno y Gestión de TI MANUAL AUTOFORMATIVO 61
INTRODUCCIÓN
Este tema está enfocado en como efectuar una Auditoria de Sistemas a la Continuidad de Negocio y Recuperación de
Desastres.
A medida que las compañías utilizan más y más la tecnología, se vuelven más dependientes de ella. Casi todos los proce-
sos de una compañía están soportados por tecnología. Aquí cabe preguntarse: Si las compañías son más dependientes
de la tecnología ¿Qué pasaría con la compañía si la tecnología falla de manera prolongada? ¿Qué le puede pasar a una
compañía si sus sistemas informáticos son interrumpidos por la ocurrencia de un desastre?
Eso fue precisamente lo que sucedió el día 11 de setiembre del 2001 a muchas compañías. Ese día 2 aviones chocaron
contra las dos torres gemelas en la ciudad de Nueva York en Estados Unidos, destruyendo ambos edificios.
Ud. se ha preguntado qué pasó con las compañías que funcionaban en ambas torres. ¿Ese día fue el último día de las
compañías? O podría ser que, ¿algunas compañías lograron sobrevivir a semejante desastre?
La respuesta a esta interrogante es la Continuidad de Negocio y Recuperación de Desastres. La diferencia entre que
una compañía cierre sus puertas o que logre superar un desastre es si ha implementado procesos de Continuidad de
Negocio y Recuperación de Desastres.
La Gestión de la Continuidad de Negocio es un proceso que le permite a una Compañía estar preparada ante la ocu-
rrencia de un desastre, identificando potenciales impactos de amenazas a la compañía y proveyendo una estructura
flexible y una capacidad de efectiva respuesta para continuar con las operaciones de la compañía.
Para implementar este proceso, a nivel mundial existen marcos de referencia para la gestión de la Continuidad de
Negocio.
La principal norma es la norma ISO 22301:2012 Seguridad de la sociedad – Sistemas de gestión de la continuidad del
negocio y se ha posicionado como el marco de referencia para gestionar la continuidad del negocio en una organi-
zación, para disminuir la posibilidad de ocurrencia de un incidente que impacte prolongadamente a una compañía
y, en caso de producirse, que la compañía esté preparada para responder en forma adecuada y, de esa forma, reducir
drásticamente el daño potencial de ese incidente.
También existen otras normas realacionadas a la Continuidad de negocio tales como la NFPA 1600:2007 Standard on
Disaster / Emergency Management & Business Continuit y la ISO/PAS 22399:2007 Incident Preparedness & Organi-
zational Continuity.
quede inoperativa por un periodo de tiempo que impacte adversa-
mente sus operaciones. Estas interrupciones obligan a la compañía a
tomar acciones para recuperar el estado operativo en el que estaba
62 antes del desastre. UNIDAD II: Auditoria al Gobierno y Gestión de TI
22
Un desastre puede interrumpir las operaciones de una Compañía, lo que nos obliga a tomar acciones para estar pre-
parados.
Para hacer frente a los desastres, las compañías deben estar preparadas. El objetivo de la continuidad del negocio /
recuperación de desastres es habilitar a un negocio para que continúe brindando sus servicios críticos en caso de de-
sastre y que pueda sobrevivir a una interrupción por un desastre en sus operaciones y en sus sistemas de información.
Repasemos el párrafo anterior. El objetivo no es evitar el desastre. No es posible evitar un desastre. ¿Cómo podríamos
evitar que suceda un terremoto? ¿Cómo podríamos evitar la ocurrencia del fenómeno del niño?
Lo que si puede hacer una compañía es estar preparada para recuperarse del desastre, es decir volver al estado en el
que estaba antes de la ocurrencia del desastre. Esto es similar a un resorte. ¿Qué sucede si Ud. alarga un resorte? El
resorte es flexible y se alarga. Ahora, ¿Qué pasa si suelta el reporte? El resorte vuelve a su estado anterior. Esto sucede
por la propiedad de la resilencia del reporte.
¿Se imagina si las compañías fueran resilentes? Es decir si sucede un desastre, la compañía rápidamente (cual resorte)
podrían volver a su estado normal.
Un Plan de Continuidad Negocios o Business Continuity Plan (BCP) es un plan que formula una compañía para estar
preparada ante un desastre.
a) Plan de Continuidad de Operaciones. Este plan es ejecutado por las áreas usuarias para continuar con la operación
de los procesos críticos. Es decir, los procesos que no deben para en una compañía. Aquí las áreas para ejecutar
sus procesos podrían usar sistemas stand-alone, hojas de cálculo o incluso procedimientos manuales a papel y lápiz
para continuar con las operaciones críticas.
b) Plan de Recuperación de Desastres. También conocido como Disaster Recovery Plan (DRP). Este plan es ejecutado
por el área de T.I. y tiene como objetivo recuperar los recursos informáticos que soportan los procesos críticos de
una compañía.
Ambos planes se deben ejecutar en paralelo. Es decir, mientras las áreas usuarias trabajan en la continuidad de sus
operaciones críticas (sin los sistemas informáticos), el personal de T.I. se enfoca en volver a la operatividad los recursos
informáticos ejecutando el DRP.
Esta fase también conocida como Business Impact Analysis (BIA) está enfocada en identificar los procesos críticos
de negocio, Es decir, hay que seleccionar de todos los procesos de la compañía a los procesos que no deben parar
ya que afectarían severamente a la compañía. Estos procesos son los llamados procesos críticos.
En esta fase también se identifican las métricas de tiempo de recuperación 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 pérdida aceptable de datos en el caso de una interrupción de las operaciones. Ello indica el
punto más anticipado en el tiempo al cual es aceptable recuperar los datos (ej. 4 horas). Esta métrica sirve
64 UNIDAD II: Auditoria al Gobierno y Gestión de TI
para definir la frecuencia de los respaldos (backups). Mientras más pequeño el RPO más esfuerzo y dinero
se invertirá en los respaldos.
–– El RTO es el tiempo improductivo aceptable en el caso de una interrupción de las operaciones. Ello indica
el punto más lejano en el tiempo en el que las operaciones de negocio deben retomarse después del desas-
tre. Por ejemplo si una compañía puede tolerar 3 horas entonces su RTO es de 4 horas. El RTO puede ser
calculado para cada proceso crítico del negocio identificado en el BIA. Mientras más pequeño el RTO más
esfuerzo y dinero se invertirá en la estrategia de recuperación.
–– El MTD es el Tiempo durante el cual un proceso puede estar inoperante hasta que la empresa empiece a
tener pérdidas y colapse.
–– El WRT es el Tiempo entre la recuperación del sistema y la normalización del procesamiento. Es el tiempo
invertido en buscar datos perdidos y realizar reparaciones.
UnaFigura
vez que se3 – definido
han Relación entre
los procesos los detiempos
críticos negocio y lasde la recuperación
métricas de recuperación, el de desas-
siguiente paso es
tres.
seleccionar una de las estrategias de recuperación. En T.I es imposible hablar de recuperación, si es que no se tiene
un Centro de Datos de Respaldo.
Fuente: Elaboración propia
Existen 5 estrategias de recuperación:
b) Estrategias de recuperación.
–– Alta Disponibilidad. También conocida como High Avalilability (HA). Esta estrategia es utilizada cuando el
RTO es muy pequeño. 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 automáticamente se graba una copia
Unaen vez que
el Centro se han
de Datos definido los procesos críticos de negocio y las
de Respaldo.
métricas de recuperación,
–– Hot Site. Consiste el Datos
en tener un Centro de siguiente paso
alterno similar es seleccionar
al Centro de Datos principaluna dela repli-
pero sin las
estrategias de recuperación.
cación de los datos en tiempo real. En T.I es imposible hablar de recupera-
ción,
–– WarmsiSite.
es Esque no se
un Centro tiene
de Datos conun Centroparcial
equipamiento de Datos deal Respaldo.
o inferiores Centro de Datos principal. Por
Existen
ejemplo5 estrategias
si una compañía hacede recuperación:
renovación tecnológica de servidores, los servidores antiguoes pueden ser
enviados al Centro de Datos Warm Site.
–– Cold Site. Más que un Centro de datos es una ubicación con la infraestructura básica (electricidad, cableado
de datos) para soportar la recuperación, la cual se puede realizar trayendo los equipos necesarios para rea-
lizar la recuperación.
–– Acuerdo reciproco. Esta es una estrategia a utilizar cuando la compañía no cuenta con recursos para imple-
mentar un centro de Respaldo. El Acuerdo indica que la compañía A puede utilizar al Centro de Datos de
la compañía B en caso de un desastre y viceversa. Este acuerdo se puede firmar con una compañía “amiga” y
que tenga una infraestructura informática similar a la nuestra. Ejemplo de ello podría ser compañías de un
mismo grupo empresarial o en compañías del Estado.
–– Sitios Móviles: Esta es una estrategia en la cual se tiene un Centro de Datos móvil, el cual puede ser transpor-
tado a un lugar determinado que necesite un Centro de Respaldo. Por ejemplo podría ser útil en una mina
o en caso de eventos deportivos. La siguiente figura ilustra un Sitio Móvil.
La selección de una estrategia depende del RTO, pero también del costo del Centro de Datos de recuperación.
Una vez definida la estrategia de recuperación ya se puede pasar a formular el Plan de Recuperación de Desastres.
Aquí se deben considerar los siguientes puntos:
–– Procedimientos de evacuación
–– La identificación de los diversos recursos requeridos para la recuperación y operación continua de la orga-
nización
–– Los Números de teléfonos y direcciones del personal crítico, de los proveedores, de los agentes de las com-
pañías de seguros.
Asimismo, en el plan se definen los equipos que están involucrados en los procesos de Continuidad y recuperación
de Desastres. A continuación se muestran los posibles equipos que se forman para
–– Equipo de software
–– Equipo de aplicaciones
–– Equipo de seguridad
–– Equipo de comunicaciones
–– Equipo de Transportes
–– Equipo de suministros
–– Equipo de salvamentos
–– Equipo de reubicación
–– Equipo de coordinación
–– Equipo de entrenamiento
Como se puede apreciar en el plan se formulan los puntos necesarios para la continuidad y la recuperación.
d) Pruebas y Actualización
Una vez culminado el plan, este debe ser probado para saber si realmente funciona y saber si nos va a servir cuando
suceda un desastre.
En ese contexto, el plan debe ser probado. La dificultad reside en como probamos la ocurrencia de un desastre.
En T.I. normalmente se realiza la prueba, cortando el suministro eléctrico al centro de Datos.
Los resultados de las pruebas deben ser documentadas, y las mejoras detectadas deben ser incorporadas al plan. Es
una buena práctica que al menos 2 veces al año se realicen las pruebas al plan.
Finalmente se debe actualizar el Plan. El Gerente de T.I debe exigir que el Plan este permanentemente actualizado.
–– Cambios en la organización
–– Cambios en la estrategia del negocio pueden alterar la importancia de las aplicaciones críticas o considerar
como criticas aplicaciones adicionales.
Auditoría de sistemas
UNIDAD II: Auditoria al Gobierno y Gestión de TI MANUAL AUTOFORMATIVO 67
No sirve de nada embarcarnos en la formulación del Plan para que cuando suceda el desastre nos demos con la
sorpresa que esta desactualizado y no nos ayuda en la recuperación
3.1 La Auditoria
ISACA recomienda que para auditar la Continuidad de Negocio y Recuperación de Desastres, se debe verificar:
• Evaluar los planes y si estos están escritos de manera sencilla y si son fáciles de entender
a) Continuidad de Negocio.
b) Análisis de Impacto
–– No determinación de los recursos informáticos críticos que soportan los procesos críticos
c) Estrategia de recuperación
–– Plan incompleto
–– e) Pruebas y Actualización
Diagrama –– Objetivos
Plan desactualizado
Inicio
Mearian, L. (2011). Lecciones aprendidas para la recuperación de desastres tras el 9/11 [Sitio Web]. Disponible en:
http://www.pcworld.com.mx/Articulos/18319.html,
Recordatorio Anotaciones
ACTIVIDAD N.° 2
Desarrollo Actividades Autoevaluación
de contenidos
Recordatorio Anotaciones
Auditoría de sistemas
Diagrama
Objetivos
UNIDAD
Inicio
II: Auditoria al Gobierno y Gestión de TI MANUAL AUTOFORMATIVO 69
GLOSARIO DE LA UNIDAD II
Lecturas Glosario Bibliografía
seleccionadas
BCP. Acrónimo de Business Continuity Plan. Proceso de la Compañia que se formula para estar preparado ante la
ocurrencia de un desastre que pueda afectar prolongada y adversamente los objetivos de una compañia.
Recordatorio Anotaciones
BIA. Acrónimo de Business Impact Analysis. Es una fase del proceso de Continuidad de Negocio en donde se identifi-
can los procesos críticos de negocio y se definen las métricas de recuperación.
Centro de Datos. También conocido como Data Center. Anteriormente conocido como Centro de Cómputo. Es la
ubicación física donde residen la Infraestructura tecnológica como Servidores, dispositivos de red, equipos de comu-
nicación que soportan los procesos de una compañía.
Comité de Sistemas. Comité conformado por los Gerentes de Alto Nivel de una Compañía que se encargan de dar
seguimiento al alineamiento de TI con los objetivos de la Compañía.
DRP. Acronimo de Disaster Recovery Plan. Es el Plan seguido por el área de TI después de un desastre, para recuperar
los recursos informáticos críticos.
PEE. Acronimo de Plan Estratégico Empresarial. Es el Plan en donde una compañía define su visión, misión, objetivos
y estrategias de negocio.
PETI. Acronimo de Plan Estratégico de Tecnologías de Información. Es el plan que el área de TI sigue donde define
su visión, misión, objetivos y estrategias, para apoyar en el cumplimiento del PEE.
Proceso crítico. Proceso de la compañía que no debe parar ya que de hacerlo afectaría adversamente los objetivos de
la Compañía.
RTO. Acronimo de Recovery Time Objective. Es el tiempo improductivo aceptable en el caso de una interrupción de
las operaciones.
RPO. Acronimo de Recovery Point Objective. El RPO es la pérdida aceptable de datos en el caso de una interrupción
de las operaciones
Objetivos Stand-Alone.
Inicio Equipo informático (PC o laptop) que no cuenta con acceso a la red, funcionando de manera individual.
Actividades Autoevaluación
os
BIBLIOGRAFÍA DE LA UNIDAD II
Glosario Bibliografía
s
Information systems audit and control association. (2016). CISA Re-view Manual. Chicago: ISACA.
o Anotaciones
70 UNIDAD II: Auditoria al Gobierno y Gestión de TI
Objetivos Inicio
AUTOEVALUACIÓN DE LA UNIDAD II
Actividades Autoevaluación
s
1. Ud. esta auditando la gestión de proyectos de un área de Sistemas e identifica que la lista de espera de proyectos
es mayor a 6 meses. Esto origina conflictos entre las distintas áreas para lograr que Sistemas priorice sus proyectos
s
Glosario ¿Cuál es el mecanismo más eficaz que Ud. recomendaría como auditor para atender y priorizar las distintas nece-
Bibliografía
A) Gestión de Proyectos
o Anotaciones
B) Plan Estratégico
C) Comité de Sistemas
D) Evaluación de desempeño
2. Ud. esta auditando los temas relacionados a la gestión del personal de un área de sistemas de una empresa pública
y encuentra que los gerentes de las áreas de desarrollo, mantenimiento y soporte técnico, son familiares directos
del Gerente de Sistemas. Ud. encuentra que el principal riesgo de esto es:
C) Fuga de Información
C) Reducir costos
4. Un programador trabaja en el área de soporte de aplicaciones. En esta área, el personal da soporte a las aplicacio-
nes e interactúa directamente con los usuarios de las diversas aplicaciones. Para dar soporte oportuno, se realiza
diariamente una copia de la BD de producción a la BD de soporte. ¿Cuál es el principal riesgo de esta situación?
B) Fuga de Información
5. Ud. encuentra que todos los gastos de tecnología son cargados al Centro de Costos del área de Sistemas. Esta situa-
ción coloca al área de sistemas como el área que más gasta de la empresa ¿Cuál de las siguientes recomendaría un
Auditor para una eficaz gestión financiera de IT?
6. Ud. está realizando una auditoria a la planeación del área de sistemas. En ese sentido, Ud. solicita al Gerente de
Sistemas una copia del Plan Estratégico de Tecnología de Información (PETI). La principal preocupación del au-
ditor al revisar este documento es que el PETI debe:
7. ¿Cuál de las siguientes afirmaciones es verdad en relación al Recovery Time Objective (RTO) y el Recovery Point
Objective (RPO)?
8. Ud. esta auditando el Plan de Continuidad de Negocios de Supermercados Kong y está revisando el Plan para
determinar si se realizó una adecuada selección de la estrategia de recuperación. ¿Cuál de los siguientes sería el
criterio principal para la determinación de una estrategia de recuperación?
9. Ud. está revisando la documentación del Plan de Continuidad de Negocio de la compañía minera AntraxMina.
¿Cuál de las siguientes no sería un documento a considerar en la revisión:
B) Políticas de Seguridad
72
10. En el contexto de la continuidad de negocio, ¿Cuál de los siguientes no es considerado un desastre?
A) Un terremoto
C) Infección de un spyware
D) Error del administrador como por ejm. el borrado de una BBDD crítica.
Auditoría de sistemas
UNIDAD III: Auditoría al Ciclo de Vida de desarrollo de Software MANUAL AUTOFORMATIVO 73
autoevaluación BIBLIOGRAFÍA
Lecturas Glosario Bibliografía
seleccionadas
5° Videoclase (Video conferencia) 1. Identifica los riesgos de cada una de las 1. Valora la importancia de la ejecución de
Tema N.° 1: Etapas del ciclo de vida de Desa- fases del ciclo de vida de desarrollo de la auditoria de sistemas.
rrollo de Software sistemas. 2. Se auto valora por su aprendizaje de las
1. Etapas del ciclo de vida 2. Identifica las metodologías y prácticas de técnicas de auditoria de sistemas.
pruebas relacionadas con el desarrollo de 3. Asume el compro-miso de revisar los
2. Controles de entrada, procesamiento y sistemas de información.
salida en el Software contenidos del manual.
3. Identifica los procedimientos de cambios 4. Valora la importancia de la auditoria de
en los sistemas sistemas para el mejora-miento de una
Tema N.° 2: Mantenimiento de Sistemas 4. Aplica los controles en el software. empresa y para las actividades o procesos
1. Procedimiento de control de cambios a realizar.
Actividad N.° 3 5. Participa activamente en el desarrollo de
Lectura seleccionada 1: las actividades de la asignatura.
Participan en el Foro de discusión sobre las
Título: Ciclo de Vida del Software. disponi- “riesgos en el desarrollo de software”.
ble en: http://static.ccm2.net/es.ccm.net/
contents/pdf/ciclo-de-vida-del-software-223-
k8u3gm.pdf
Control de Lectura Nº 2
Tema N.° 4: Auditoria al ciclo de vida Evaluación escrita de los temas N.° 1,2,3, y 4 ,
1. Auditoría a ciclo de vida de desarrollo más los contenidos de las lecturas selecciona-
2. Auditoría al mantenimiento de Sistemas das 1 y 2 de la Unidad III.
Lectura seleccionada 2:
Título: ¿Qué es big data?. Disponible en:
https://www.ibm.com/developerworks/ssa/
local/im/que-es-big-data/
Autoevaluación Nº 3
En este tema abordaremos el amplio mundo del desarrollo del softwar
compañías
74 gastan cientos de miles UNIDAD
de III:
dólares en delos
Auditoría al Ciclo procesos
Vida de de desarro
desarrollo de Software
software y es conocido que todo desarrollo de software conlleva riesgo
cuales deben ser revisados adecuadamente por los Auditores de Sist
También abordaremos
TEMA N.° eldemantenimiento
1: Etapas del Ciclo Vida de Sistemas y los procedimientos q
Auditores toman en cuenta para asegurar que los cambios al software ex
no introduzcan nuevos riesgos a las compañías.
INTRODUCCIÓN
Figura
Como se puede 1en–la Etapas
apreciar genéricas
figura 1, el Ciclo de Vida consideradel Ciclo
actividades de Vida
de adquisición de Desarrollo
de software. Ud. podría
Software.
preguntarse qué hace la adquisición en un ciclo de vida de desarrollo. Esto es lógico ya que mucho del software ya se
encuentra escrito y podría ser muy ventajoso adquirir software en lugar de construirlo.
El estudio de factibilidad es la primera etapa de un ciclo de vida de desarrollo de software. En esta etapa se realizan las
siguientes actividades:
• Definir los beneficios tangibles e intangibles del futuro sistema. Los beneficios tangibles siempre están relaciona-
dos a dinero e incluyen ahorro de costos, incremento de las ventas, reducción de personal (suena feo, pero es un
beneficio tangible), entre otros. Los beneficios intangibles incluyen mejora en los procesos, rapidez en la entrega
de productos o servicios, etc.
• Determinar el costo y tiempo aproximado para implementar el sistema. Se debe tener una idea de cuánto costaría
y cuánto tiempo podría tomar implementar la solución. Una buena práctica seria formular un Request for Infor-
mation (RFI) y enviarlo a proveedores. Este documento solicita a los proveedores que indiquen las capacidades
que tienen sus sistemas y nos permite tener una idea inicial de que existe en el mercado y cuánto tiempo y dinero
costaría.
• Escribir el Business Case (Caso de Negocio). El Business Case es un documento importante en el que se deben defi-
nir las alternativas existentes para implementar el sistema. Por ejemplo un Business Case podría tener 4 alternativas:
Dado que se tienen alternativas, se puede tomar una decisión de que alternativa seguir. Recuerde que tomar una deci-
sión es seleccionar una alternativa entre varias alternativas posibles.
1.3 Requerimientos
El análisis de requerimientos es la etapa más importante del ciclo de vida (Alguien dijo curso de Ingeniería de Re-
querimientos). Dado que el software a construir es intangible (no se puede tocar, no se puede sentir), no es lo mismo
construir software que construir un tangible como por ejemplo un edificio.
Muchos de los proyectos de desarrollo de software fracasan por que no se logra un entendimiento claro de los reque-
rimientos de los usuarios, por lo que es vital la participación de los usuarios.
1.4 Diseño
En caso de que se decida desarrollar, entonces la siguiente fase será la de diseño. La fase de diseño solo puede hacerse
después de que se tenga definidos claramente los requerimientos.
En esta fase es muy común utilizar algún lenguaje de modelado de software tal como el Unified Modeling Language
(UML) para diseñar, especificar, desarrollar y documentar un sistema.
La fase de diseño es equivalente a realizar un plano en la construcción de un edificio. El plano indica cómo será el
edificio. De manera similar en la fase de diseño se construyen los planos para realizar un software. El plano no puede
estar cambiando por lo que es imprescindible implementar un procedimiento de control de cambios para prevenir
que se creen nuevos requerimientos o se modifiquen los requerimientos sin control.
En caso de que se decida no desarrollar, entonces la siguiente fase después de la fase de Requerimientos es la fase de
Adquisición del software. Al igual que la fase de Diseño, la adquisición de software solo puede ocurrir después de cerrar
la fase de requerimientos, ya que no podemos adquirir un software sin saber lo que necesitamos.
En esta etapa básicamente se prepara el Request For Proposal ( RFP). El RFP es un documento que contiene todos los
requerimientos funcionales y no funcionales que necesitamos adquirir. Asimismo, el RFP contiene los requerimientos
técnicos, operacionales y de soporte por parte del proveedor.
El RFP es enviado a todos los proveedores para que puedan enviar sus propuestas. Una vez que se tienen las propuestas
se debe comparar las propuestas y seleccionar la propuesta más conveniente. Es común que las propuestas sean evalua-
das en función a su peso técnico y económico. Por ejemplo la evaluación técnica puede pesar 70-80% y la evaluación
económica puede pesar 20 % - 30 %.
Una vez declarado ganador, se debe firmar el contrato con el proveedor, el cual debe tener las penalidades adecuadas,
en caso de un incumplimiento por parte del proveedor.
1.6 Desarrollo
Esta fase es la continuación de la fase de Diseño. Con los documentos de especificaciones de diseño, se realiza la co-
dificación utilizando diversos métodos, técnicas y lenguajes de programación. Es muy común que los desarrolladores
utilicen ambientes integrados de desarrollo integrado (IDE) que facilitan la programación del código fuente.
En esta etapa se debe considerar las pruebas que garanticen la calidad del software construido. No se puede conceptua-
lizar desarrollo sin pruebas. Las pruebas son inherentes al desarrollo (por ese motivo no existe una fase de pruebas).
Una pregunta que se debe hacer en esta fase es: ¿Cuánto tiempo se le debe dedicar a las pruebas? ¿Cuál es la relación
optima de tiempo entre el desarrollo y las pruebas? Por ejemplo si tomo 1 mes para codificar, ¿Cuánto tiempo se debe
estimar para las pruebas? Muchas compañías le dedican el 20% a la codificación y el 80% del tiempo a las pruebas. Eso
significa que si se estima un mes para la codificación, se debería tener 4 meses de codificación. Ahora le pregunto ¿Ud.
considera que esta bien la relación 20%–80% ¿ Está un poco exagerada? ¿Será esta la práctica de los desarrollos de
software en el país? Lo cierto es cada equipo de desarrollo tiene sus propios estándares. Pero, no dedicarle suficiente
tiempo a las pruebas hace que muchos proyectos de desarrollo de software no logran la suficiente calidad, y eso genera
muchos riesgos en el ciclo de vida.
Auditoría de sistemas
UNIDAD III: Auditoría al Ciclo de Vida de desarrollo de Software MANUAL AUTOFORMATIVO 77
• Prueba
unitaria. Consiste en probar un único programa. Esta es la prueba que los desarrolladores normalmente
realizan cuando verifican sus programas.
• Prueba
de interface o de integración. Esta prueba verifica que la información 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 recuperación. Verifican que el software funcione adecuadamente después de una falla de hardware o
software.
• Pruebas de volumen. Determina el número máximo de transacciones que un software puede procesar.
• Pruebas de Stress. Determina el número máximo de usuarios / servicios que un software puede procesar.
• Pruebas de rendimiento. Compara el rendimiento de un software a otros sistemas equivalentes usando benchmarks
definidos.
• Pruebas de aceptación final – User Acceptance Test(UAT). Esta prueba se da en la fase de implementación, donde
el usuario aprueba la funcionalidad de un sistema.
• Alfa
y beta. Esta prueba es utilizada por los fabricantes de software. La prueba Alfa es una primera prueba interna
y el software podría no estar completamente terminado. La prueba Beta es una prueba con el software terminado
y enviada a un grupo de usuarios externos para que prueben el software en condiciones reales.
• Piloto. Esta es una prueba para probar una parte específica de un sistema.
• Función/validación.
Evalúa la funcionalidad de un sistema contra los requerimientos para verificar que se esté
construyendo e software de acuerdo a los requerimientos.
• Regresión.
Esta prueba está orientada a probar nuevamente funcionalidades cuando se introducen cambios o co-
rrecciones a un sistema. Esta prueba verifica que no hayan impactos no deseados en otras partes del software.
• Paralela.
Esta prueba consiste en probar dos sistemas, normalmente el viejo sistema y el nuevo sistema para com-
parar los resultados.
• Sociabilidad.
Esta prueba consiste en verificar que un cambio en un software no afecta a otros sistemas. Es decir
que el sistema “es amigo” de los demás sistemas y no genera conflictos con los otros sistemas.
Todas las pruebas deben ser planificadas y se debe realizar un Plan de pruebas. Las pruebas deben ejecutarse y docu-
mentar los resultados de las pruebas. Los errores y fallas deben ser incorporados en el desarrollo.
1.7 Configuración
La fase de Configuración es la fase que continua después de la adquisición del software (en caso que se decidió ad-
quirir un software). En esta etapa se adecua el software para que funcione según los requerimientos de la Compañía.
78 UNIDAD III: Auditoría al Ciclo de Vida de desarrollo de Software
Normalmente esto se basa en cambiar los parámetros del software evitando así tener que hacer cambios en el código
fuente del sistema a adquirir. Para ello el software a adquirir debería ser lo suficientemente flexible para permitir con-
figurar y personalizar el software.
En esta fase, cabe la pena preguntarse: ¿Hay que adecuar el software a la compañía o adecuar la compañía al softwa-
re? En líneas generales esta pregunta genera muchas y acaloradas discusiones. En mi opinión cuando se adquiere un
software, este software ya fue implementado decenas, cientos o incluso miles de veces en compañías anteriores, por
lo que el software trae muchas buenas prácticas. No siempre la forma como opera una compañía es la mejor y hacer
que el software se adecue a la compañía podría generar automatización de procesos no optimizados, por lo que de
preferencia la compañía debería adecuarse al software. De esa manera el software se utilizaría en su versión estándar y
fortalecería el soporte del fabricante del software.
Asimismo, es una práctica normal de las compañías construir interfaces entre el software adquirido con los software
existentes.
1.8 Implementación
En la fase de implementación se establece y la operación efectiva del nuevo sistema. Antes de la implementación, el
usuario ha aceptado la funcionalidad del sistema a través de la prueba de aceptación del usuario final (UAT).
Normalmente los proyectos de desarrollo de sistemas de información culminan en la fase de Implementación. Sin em-
bargo es vital que se considere la fase de Revisión de Post-Implementación. Esta revisión es una oportunidad no apro-
vechada por el área de T.I. para demostrar los beneficios que el Software brinda a la Alta Dirección de la Compañía.
Los beneficios se presentaron en la etapa de Estudio de factibilidad. Nosotros, lo de T.I. presentamos un business case
con la opciones para que nos aprueben el proyecto. Sin embargo, una vez que el proyecto es autorizado, comenzamos a
trabajar y al finalizar el software nunca nos preocupamos por dar a conocer los beneficios (tangibles e intangibles) que
se lograron. Una vez que culminamos un software nos dedicamos a construir el siguiente software y nunca nos damos
un tiempo para medir los resultados de nuestro sistema. Mientras más presentemos los resultados logrados, más fácil
será conseguir recursos para el siguiente proyecto. Sin embargo, si entregamos un software y no “vendemos” los logros
resultantes, perdemos una excelente oportunidad para demostrar los beneficios que el software logro.
• Obtener las lecciones aprendidas que serán aplicadas en los siguientes proyectos.
El Ciclo de vida de desarrollo de software tradicional no es el único. Algunos autores manifiestan que el ciclo de vida
de desarrollo del software tradicional no es apropiado para procesos de desarrollo de software con poco tiempo para
entregar el software. En ese sentido, existen procesos de desarrollo de software incremental e iterativo que se compo-
nen de tareas pequeñas etapas repetitivas. Ejemplo de procesos iterativos lo constituyen el desarrollo evolucionario,
el desarrollo en espiral y el desarrollo ágil. De estos 3, el proceso más popular es el desarrollo ágil con el framework
scrum como referente.
El software que desarrollamos debe ser a “prueba de balas”. Eso significa que adicional a que debe cumplir con los
requerimientos funcionales y no funcionales, debe garantizarse que el Sistema no permita el ingreso de datos incorrec-
tos, que los procesos sean exactos y proteger los reportes emitidos por el Sistema.
Auditoría de sistemas
UNIDAD III: Auditoría al Ciclo de Vida de desarrollo de Software MANUAL AUTOFORMATIVO 79
Para evitar que se ingresen datos incorrectos, incompletos o inconsistentes, los formularios de entrada de datos deben
tener controles de validación. ISACA recomienda que se consideren los siguientes controles para validar los datos:
Tabla 3
Lista de controles de validación de entrada de datos.
No. Parámetro Descripción
1. Verificación de limite Un dato no debe ser menor a, o mayor a un determinado valor. Ea decir debe estar
dentro de un límite. Por ejemplo el monto total de una factura de una compañía que
vende autos no puede ser menor que USD 7,000.
2. Verificación de rango Un dato debe estar dentro de un rango de valores predeterminados. Por ejemplo la
edad de una persona debe estar entre 18 y 100 años.
4. Verificación de razonabilidad El dato es comparado para determinar límites razonables o tasas de ocurrencia prede-
terminadas. Por ejm. La edad de una persona no puede ser mayor a 100 años.
5. Verificación de coincidencia Los datos ingresados deben coincidir con valores almacenados en una tabla. Por ejm.
códigos Postales
6. Dígito de control Un valor numérico calculado por un algoritmo y que permite asegurar la integridad
de un dato. Este control es efectivo para detectar la transposición de los caracteres
de un campo. Por ejm. La verificación del RUC debe ser realizada con el algoritmo
Modulo 11 modificado (El ejemplo aplica para Perú).
7. Verificación de obligatoriedad Un campo debe contener datos válidos, según el tipo de campo que se está ingresan-
do.
8. Verificación de datos duplicados Una transacción nueva es comparada con transacciones anteriores para asegurar que
no hay sido introducida previamente. Por ejm. Un pago de una factura a proveedores
se compara con pagos anteriores de la misma factura para asegurar que el pago no
este duplicado.
9. Relaciones con otros campos Un campo depende de un valor en otro campo. Por ejm: si se selecciona Cliente
Persona Natural, entonces se debe validar que el campo RUC empiece por 10. (El
ejemplo aplica para Perú).
Los controles de procesamiento están orientados a garantizar que los cálculos de los algoritmos internos del Sistema
sean correctos, asegurando la exactitud de los datos acumulados por los diversos procesos internos en un Sistema.
Ejemplo de un control de procesamiento lo constituye una verificación del cálculo de un algoritmo, usando otro me-
canismo de cálculo para verificar el resultado. Por ejemplo verificando que el resultado de un cálculo con una com-
probación a través de una sentencia SELECT.
suma = 0
While i < = 10
endwhile
Existen muchas formas de verificar los cálculos dentro de un Sistema de Información. Por ejemplo:
• Comprobar los totales cada vez que se inicia una nueva rutina.
• Verificaciones de límite o rango, similares a los controles que vimos en la entrada de datos.
Los controles de Salida están orientados a proveer que los datos entregados a los usuarios serán presentados, formatea-
dos y entregados en una forma consistente y segura.
• Generación automatizada de Instrumentos Negociables, Formularios y Firmas. Si el Sistema emite acciones, che-
ques, warrants,o cualquier otro instrumento negociable, se debe asegurar que dichos reportes no sean modificados.
Por ejemplo si se emite un cheque se debe emitir astericos antes y des pues de la cifra: ****1,315.00*****
Otro ejemplo seria no imprimir una Tarjeta de Crédito completa. Podría reemplazarse partes de la tarjeta de cré-
dito con asteriscos.
• Manejo de Errores en las Salidas. El Sistema debe tener controles para evitar que no se emita un y que ningún re-
porte se pierda. Por ejemplo controlar las numeraciones de la facturas.
También se deben seguir controles de salida físicos. Todos los controles en un Sistema Informático se pueden venir
abajo si es que al imprimirse un reporte con información sensible no se toman las medidas físicas necesarias para
proteger la información impresa. Entre las medidas físicas a considerar tenemos por ejemplo:
• Registro y Almacenamiento de Formularios Negociables, Sensitivos y Críticos en un Lugar Seguro. Este control
evitara la sustracción o robo de reportes que contengan valores.
• Distribución de Reportes. Los reportes críticos deben ser distribuidos de manera segura. Por ejemplo si es un estado
de cuenta, debe ensobrarse. Ahora existen maquinas que imprimen y ensobran automáticamente.
• Retención de Reportes. Los reportes con información sensible que pierdan su vigencia deben ser destruidos. La
destrucción debe considerar las leyes y regulaciones sobre retención de documentos que pudiesen existir.
• Verificación de Recibo de los Reportes. En caso de que se entreguen reportes a determinadas personas, siempre es
preferible hacerlas firmar un acuse de recibo de que han recibido el reporte.
En resumen, los controles deben existir durante el ingreso, el procesamiento y la salida de los sistemas de información.
Un error muy común que cometen los desarrolladores de software es considerar únicamente controles de entrada.
Ahora ya sabemos que se deben considerar todos los controles posibles dentro de un sistema de información.
Auditoría de sistemas
UNIDAD III: Auditoría al Ciclo de Vida de desarrollo de Software MANUAL AUTOFORMATIVO 81
INTRODUCCIÓN
Una vez que un Sistema de Información está funcionando (en producción), el Sistema sufre muchos cambios debido
a la demanda de los usuarios. En un mundo ideal, los usuarios solicitan cambios que mejoran las funcionalidades del
Sistema de Información. Sin embargo, también se pueden dar cambios para corregir funcionalidades defectuosas del
Sistema de Información. Desde el punto de vista de Auditoria, los cambios no deben introducir nuevos riesgos.
1 Mantenimiento de Sistemas
Las estadísticas indican que el Mantenimiento de Sistemas representa aproximadamente el 80% del ciclo de la vida
útil de un Sistema de Información. Esto significa que los costos y tiempo consumidos en el proceso de ciclo de vida de
desarrollo del Sistema de Información representa solamente el 20%.
Los fabricantes de software saben que el negocio está en el mantenimiento de software más que en el desarrollo de sof-
tware. Cuando un sistema de información está en funcionamiento, se requieren de nuevas funcionalidades, upgrades,
y mejoras que son parte del mantenimiento de sistemas.
Cuando se realiza un cambio a un Sistema de Información, éste podría afectar adversamente el funcionamiento de un
Sistema. Es por ello que cualquier cambio debe ser minuciosamente analizado a través de un proceso de control de
Cambios.
El Control de Cambios es uno de los procesos de ITIL (Information technology Infrastructure Library). Básicamente
este proceso trata de que un cambio pase por un proceso de autorización y revisión antes de su implementación para
verificar que el cambio no introduce riesgos ni impactos no deseados.
En una compañía donde no existe un proceso de control de cambios, cada persona de IT hace cambios directamente a
los sistemas. Esto no solo aplica para el equipo de desarrollo de software. Por ejemplo la gente de redes podría agregar
nuevos segmentos de red, o cambios en las redes o routers; la gente de Base de Datos podría modificar objetos dentro
de una Base de Datos, la gente de Servidores realizar cambios en la configuración de uno o más servidores. Como se
podrá intuir, un cambio en un componente podría afectar a otros componentes de la Infraestructura e impactar adver-
samente en el servicio ofrecido por IT.
Entonces, queda claro que se necesita un proceso de control de cambios en el cual todo cambio requiere de una serie
de actividades y controles hasta que el cambio finalmente pasa a producción.
A continuación presentaremos un conjunto de pasos a seguir (se asume que se trata de una empresa grande)
a) El usuario solicita un cambio a través de una solicitud de cambio (En inglés Request for Change RFC).
3 Implantación de cambios
Una vez que el cambio es aprobado por el usuario (o por la Gerencia del usuario), el cambio está listo para ser pasado
al ambiente de producción. El usuario obtiene por fin su cambio!
4 Documentación
Para asegurar el mantenimiento futuro del sistema, toda documentación relevante debe ser actualizada. Un error muy
común es que los cambios no son acompañados de la correspondiente documentación. Debido a que los cambios en
un sistema se necesitan “para ayer”, es común sacrificar la documentación. El mantener un sistema sin la documenta-
ción actualizada introduce riesgos de que los cambios se demoren un mayor tiempo, ya que el programador necesita
entender el código fuente.
5 Cambios de emergencia.
Imagine una situación donde un Sistema de Información falle y se necesite corregir este error inmediatamente. En
este caso, sería muy engorroso seguir el procedimiento de control de cambios del punto 1.1 y seguir todos los pasos,
obteniendo todas las autorizaciones y cumplir con todos los controles requeridos.
En una situación de emergencia, es posible que los programadores puedan tener acceso tanto a la Base de Datos como
al repositorio de los programas fuente del ambiente de producción de manera controlada. Muchas compañías por
ejemplo disponen de unos sobres cerrados y lacrados, los cuales solamente serán abiertos cuando se tenga un caso de
emergencia. Dentro de los sobres se tienen usuarios y contraseñas, las cuales podrán ser utilizadas por un programador
para corregir una situación en un programa o en una Base de Datos. Evidentemente estos usuarios y contraseñas tienen
una caducidad muy corta y son sujetos a pistas de auditoria, de tal manera que se pueda rastrear todos los cambios
realizados en esta situación de emergencia.
• El programador tiene acceso a las carpetas de producción que contiene los programas, incluyendo el código fuente
y el código objeto.
• El usuario responsable de la aplicación no estaba al tanto del cambio (el usuario no firmó la solicitud de cambio
(RFC)
• No existe un procedimiento formal.
• El Gerente que debía autorizar no firmó la solicitud de cambio aprobando el inicio de los trabajos.
• El usuario solicitante no firmó el formulario de aceptación de cambio (UAT).
• El código fuente modificado no fue revisado adecuadamente.
• El programador puso un código extra para beneficio personal (es decir, cometió fraude).
Auditoría de sistemas
Diagrama
UNIDAD
Objetivos
III:Inicio
Auditoría al Ciclo de Vida de desarrollo de Software MANUAL AUTOFORMATIVO 83
Kioskea.net (2014). Ciclo de Vida del Software. [Sitio Web]. Disponible en: http://static.ccm2.net/es.ccm.net/con-
tents/pdf/ciclo-de-vida-del-software-223-k8u3gm.pdf
Recordatorio Anotaciones
ACTIVIDAD N.° 3
Desarrollo Actividades Autoevaluación
de contenidos
INSTRUCCIONES
INTRODUCCIÓN
Este tema está enfocado en analizar algunas Aplicaciones de Negocio verticales comunes que comúnmente son revisa-
das por los Auditores de Sistemas; así como el Big Data que se convertirá sin ninguna duda en el modelo de sistemas
de información utilizados para la toma de decisiones en las organizaciones.
Se conoce como Aplicaciones de negocio verticales a aquellas Aplicaciones que no son de uso general y que más bien
son utilizadas por una industria especifica o para un solo propósito. A continuación revisaremos algunas de las aplica-
ciones de negocio verticales más utilizadas.
El E-Commerce se refiere a la venta y compra de productos o servicios a través de Internet, lo cual da a los vendedores
y clientes una inmensa oportunidad para vender a nivel global y para comprar a un precio asequible.
• Business-To-Consumer (B2C). En este modelo la compañía que vende se relaciona directamente con miles o inclu-
so millones clientes. El líder de este sector es www.amazon.com quien reinventa este sector con cientos de innova-
ciones.
• Business-To-Business (B2B). En este modelo las compañías pueden integrar procesos directamente. Ejemplo de
procesos que se pueden integrar son pedidos al proveedor, pagos al proveedor, reclamos, servicio post-venta, entre
otros.
• Business-To-Employee(B2E). La compañía pone a disposición de sus empleados realizar transacciones directas como
por ejemplo solicitar un préstamo, cambiar el AFP, solicitar una carta para una Embajada, imprimir boletas de pago y
certificados varios.
• Business-To-Government(B2G). Este modelo permite a las compañías realizar trámites y pagar directamente los
impuestos ante el Gobierno.
Como se puede apreciar, el comercio electrónico tiene muchas ventajas. Sin embargo también hay que considerar los
riesgos del comercio electrónico, entre los que tenemos:
• Confidencialidad. Para poder realizar transacciones electrónicas, los clientes deben suministrar información perso-
nal que podría incluir tarjetas de crédito que de perderse podrían afectar a los clientes y ser víctimas de fraude. De
hecho este riesgo ha sucedido varias veces. Basta buscar en Internet los ataques a la compañía Target. Puede ver un
pequeño video en: https://www.youtube.com/watch?v=lqu_Bx4Uf5w
• Integridad. Alguna vez le ha pasado o ha escuchado que se está procesando una transacción electrónica y no termi-
na y el sistema “se cuelga”, con lo que el usuario no sabe si la transacción terminó o debe volver a hacerla. Si vuelve
a realizarla, se podría comprar “doble”. Por otro lado, que sucede si los criminales informáticos modifican o borran
los datos. A esto se refiere el riesgo a la integridad de los datos.
• Disponibilidad. Uno de los grandes riesgos para una compañía de comercio electrónico es estar fuera de línea, es
decir no estar disponible. Esto aparte de hacer perder dinero a la compañía, podría espantar a los clientes y hacerles
perder la confianza en el sitio.
• Traslado del poder a los clientes. Este es el riesgo más importante de un sitio de comercio electrónico. Los clientes
Auditoría de sistemas
UNIDAD III: Auditoría al Ciclo de Vida de desarrollo de Software MANUAL AUTOFORMATIVO 85
están cada vez más informados y la competencia esta aun click de distancia y los clientes ahora son cada vez menos
leales a las marcas.
El intercambio Electrónico de Datos es un estándar en la cual los sistemas de información de diferentes empresas con-
versan directamente entre ellos, sin necesidad de intervención humana.
Imagine la siguiente situación: Trabajamos en un gran supermercado, el cual tiene cientos (o incluso miles) de pro-
veedores. La tarea de emitir órdenes de Compra para comprar a los proveedores los diversos productos a medida que
se van agotando de los stocks de las diversas tiendas requerirá de un ejército de gente en el área de Compras. Por cada
proveedor, tenemos que emitir una Orden de Compra y debemos registrar los artículos y las cantidades a comprar en
la Orden y luego emitir la orden. Una vez emitida la Orden habrá que enviarla por correo electrónico al proveedor.
El proveedor una vez recibida la Orden, ingresara los datos de la Orden de Compra en su Sistema de Ventas y en fun-
ción a ello, emitirá una factura y una guía de remisión para que despachen los productos que estamos adquiriendo.
En el proceso descrito existen dos compañías (el supermercado y el proveedor) en el cual ambos cuenta con sistemas
de información pero la transferencia de datos es a través de correo electrónico.
Entonces, ¿no sería mejor que los sistemas conversasen? Es aquí donde entra EDI. EDI es un estándar que permite a
sistemas comunicarse entre sí. Para que dos sistemas se comuniquen entre si se necesita que hablen un mismo proto-
colo de comunicación. Eso es precisamente EDI.
• Menos papeleo
Evidentemente, la naturaleza crítica de muchas transacciones (órdenes de Compra, facturas y pagos), requiere protec-
ción de las transmisiones. Por ello, los sistemas EDI cuentan con mecanismos de protección, tales como:
• Normas para indicar que el formato y el contenido del mensaje son válidos
• Controles para asegurar que la aplicación de traducción convierte correctamente las transmisiones estándar para
el software de aplicación
• Procedimientos para determinar que los mensajes son solamente de partes autorizadas
• Los datos deben estar encriptados usando algoritmos acordados por las partes involucradas
• El intercambio de totales de control de las transacciones enviados y recibidos entre los socios comerciales en inter-
valos predeterminados.
86 UNIDAD III: Auditoría al Ciclo de Vida de desarrollo de Software
Cuando hemos ido al supermercado y formado la fila para pagar nuestras compras. Algunas personas pagan con tarjeta
en lugar de efectivo. Esto se puede hacer a través de los Sistemas de Punto de Venta (POS) que permiten a diversas
compañías, aceptar pagos electrónicos por ventas en tiempo real. A través de los sistemas POS los clientes pueden pa-
gar sus compras a través del uso de tarjetas de crédito y de débito en 24x7. Los POS pueden estar conectados a lectores
magnéticos, lectores de chip, códigos de barra, entre otros.
Desde el punto de vista de riesgo, es importante identificar y analizar cómo estos sistemas guardan la información que
procesan, tales como el número de la tarjeta, y la información personal de los tarjetahabientes; así como las medidas
de seguridad en la transmisión de la información.
En el Perú empresas como Visanet y Procesos MC permiten el uso de tarjetas Visa, MasterCard, Dinners, Discover,
Union Pay, American Express e incluso tarjetas privadas de tiendas tales como Ripley, Saga Falabella, CrediScotia, Fi-
nanciera Uno, entre otros.
El objetivo de los sistemas de dinero electrónico es emular el dinero en efectivo. Un emisor hace esto mediante la
creación de certificados digitales, que luego son comprados por los usuarios que los depositan en una fecha posterior.
• Se ahorra tiempo y dinero ya que se puede realizar todas las operaciones de dinero electrónico en cualquier mo-
mento y en cualquier lugar.
Recientemente en el Perú se ha implementado el Sistema BIM, con el cual se puede realizar transacciones con dinero
electrónico en lugar de cargar efectivo para mandar y recibir plata, a través del uso de cualquier celular. Puedes obte-
ner más información en www.mibim.pe
Uno de las Aplicaciones que más van a impactar a las compañías en el futuro cercano es el Big Data.
Es sabido que una persona promedio el día de hoy genera más datos en un solo día, que una persona en el siglo XIV
en toda su vida.
Esta explosión de información, llevándolo al contexto de las empresas es más evidente que nunca. Las compañías gene-
ran terabytes (e incluso petabytes) de información cada año y no necesariamente se aprovecha toda esa información.
Si las compañías pudiesen aprovechar la cuantiosa información que poseen, estarían en posición de tomar mejores
decisiones de negocio.
Anteriormente, la toma de decisiones se hacían sobre los sistemas de Business Intelligence, pero que tenían el proble-
ma de que demoraban mucho en cargar la data proveniente de los sistemas transaccionales. Con el pasar del tiempo,
aparecieron los sistemas de computación en memoria (in-memory Computing) que permiten computar millones de
datos en la memoria del computador, eliminado la necesidad de cargar los datos desde otros sistemas de información.
Si Ud. desea ahondar en este fascinante tema, le invito a leer la lectura seleccionada de esta semana titulada: ¿Qué es
Big data? Si bien, es una lectura tomada de un sitio de un proveedor, en este caso IBM, la lectura ofrece una fuente
interesante y rápida forma de profundizar los conocimientos de Big Data.
Otra fuente de información que recomiendo, la puede encontrar en el sitio”The human face of big data”. http://
humanfaceofbigdata.com .
Auditoría de sistemas
UNIDAD III: Auditoría al Ciclo de Vida de desarrollo de Software MANUAL AUTOFORMATIVO 87
Este sitio (del mismo nombre del famoso libro de big data) contiene excelentes videos y ejemplos de la inmensa can-
tidad de datos al que nos enfrentamos.
Asimismo un ejemplo práctico del big data lo puede encontrar en: https://www.youtube.com/watch?v=d9NJt4DBb-I
88 UNIDAD III: Auditoría al Ciclo de Vida de desarrollo de Software
INTRODUCCIÓN
Este tema está enfocado en como efectuar una Auditoria de Sistemas al Ciclo de Vida de Desarrollo de Software y al
Mantenimiento de los Sistemas de Información.
• Identificar los componentes significativos o importantes en la aplicación y el flujo de las transacciones a través del
sistema.
• Identificar las fortalezas de control de la aplicación y evaluar el impacto de las debilidades de control para desarro-
llar una estrategia de prueba, mediante el análisis de la información acumulada.
• Documentos de la metodología de ciclo de vida. Esto dará un entendimiento al Auditor de la robustez de los pro-
cesos de construcción de desarrollo de software.
• Request for Change (RFC). Este documento permitirá conocer que cambios se realizaron y si estos contaron con
la autorización respectiva y debería poder cruzarse el documento de cambio con los cambios en el código fuente.
• Manuales de usuario. Con este documento se entiende como el usuario utiliza la aplicación. Es muy común que
este documento este desactualizado.
1.3 Situaciones que podría originar riesgos en el Ciclo de Vida de Desarrollo de Software.
b) Estudio de factibilidad.
c) Requerimientos.
d) Diseño
e) Adquisición de Software
• Falta de un RFP
• RFP incompleto
• Falta de contratos
f) Desarrollo
• Falta de pruebas.
• Pruebas incompletas.
g) Configuración
h) Implementación
i) Revisión Post-Implementación
• Request for Change (RFC). Este documento permitirá conocer que cambios se realizaron y si estos contaron con
la autorización respectiva y debería poder cruzarse el documento de cambio con los cambios en el código fuente.
• Manuales de usuario actualizados. Con este documento se verifica si los cambios se ven reflejados en la documen-
tación.
• Falta de priorización y seguimiento del sistema de cambio de los requerimientos del usuario
• Inexistencia de restricciones de acceso de seguridad sobre las carpetas de producción donde se encuentra los ob-
jetos fuente y ejecutables
Además, el auditor de SI debe revisar el proceso global de gestión del cambio de la compañía, para identificar posibles
mejoras en el tiempo de respuesta y la satisfacción de los usuarios con el proceso de cambio.
Desarrollo Actividades Autoevaluación
de contenidos
CONTROL DE LECTURA Nº 2
Diagrama ObjetivosInicio
Esta actividad
Lecturas
Glosario
seleccionadas puede
Bibliografía
consultarla en su Aula virtual.
Big data: Se refiere a la disciplina de recolección, almacenamiento, búsqueda, compartición, análisis, y visualización de
grandes cantidades de información.
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 más conveniente.
IDE: Acrónimo de Integrated Development Environment. En español, Entorno de Desarrollo Integrado, es un sof-
tware que facilita el desarrollo de software, contando con un editor de código fuente, herramientas de construcción
automáticas y un depurador. La mayoría de los IDE tienen auto-completado inteligente de código y algunos cuentan
con un compilador, un intérprete, o ambos.
ITIL: Acrónimo de Information technology Infrastructure Library. En español Biblioteca de Infraestructura de Tecno-
logía de Información. Es una práctica reconocida para la gestión de los servicios ofrecidos por las IT. Dentro de ITIL
se encuentra el proceso de Gestión de Cambios.
RFC: Acrónimo de Request for Change. En español Solicitud de Cambio, es un documento utilizado en el proceso de
Gestión de cambios, donde se documenta un cambio que es requerido.
RFI: Acrónimo de Request for Information. En español Solicitud de Información, es un documento que permite re-
coger información de las capacidades y características de un software de un proveedor. Normalmente se utiliza para
sondear el mercado.
RFP: Acrónimo de Request for Proposal. En español Solicitud de Propuesta, es un documento que solicita a los pro-
veedores que presenten sus propuestas para adquirir un determinado bien o servicio. Este documento normalmente
se solicita dentro de un proceso de licitación. También es conocido como “especificaciones técnicas”.
SDLC: Acrónimo de Software Develepment Life Cycle. En español, Ciclo de vida de desarrollo de software, es un pro-
ceso de la Ingeniería de Software para creación de desarrollo y/o adquisición de software.
UAT: Acrónimo de User Aceptation Test. En español, prueba de aceptación de usuario, es una prueba en la que el
usuario valida que el software cumple con los requerimientos solicitado, y autoriza a ponerlo en funcionamiento.
UML: Acrónimo de Unified Model Language. En español, Lenguaje Unificado de Modelado, es un lenguaje grafico
utilizado para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un
Objetivos “plano”
Inicio del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del siste-
ma, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y reciclaje de
componentes.
Actividades Autoevaluación
os
Information systems audit and control association. (2016). CISA Re-view Manual. Chicago: ISACA.
o Anotaciones
92 UNIDAD III: Auditoría al Ciclo de Vida de desarrollo de Software
Objetivos Inicio
1. Ud. esta auditando los resultados de un servicio de Hacking ético a las aplicaciones de una compañía y encuentra
que el hacker fue contratado para realizar pruebas de caja blanca. Esta prueba verifica:
s
Glosario
Bibliografía
A) Los controles de validación
B)
El código fuente
o Anotaciones
C) El proceso de ciclo de vida de la aplicación
2. ¿En cuál de las siguientes fases del ciclo de vida de desarrollo de software se lleva a cabo la prueba de Aceptación
de Usuario (UAT)?
A) Adquisición
B) Configuración
C) Implementación
D) Post-Implementación
3. Ud. esta auditando la validación del ingreso de datos de un nuevo sitio de redes sociales que tiene el potencial de
destronar a Facebook. Al revisar el sitio, Ud. encuentra que para el registro de nuevos usuarios, el sistema solicita el
correo sola una vez y no dos veces como lo hacen todas las redes sociales. ¿Cuál de las siguientes validaciones Ud.
recomendaría?
A)
Chequeo de razonabilidad
B) Prueba de sociabilidad
C)
Validación de llave
4. Ud. esta auditando el proceso de mantenimiento de software y encentra que en el presente año el principal sistema
de información ha tenido 18 cambios. ¿Cuál de las siguientes sería una evidencia que Ud. solicitaría como parte de
la revisión?
5. Ud. esta por auditar el Sistema de Compras de Supermercados Chong y encuentra que el sistema realiza un In-
tercambio Electrónico de Datos basado en el estándar EDI. El Sistema de Compras se conecta con los sistemas de
información de los proveedores. Al respecto, ¿cuál de los siguientes NO seria su principal preocupación?
6. Ud. es parte del equipo de Auditoria al sitio de comercio electrónico de la librería más importante del mundo:
Barnes and Noble.com. ¿Cuál de los siguientes NO seria parte de la auditoria?,
A) Revisión de los mecanismos de extracción de datos para las estadísticas del sitio
7. Ud. esta auditando el proceso de ciclo de vida de desarrollo de software de la compañía de lácteos Glorita, y el área
de Sistemas le informa que ha presentado al gerente Financiero, un caso de negocios (Business Case) relacionado
a la implementación de un nuevo Sistema de Recursos Empresariales (ERP) al gerente. El área de Sistemas presen-
to el caso de negocio al gerente Financiero para:
A) Cerrar el proyecto
B)
Validar los beneficios del proyecto post cierre
8. La prueba en que se determina que un software no altere o dañe los software que ya se encuentran corriendo es la:
B) Prueba de regresión
D) Prueba de sociabilidad
9. En cual fase del ciclo de vida de desarrollo de sistemas se toma la decisión de desarrollar o adquirir el software
A) Diseño
B) Adquisición
C) Ingeniería de requerimientos
D) Estudio de Factibilidad
E) Implementación
10. Ud. está revisando una RFP (Request For Purposal) ¿Cuál es la fase del ciclo de vida que está auditando?
A) Estudio de Factibilidad
B)
Pruebas
C) Adquisición
D) Configuración
94
Auditoría de sistemas
UNIDAD IV: Auditoría a la seguridad de la información MANUAL AUTOFORMATIVO 95
autoevaluación BIBLIOGRAFÍA
Lecturas Glosario Bibliografía
seleccionadas
7° Videoclase (Video conferencia) 1. Identifica los riesgos relacionados a la 1. Valora la importancia de la ejecución de
Tema N.° 1: Seguridad de la información seguridad de la información la auditoria de sistemas.
1. Seguridad de la información 2. Identifica los riesgos relacionados a la 2. Se auto valora por su aprendizaje de las
seguridad informática técnicas de auditoria de sistemas.
2. Seguridad informática
3. Participa en la redacción de observacio- 3. Asume el compro-miso de revisar los
nes relacionadas a la Gestión de Accesos y contenidos del manual.
Tema N.° 2: Controles de seguridad I Criptografía. 4. Valora la importancia de la auditoria de
1. Gestión de accesos sistemas para el mejora-miento de una
Actividad N.° 4 empresa y para las actividades o procesos
2. Criptografía
a realizar.
Lectura seleccionada 1 Elabora un ensayo sobre cuando utilizar los
diversos tipos de criptografía. 5. Participa activamente en el desarrollo de
Aplicación de la criptografía. Disponible en: las actividades de la asignatura.
https://www.icai.es/contenidos/publicacio-
nes/anales_get.php?id=1235
8° Videoclase
Tema N.° 3: Controles de Seguridad II 1. Identifica los riesgos relacionados al
1. Dispositivos de Seguridad Internet Internet
2. Seguridad Cloud 2. Identifica los riesgos relacionados al
Cloud
3. Seguridad Móviles
3. Identifica los riesgos relacionados a los
dispositivos móviles
Tema N.° 4: Auditoría a la Seguridad de la 4. Participa en la redacción de observa-
Información ciones relacionadas a la seguridad de
1. Auditoría a la seguridad de la informa- la información, poniendo énfasis en la
ción recomendación de controles.
2. Auditoría a los controles de seguridad.
Lectura seleccionada 2: Tarea Académica Nº 2
Seguridad en dispositivos móviles: ¿Qué Elabora un informe de auditoría de controles
pautas debes seguir?. Disponible en: http:// de seguridad del caso “Auditoria de una
hipertextual.com/archivo/2013/12/seguri- empresa regional”.
dad-dispositivos-moviles-consejos/
Autoevaluación de la unidad IV
96 UNIDAD IV: Auditoría a la seguridad de la información
INTRODUCCIÓN
En este tema revisaremos los conceptos fundamentales sobre la seguridad de la información.
1 Seguridad de la Información
En su definición más simple la Seguridad es la ausencia de riesgo. Esto quiere decir que la Seguridad es un estado. Hoy
puedo estar seguro y mañana no estarlo; o al revés, hoy no estarlo y mañana estar seguro.
La información de las compañías tiene valor y por ello requiere ser protegida. Esto tiene un significado relevante ya
que la información es intangible, es decir que está en la memoria de un computador, en una Base de Datos, en una
carpeta compartida, en la nube, en un dispositivo móvil. En cualquiera de estos requiere de protección del intangible.
a) Confidencialidad. La confidencialidad se refiere a que la información solamente sea accedida por las personas
autorizadas. Por ejemplo si un criminal informático logra acceder a información de muestra compañía, se vería
afectada la Confidencialidad.
b) Integridad. La integridad se refiere a que la información permanezca completa e inalterable, es decir que se
mantenga exacta tal como fue ingresada. Si por ejemplo un malware encripta la información, es decir la modifica,
entonces se afecta la integridad.
c) Disponibilidad. Se refiere a que la información esté disponible cuando la persona autorizada la requiere. Este atri-
buto de la seguridad es el más valorado por los usuarios. Imagine un dia lunes a primera hora y que los usuarios se
encuentren con que “no hay sistema” debido a un ataque informático.
Para que una iniciativa de Seguridad de la Información tenga éxito en una organización, se deben asegurar que los
siguientes factores se logren:
b) Políticas, Normas y Procedimientos. Este tema lo vimos en la Unidad II, cuando vimos el tema de las prácticas
gerenciales de IT. Se debe contar con un árbol normativo con todas las políticas, normas y procedimientos de se-
guridad de la información.
c) Organización. Las actividades de seguridad requieren de un área organizada para que se encargue de todos los
temas. Asimismo, se necesita que todos los usuarios tengan responsabilidades por la seguridad de la información
en la compañía donde laboran.
d) Educación. Los usuarios deben ser capacitados en los temas relevantes de Seguridad de la Información. Temas
como riesgos, amenazas, uso aceptable de información y consideraciones que deben ser tomadas, son los temas
que deben ser considerados en las capacitaciones de seguridad de la información. Se debe considerar capacitar a
los usuarios al menos una vez al año.
Auditoría de sistemas
UNIDAD IV: Auditoría a la seguridad de la información MANUAL AUTOFORMATIVO 97
e) Monitoreo. La ejecución de un monitoreo continuo y en tiempo real del cumplimiento de los controles y de la
normatividad de seguridad de la información es una actividad vital para la seguridad de la información.
f) Manejo de Incidentes. Tarde o temprano van a suceder incidentes de seguridad de la información. Esto es una rea-
lidad a pesar de todos los controles de seguridad de la información que el dinero pueda comprar y se implementen
en una compañía.
El responsable de Seguridad de la Información es el llamado a lograr a que estos Factores Críticos de Éxito se cumplan.
De estos factores dependen si va a tener éxito o no en su gestión.
Existe una máxima en Seguridad de la información: No se puede proteger lo que no se sabe que uno tiene.
Es por ello que uno de los puntos cruciales de seguridad de la información radica en contar con un inventario exhaus-
tivo de los activos de información. En este inventario no interesa si el activo es de propiedad de la compañía. Es decir
se deben considerar los activos de información que sean de propiedad de terceros y que contengan información de la
compañía. Si está conectado a la red, debe ser considerado en el inventario.
• Sistemas de Información
• Base de Datos
• Media
• Licencias
• Interfaces
• Servidores
• PCs / Laptops
• Disp. móviles
• Periféricos
• Equipos de comunicación
• Contratos
• Documentación
• Personal
98 UNIDAD IV: Auditoría a la seguridad de la información
2 Seguridad Informática
De primera impresión, la Seguridad de la Información podría confundirse con la Seguridad Informática. De hecho
muchos profesionales, usan el término indistintamente.
Sin embargo, es preciso acotar que la Seguridad Informática es un subconjunto de la disciplina de la Seguridad de la
Información.
Según Jeimy J. Cano, la Seguridad Informática, es la disciplina que “se encargaría de las implementaciones técnicas de
la protección de la información, el despliegue de las tecnologías antivirus, firewalls, detección de intrusos, detección
de anomalías, correlación de eventos, atención de incidentes, entre otros elementos, que—articulados con prácticas
de gobierno de tecnología de información—establecen la forma de actuar y asegurar las situaciones de fallas parciales
o totales, cuando la información es el activo que se encuentra en riesgo.”
Entonces se puede decir que la Seguridad Informática trabaja en una capa operativa con algunos temas tácticos para
proteger la información de una compañía.
Por su lado, el mismo autor refiere que la Seguridad de la Información “es la disciplina que nos habla de los riesgos,
de las amenazas, de los análisis de escenarios, de las buenas prácticas y esquemas normativos, que nos exigen niveles
de aseguramiento de procesos y tecnologías para elevar el nivel de confianza en la creación, uso, almacenamiento,
transmisión, recuperación y disposición final de la información.”
Esto significa que la Seguridad de la Información trasciende al área de TI, ya que la información podría estar en medios
tecnológicos como no tecnológicos. Es decir que la Seguridad de la Información se encarga de la protección de la in-
formación en todas sus manifestaciones. En ese sentido, la Seguridad de la Información es la capa estratégica orientada
a proteger la información.
INTRODUCCIÓN
En este tema vamos a revisar 2 controles importantes de Seguridad de la Información: La Gestión de Accesos y la Crip-
tografía.
1 Gestión de Accesos
La Gestión de Accesos es un control preventivo que permite que no se acceda a la a la información por parte de usua-
rios no autorizados. La Gestión de Accesos está relacionada a la Confidencialidad de la Información.
1.1 Acceso.
Empecemos por lo primero: definiendo lo que es el Acceso. Acceso es el flujo de información entre un sujeto y un
objeto. Un sujeto puede ser una persona, una aplicación, una interface, etc. Por su lado, un objeto puede ser una Base
de datos, un programa, una impresora.
El acceso a la información dentro de una compañía no puede darse sin ningún tipo de control. El acceso a la informa-
ción se debe otorgar solamente a las personas estrictamente necesarias.
El criterio fundamental para otorgar accesos a los diversos activos es la Necesidad de Saber (Need-to-Know).
• -¿Un vigilante para realizar sus funciones necesitará acceso a los Estados Financieros de la Compañía?
• ¿La Sra. de limpieza para realizar sus funciones necesitara acceso a la planilla de la compañía?
• ¿El administrador de la Red para realizar sus funciones necesitará tener acceso a la Contabilidad de la compañía?
En los 3 casos presentados, ¿Qué debería suceder si alguno de estas personas solicita acceso? Evidentemente, el acceso
a la información debería ser rechazado. A eso se refiere la necesidad de Saber. Este criterio precisa que los accesos
a los activos de información deben ser otorgados a aquellas personas que para el desenvolvimiento de sus funciones
requieren de dicho acceso.
Ahora, vayamos un paso más allá. ¿Qué sucede con el Gerente General o dueño de la Compañía? ¿Necesitara tener
acceso a todo la información de la compañía? La respuesta es NO. El gerente General debería tener acceso solamente
a aquella información que necesite para realizar sus funciones de Gerente General.
La necesidad de Saber no es fácil de implementar en las organizaciones. En muchas compañías se otorga acceso a todo
aquel que lo pide o se otorga acceso a los compañeros o amigos de la oficina. Todas las compañías deberían compren-
der este criterio fundamental y aplicarlo.
a) Identificación
b) Autenticación
c) Autorización
a) Identificación
La identificación se da cuando el Sistema nos pide nuestra cuenta de usuario. Esta cuenta de usuario puede recibe
varios nombres: user id, login, logon id, etc.
Dadas las amenazas a las que está expuesta la información, es evidente que no basta con identificarnos ante un Sistema
para acceder a la información. Los Sistemas de Control de Acceso siempre requieren que se verifique la identidad del
usuario.
b) Autenticación.
La autenticación es el segundo paso y consiste en asegurar que el usuario demuestre que es quien dice ser.
La pregunta ¿Qué es lo que se? es la más popular y se responde a través de contraseñas. Es decir, los usuarios saben sus
contraseñas.
Por ejemplo, la contraseña: “%%3sat5050599??##”, es una contraseña difícil de adivinar, pero no es fácil de recordar,
por lo que no cumple los 2 criterios simultáneamente.
Existen 2 técnicas recomendadas para recordar contraseñas y que permiten cumplir ambos criterios.
La técnica del Acróstico: Por ejemplo considere la frase: “Más vale pájaro en mano que ciento volando”. Si aplicamos
la técnica del acróstico, es decir tomamos la primera letra de cada palabra de la frase nos daría la contraseña: “Mvpem-
q100v”.
La segunda técnica es la de usar una frase que sea familiar. Considere la siguiente frase corta: “si se puede”. Agregando
símbolos a la frase nos daría la contraseña: Si##se##puede
Esta técnica también es recomendada por el analista de la NSA, Edward Snowden. El indica que se use una contrase-
ña en base a una frase. Textualmente Snowden da un ejemplo de contraseña: “margaretthatcheris110%SEXY”. Esta
contraseña se deriva de la frase: Margaret Thatcher es 110% sexy. Puede encontrar más información de las recomen-
daciones de Edward Snowden en:
http://www.20minutos.es/noticia/2429957/0/edward-snowden/seis-consejos/contrasenas-seguras-internet/#x-
tor=AD-15&xts=467263
b.2 Autenticación teniendo algo. Auditoría de sistemas
UNIDAD IV: Auditoría a la seguridad de la información MANUAL AUTOFORMATIVO 101
Otra forma de autenticación (menos popular) es la d
autenticación teniendo algo. Por ejemplo: un token, una tarjeta d
coordenadas o un chip. En la siguiente figura se tiene un ejempl
b.2 Autenticación teniendo algo.
de tarjeta
Otra forma de autenticación de
(menos coordenadas:
popular) es la de autenticación teniendo algo. Por ejemplo: un token, una tarje-
ta de coordenadas o un chip. En la siguiente figura se tiene un ejemplo de tarjeta de coordenadas:
c) Autorización
b.3 Autenticación siendo algo.
La última fase del control de Acceso es la Autorización y se refiere a que permisos (también llamados privilegios) tiene
un usuario cuando ingresa al Sistema.
Esta pregunta se responde con la biometría. El Sistema pid
En función a la Autorización un determinado usuario puede insertar, modificar o incluso eliminar registros en una
ingresar un dato biométrico para autenticar a la persona.
determinada transacción. Est
puede ser logrado con la huella dactilar, el análisis del iris, de
retina,
c.1 Sistema de Control la geometría de la mano. Las venas del dorso, etc.
de Accesos
• Crear responsabilidades y auditabilidad individual a través de registro de los eventos en una bitácora
• Reportes de Accesos
102 UNIDAD IV: Auditoría a la seguridad de la información
2 Criptografía
2.3 Definición
La criptografía permite convertir un texto plano (técnicamente se llama plain text) que requiere ser transmitido, a
un texto ilegible (técnicamente se le llama cypher text) que no puede ser entendido si es que alguien captura el texto
durante la transmisión.
• El
algoritmo criptográfico. Siempre se debe utilizar un algoritmo público ya que este algoritmo es considerado
robusto.
• La
llave. La llave se refiere a una cadena de bits que se introduce al algoritmo. La llave constituye el elemento se-
creto. Es por ello que se dice que la fortaleza de la criptografía reside en la seguridad de la llave.
• La
longitud de la llave. Mientras más larga la longitud de la cadena de bits, más segura estará la llave. Dado que la
llave es una cadena de bits, es sujeta a un ataque de fuerza bruta en donde el atacante intentará romper la cripto-
grafía intentando todas las combinaciones posibles de llave.
a) Criptografía simétrica.
b) Criptografía asimétrica.
c) Funciones hash.
Es una criptografía de una sola dirección. Es decir, se puede encriptar, pero no se puede desencriptar.
La criptografía asimétrica es una criptografía que permite encriptar y desencriptar utilizando una misma llave. Esto
significa que la misma llave que se utiliza para encriptar, es usada para desencriptar.
El algoritmo de criptografía simétrica más popular es el algoritmo AES (Advanced Encription System). Este algoritmo
permite longitudes de llave de 128, 192 o 256 bits. (EL día de hoy se considera que longitudes de llave de 128 bits son
seguras). El algoritmo AES está basado en el algorimo Rijndael (Se pronuncia Ring Doll) que ganó un concurso de
criptografía convocado por la NIST en el año 2001.
https://es.wikipedia.org/wiki/Advanced_Encryption_Standard
https://www.youtube.com/watch?v=46Pwz2V-t8Q
El problema de la criptografía simétrica es la distribución de la llave. Dado que, con la misma llave que se encripta se
desencripta, entonces se necesita un mecanismo seguro para enviar la llave al destinatario.
Auditoría de sistemas
UNIDAD IV: Auditoría a la seguridad de la información MANUAL AUTOFORMATIVO 103
Por ejemplo si encriptamos un documento, enviamos el documento encriptado al destinatario, pero, ¿cómo haríamos
para hacerle llegar la llave? Para resolver este problema, en los años 70 se inventó la criptografía asimétrica.
La criptografía asimétrica requiere de dos llaves para cada usuario o Sistema. Una llave es usada para encriptar y la
otra llave es usada para desencriptar. Una de las llaves es la llave privada (que debe conservarse secreta) y la otra llave
es la llave publica (por lo tanto no requiere ser secreta, sino todo lo contrario, podría estar publicada en cualquier
directorio). Con esto se evita, que se tenga que distribuir la llave secreta.
El algoritmo de criptografía asimétrica más popular es el algoritmo RSA (El nombre del algoritmo está basado en las
iniciales de sus 3 creadores: Rivest, Shamiry Adleman). Este algoritmo permite longitudes de llave de 1024, 2048 y 3072
bits. El día de hoy no se utiliza llaves de 1024 bits.
https://www.youtube.com/watch?v=On1clzor4x4
Un tercer tipo de criptografía es la función hash. Se trata de una función de una sola vía, es decir en un solo sentido.
Se utiliza para encriptar pero no para desencriptar.
La función hash es una función muy sensible. Esto significa que un pequeño cambio en el texto plano originará un
resultado completamente diferente.
El resultado de una función Hash es llamado MD (Message Digest) o resumen del mensaje. Este resultado siempre es
de una longitud fija sin importar la longitud del mensaje original.
Esta criptografía es más utilizada para garantizar la integridad (más que la confidencialidad).
Para probar cómo funciona, ingrese a hashgenerator.de y ponga un texto, hagale anos cambios y observe como el
Message Digest cambia dramáticamente.
Las 3 criptografías se utilizan en diversas situaciones. A continuación presentaremos un cuadro resumen de las 3 crip-
tografías:
Tabla 4
Cuadro Comparativo Criptografías.
atributo criptografía simétrica criptografía asimétrica función hash
Nro. de llaves 1 2 1
2.6 Aplicaciones
• Firma
Digital. Este algoritmo emula la firma humana en transacciones digitales. Utiliza la criptografía asimétrica y
la función Hash.
• Transport Layer Security (TLS). Este protocolo encripta la comunicación entre un Browser y un Servidor Web. Este
protocolo reemplazo al protocolo Secure sockets layer (SSL).
• IP security (IPSec). Es un protocolo asegurar el flujo de paquetes, garantizar la autenticación mutua y establecer
parámetros criptográficos. Es muy utilizado en las implementaciones de VPN (Virtual Private Network).
• Secure Shell (SSH). Es un protocolo que permite el login y servicios de red a sistemas remotos.
• Secure
multipurpose Internet mail extensions (S/MIME). Es un estándar para la protección de correos electróni-
cos.
• 3D Secure. Es un protocolo basado en XML para otorgar seguridad en las transacciones de tarjeta de débito y de
crédito.
Si te interesa el tema de la criptografía, le recomiendo la película El Código Enigma donde se cuenta la historia de
cómo se logró romper la criptografía de la maquina alemana que encriptaba los mensajes de guerra durante la Segun-
Diagrama Objetivos Inicio
da Guerra Mundial.
LECTURA SELECCIONADA Nº 1:
Lecturas Glosario Bibliografía
seleccionadas
Delgado, V., & Palacios, R. (2006). Aplicaciones prácticas de la criptografía. Anales de Mecánica y Electricidad. Dispo-
nible
Recordatorioen:Anotaciones
http://bit.ly/2bcFvh1
Diagrama Objetivos Inicio
ACTIVIDAD N.° 4
Desarrollo Actividades Autoevaluación
de contenidos
Participan en el Foro de discusión subiendo un ensayo sobre cuando utilizar los diversos tipos de criptografía.
3. Elabora un ensayo sobre cuando utilizar los diversos tipos de criptografía y súbelo al aula virtual.
4. Participa en el foro de discusión, emitiendo tu opinión sobre el trabajo de un compañero, como mínimo.
Auditoría de sistemas
UNIDAD IV: Auditoría a la seguridad de la información MANUAL AUTOFORMATIVO 105
INTRODUCCIÓN
Este tema está enfocado en los controles a implementar tanto en la Seguridad de Internet, como en el cloud y los
móviles.
1 Seguridad en Internet
La Seguridad de Internet tiene que ver con los controles a implementar por las compañías para protegerse de las
amenazas provenientes de Internet.
• Crackers. Más conocidos como los criminal hackers. Son personas con conocimientos tecnológicos (no necesaria-
mente muy sofisticados) que realizan actividades ilegales como ingresar a los sistemas de información para robar
información con el fin de obtener un beneficio económico.
Hay que diferenciar el cracker del hacker. El hacker no es un criminal. Es una persona con altos conocimientos
tecnológicos y que averiguan como ingresar a un determinado objetivo. Esta más orientado con la satisfacción per-
sonal que con el lucro haciendo actividades ilegales, como es el caso del cracker. Sin embargo, la persona común
no distingue entre ambos. En realidad cracker y hacker son opuestos.
• Lammers. Los lammers son aquellas personas que tienen limitaciones en su capacidad técnica y que se hacen pasar
como hackers. Es decir, presumen de sus habilidades técnicas, a pesar de que no las tienen. Los hackers utilizan
este término como un insulto para la persona que se “alucina” hacker pero que lo único que hace es utilizar pro-
gramas de fácil manejo para intentar “hackear” un objetivo.
• Wannabies. Los Wannabies son aquellas personas que están en proceso de hacerse hackers. Podría tratarse de no-
vatos con altos conocimientos técnicos pero que aún no son reconocidos por la comunidad hacker. Etas personas
perseveran estudiando y aprendiendo las diversas técnicas de ingreso a los sistemas.
• Script-Kidies. Los Script-Kiddies son personas sin conocimientos técnicos avanzados y que se dedica a utilizar pro-
gramas y scripts desarrollados por otros para atacar sistemas. Son como los lammers.
• Samurai. Los Samirai son personas con alta capacidad téncia y que son llamados por una compañía para investigar
fallos de seguridad
• Competencia. Se refiere a cualquiera de los anteriores y que es contratada por la competencia para acceder a los
sistemas de una determinada compañía. En Latinoamerica existe un espionaje industrial en aumento y las compa-
ñías deben protegerse de la competencia.
Las compañías para defenderse de las amenazas de Internet, implementan controles, los cuales veremos a continua-
ción.
1.1 Firewalls
El Firewall es considerado como el control primario de defensa de las compañías. El firewall puede ser visto como una
garita de peaje. En función a ciertas reglas permite o no el acceso entre 2 redes. Los firewalls pueden ser implementa-
dos en hardware o software, o en una combinación de ambos
El firewall también puede ser usado al interno para proteger algunas partes de la red que solo deben ser accedidas, por
ejemplo la red donde se encuentren los servidores.
• Filtrado
de paquetes. Este tipo de firewall filtra cada paquete tomando únicamente la información contenida en
el paquete en sí, utilizando generalmente una combinación del emisor del paquete y la dirección de destino, su
protocolo, y, en el tráfico TCP y UDP, el número de puerto. Este tipo de Firewalls fue el primer tipo, y actualmente
no es muy utilizado.
• Aplicación. Este tipo de Firewall es usado con los servidores proxy. En esta situación no se da una trasferencia de
datos de forma directa entre redes, porque existe un monitoreo de la información.
• Stateful
Inspection. Este tipo de firewall realiza un seguimiento del estado de las conexiones de red (TCP, UDP) que
cruzan a través de él, dejando pasar solo a los paquetes que coincidan con una conexión activa conocida.
Cuando se implementa un firewall, una buena práctica es seguir la guía de la NIST SP 800-41. Puede ubicar la norma
en el siguiente link: http://csrc.nist.gov/publications/nistpubs/800-41-Rev1/sp800-41-rev1.pdf
Otro punto digno de mencionar lo constituyen los firewalls de Nueva Generación (NGFW). Estos Firewalls son capa-
ces de entender las aplicaciones Web 2.0 (Facebook, Dropbox, Youtube, etc) y también se conectan con los sistemas
LDAP y con ello conocen a los usuarios de la red. La compañía palo Alto invento este concepto y se está apoderando
rápidamente del mercado de Firewalls.
1.2 IDS
a) IDS basado en red (NIDS). Cuando se implementa en la red, el IDS analiza el tráfico de la red (o parte de ella),
inspeccionado los paquetes en busca de situaciones anómalas. Un NIDS es un control que complementa a los fi-
rewalls.
Una analogía para comprender el NIDS son los controles antes de abordar un avión. Cuando Ud. quiere abordar un
avión hay una persona que se encarga de verificar si el boarding pass coincide con su documento de identidad. Si todo
esta OK, Ud. Es autorizado a seguir. Este control es como el Firewall. Luego de que Ud. ha pasado, se tiene que pasar
por el control de rayos X. Ud. tiene que quitarse cualquier cosa que porte y sus cosas pasan por la máquina de rayos X.
Los rayos X verifican el contenido que Ud. porta. Este control es el IDS.
Un punto importante cuando se implemente un NIDS es donde se coloca el IDS. Dado que cada paquete de datos es
examinado, poner un IDS puede significar una degradación en la performance de la red.
b) 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 críticos del Sistema ante cambios no autorizados. Veamos un ejemplo. Si
un servidor cuenta con un HIDS e ingresa un malware a dicho Servidor, cuando el malware intenta agregar o cam-
biar una llave en el regedit, el HIDS toma este cambio como una situación anómala y detiene el intento.
Una de las mega tendencias en TI indudablemente es la adopción del Cloud Computing. Mucho se ha escrito del
Cloud y existe algo de confusión en este tema.
Las definiciones oficiales de Cloud se encuentran en la guía NIST SP 800-145. La guía la puede ubicar en:
http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf
Auditoría de sistemas
UNIDAD IV: Auditoría a la seguridad de la información MANUAL AUTOFORMATIVO 107
Según esta guía, el Cloud es un “modelo para habilitar el acceso de red de forma continua, conveniente y bajo deman-
da a un conjunto de recursos de computación configurables que puedan ser rápidamente provisionados y lanzados
con un mínimo esfuerzo de gestión e interacción con el proveedor de servicio”.
Asimismo la guía define 5 características que debe cumplir toda solución para ser considerada Cloud:
• Pooling de recursos
• Rápida elasticidad
• Servicio medido
https://www.youtube.com/watch?v=0xPENqtDVXU
El Cloud no está exento de riesgos. Entre los principales riesgos de negocio tenemos:
• Pérdida
de control. La compañía pierde control de las soluciones tecnológicas, toda vez que un proveedor se en-
carga del servicio.
• Mayor
relevancia del proveedor. Coherente con el punto anterior, el proveedor al controlar el servicio tiene mayor
ventaja para negociar con el cliente.
• Menor visibilidad del destino de los datos. En el cloud no deberían interesar al cliente donde están sus datos. Sin
embargo, algunos países exigen que los datos no salgan de sus territorios.
• Ambigüedad
de responsabilidades. Ante la ocurrencia de un problema, el proveedor y el cliente podrían verse
enfrentados debido a una evasión de las responsabilidades.
• •Adaptación de usuarios al nuevo modelo. Cambiar el modo de trabajar de los usuarios hacia una solución 100%
web podría 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 protección de la información cuando es accedida
desde los dispositivos móviles tanto de propiedad de la compañía como de los propios usuarios.
• Incapacidad
de medir cumplimiento. El modelo de Cloud se basa en la medición. Esto origina riesgos en el cliente
para saber si la medición es la adecuada.
• Falla
de la Nube. En caso de falla en la Nube, la compañía se quedaría sin servicio. El Internet se convierte en un
recurso crítico. Sin Internet no hay acceso a la solución.
En relación a los riesgos de seguridad de la información, la principal organización que investiga estos temas es la Cloud
Security Alliance. Su sitio web es: https://cloudsecurityalliance.org/
Esta organización emite todos los años un informe de las amenazas que afectan a los servicios Cloud. El último informe
es el informe The Treacherous 12 CSA’s Cloud Computing Top Threats in 2016, en el cual se definen las principales
amenazas, las cuales se presentan a continuación:
3. APIs inseguras
5. Secuestro de cuentas
8. Pérdida de Datos
https://downloads.cloudsecurityalliance.org/assets/research/top-threats/Treacherous-12_Cloud-Computing_Top-
Threats.pdf
3. Seguridad de Móviles.
Hubo un tiempo en que los usuarios dentro de una compañía le pedían asesoría al área de TI, sobre que tecnología
adquirir. El área de TI era el área experta y los usuarios agradecidos seguían los consejos que el área de TI ls daba. Esos
son tiempos muy lejanos. El día de hoy estamos viviendo una tendencia en que los usuarios saben tanto de tecnología
como el área de TI. Esto es particularmente cierto en el caso de las tecnologías móviles. Incluso, las tecnologías de in-
formación llegan primero al consumidor y luego son adoptadas por las compañías. Este fenómeno es conocido como
la consumerización de la tecnología. Es por esta razón que los dispositivos móviles están prácticamente al alcance de
cualquier persona.
Esto enfrenta a las compañías a la decisión de si permitir o no el ingreso de los dispositivos móviles. Las compañías
enfrentan el día de hoy estas realidades:
• Los usuarios tienen mejor tecnología que la prevista por sus empresas
• COPE
(Corporate Owned Personally Enabled). En esta estrategia la compañía adquiere los dispositivos móviles y
los entrega a sus trabajadores. Dado que la propiedad de los dispositivos es de la compañía, los dispositivos están
sujetos a las políticas y restricciones que la compañía impone.
• BYOD
(Bring Your Own Device). En esta estrategia la compañía permite a sus trabajadores que traigan sus propios
dispositivos móviles personales y les permite que desde dichos dispositivos se accedan a activos de información de la
compañía tales como correo electrónico, Intranet, VPN, acceso a Sistemas internos, entre otros. Esto significa que
en un dispositivo personal conviven aplicaciones e información tanto del usuario como de la compañía.
Auditoría de sistemas
UNIDAD IV: Auditoría a la seguridad de la información MANUAL AUTOFORMATIVO 109
Estas nuevas tendencias en las que la información de la compañía reside en los dispositivos móviles generan nuevos
riesgos. Entre los riesgos más relevantes tenemos:
• Robo
o pérdida de dispositivo. Si se pierde el dispositivo móvil, no solo se pierde información personal del usuario,
sino que un tercero podría tener acceso a la información de la compañía.
• Fuga
de datos. Si la compañía no implementa controles, un usuario podría sacar información de la compañía sin
ningún tipo de restricción.
• Acceso no autorizado. Un dispositivo móvil no protegido puede ser accedido ante un descuido del usuario y la
información de la compañía podría ser accedida de manera no autorizada.
• Propagación
de malware. Los dispositivos móviles son ahora otro canal de propagación del malware. El malware
está presente en todas las plataformas.
Los riesgos presentados son solo algunos de los riesgos a los que se enfrentan los dispositivos móviles. Puede ver un
video sobre este tema (en inglés) en: http://www.youtube.com/watch?v=iJUwz2b64Sw
a) iOS.
El SO de Apple es considerada la plataforma más segura debido a que toda App es revisada por Apple antes de ser pu-
blicada en el Apple Store. Esto permite con un cierto grado de confiabilidad que las Apps publicadas en el App Store
son seguras.
A pesar de los controles, los criminales informativos se las han arreglado para meter malware en algunas Apps.
http://www.lavanguardia.com/tecnologia/moviles-dispositivos/iphone-ipad/20150925/54436836215/apple-apps-
malware.html
b) Android.
La plataforma móvil de Google es considerada una de las más inseguras debido a que no cuenta con los controles que
Apple exige. Los diversos estudios indican que esta es la plataforma móvil preferida para la distribución del malware y
la generación de Apps maliciosas, precisamente por que Google no controla las Apps publicadas en Google Play.
A favor de Android se puede decir que diversos especialistas consideran que el diseño del Sistema Operativo Android
es seguro. El riesgo no está en el Sistema operativo, sino que radica en los privilegios que los usuarios otorgan a las
diversas Apps que se descargan.
c) Windows Mobile.
Antes conocido como Windows Phone. La plataforma móvil de Windows no es precisamente la más popular. Al igual
que Apple, Microsoft revisa cada App antes de ser publicada en la tienda. Windows Mobile “carga con la mochila” de
ser un producto Windows y por tanto expuesto al malware de la plataforma Windows. Dado que Windows Mobile no
es tan popular no hay tanto malware como en otras plataformas moviles.
110 UNIDAD IV: Auditoría a la seguridad de la información
INTRODUCCIÓN
Este tema está enfocado en como efectuar una Auditoria de Sistemas a la Seguridad de la información.
En líneas generales, el Auditor de Sistemas debe efectuar las siguientes tareas cuando revisa la Seguridad de la Infor-
mación:
• Revisar la existencia de Inventarios de Activos de Información y la existencia de Propietarios para los Activos.
• Revisión
de controles para minimizar riesgos en cada uno de los Activos de Información a través de la existencia de
Baselines de seguridad.
A continuación presentaremos las principales tareas que realiza el Auditor de Sistemas cuando audita los controles de
seguridad.
Es muy común para los auditores encontrar accesos vigentes de usuarios que ya no laboran o de cuentas que ya no se
utilizan. En ese sentido el Auditor realiza las siguientes revisiones:
• Revisión
de usuarios vigentes y cesados. Lo que se trata de encontrar es accesos de usuarios ya cesados y que siguen
vigentes en los sistemas.
• Revisión
de cuentas genéricas / de servicio. Aquí se trata de identificar si todas las cuentas genéricas tienen un pro-
pietario, si están vigentes. Por las cuentas de servicio se revisa si es que siguen vigentes.
• Revisión
de Privilegios. Se revisa los permisos que tienen los usuarios dentro de un determinado Sistema. El propie-
tario debe validar si los permisos están vigentes.
• Revisión
de autorizaciones para el acceso. Se revisa que todo acceso cuente con su autorización correspondiente
por parte del propietario del Activo de información
• Revisión
de gestión de llaves. El auditor revisa el ciclo de vida de las llaves criptográficas: ¿Cómo se crean? ¿Quién
las crea? ¿Cómo se almacenan? ¿Qué controles existen para proteger las llaves?
• Fortaleza
de los algoritmos criptográficos. El auditor revisa los algoritmos utilizados en las diversas implementacio-
nes para verificar su vigencia y robustez.
Auditoría de sistemas
UNIDAD IV: Auditoría a la seguridad de la información MANUAL AUTOFORMATIVO 111
Así por ejemplo una página muy usada por los Auditores es https://www.ssllabs.com/ssltest. Esta página permite revi-
sar la robustez de los algoritmos criptográficos y del certificado digital de una página web.
• Revisar reglas del Firewall. Se revisan las reglas para encontrar inconsistencias o reglas demasiado genéricas que
permiten accesos indebidos.
• Revisar reglas del IDS/IPS. Se revisan las reglas en busca de debilidades en las reglas de detección de anomalías.
• Revisar la actualización de los dispositivos de Seguridad. El Auditor revisa que los diversos dispositivos se encuen-
tren con las versiones vigentes y con los parches correspondientes.
A nivel de Cloud, como es evidente no se puede auditar a los proveedores de Cloud. En ese contexto se revisan si se han
implementado los controles ofrecidos por la solución Cloud. Asimismo se revisan los Contratos y si los SLAs ofrecidos
por el proveedor Cloud se cumplen.
Finalmente a nivel de los dispositivos móviles se revisan que en los móviles COPE y BYOD se tengan implementados
controles para asegurar la confidencialidad de la información contenida en dichos móviles. Así por ejemplo, el Audi-
tor revisa que la compañía tenga alguna solución de control como por ejemplo MDM (Mobile Device Management).
112 Diagrama Objetivos Inicio
UNIDAD IV: Auditoría a la seguridad de la información
LECTURA SELECCIONADA Nº 2:
Lecturas Glosario Bibliografía
seleccionadas
Leer
Diagramaartículo:
Objetivos Seguridad
Inicio en dispositivos móviles: ¿qué pautas debes seguir?.
Velasco, J. (2013). Seguridad en dispositivos móviles: ¿qué pautas debes seguir?. Disponible en http://bit.ly/2bxHOZZ
Recordatorio Anotaciones
Desarrollo Actividades Autoevaluación
de contenidos
Diagrama Objetivos
TAREA ACADEMICA Nº 2
Inicio
Esta actividad
Lecturas
Glosario
seleccionadas puede
Bibliografía
consultarla en su Aula virtual.
Desarrollo Actividades Autoevaluación
de contenidos
Recordatorio
GLOSARIO DE LA UNIDAD IV
Anotaciones
Activo de información. Recurso informático que trata información. Puede ser una Base de datos, un Sistema, un Ser-
vidor, etc.
Recordatorio Anotaciones
BYOD. Acrónimo de Bring Your Own Device. Es una estrategia utilizada por las compañías para permitir a los usuarios
traer sus propios dispositivos y conectarlos a la red de la Compañía.
COPE. Acrónimo de Corporate Owned personally Enabled. Es una estrategia usada por las compañías para entregar a
sus trabajadores dispositivos móviles.
Cuenta de Servicio. Es una cuenta utilizada por un Sistema de Información o dispositivo de red para comunicarse con
otro sistema o dispositivo. La cuenta de Servicio no es utilizada por ningún usuario.
Cuenta genérica. Es una cuenta utilizada para un usuario para un propósito específico pero que no cuenta con sus
Objetivos Inicio
nombres y apellidos. Toda cuenta genérica debe contar con un Propietario.
BIBLIOGRAFÍA DE LA UNIDAD IV
Glosario Bibliografía
s
Information systems audit and control association. (2016). CISA Re-view Manual. Chicago: ISACA.
o Anotaciones
Auditoría de sistemas
UNIDAD IV: Auditoría a la seguridad de la información MANUAL AUTOFORMATIVO 113
Objetivos Inicio
AUTOEVALUACIÓN DE LA UNIDAD IV
Actividades Autoevaluación
s
1. Después de 2 meses, la Universidad “Universal”, descubre un hueco de seguridad que permitió a 2 alumnos reali-
s
Glosario
zar un ataque informático y acceder y modificar las notas almacenadas en la Base de Datos del Sistema Académico.
Bibliografía
El descubrimiento fue accidental. En este caso, la Universidad habría podido detectar oportunamente si es que
tuviese implementado en la Base de datos:
o Anotaciones
A) Algoritmo criptográfico RSA de Criptografía asimétrica
A) Topología de la red
B) Interconexion de la red
D) Gateway a Internet
3. Ud. Encuentra que el área de IT ha adquirido un Firewall de Nueva Generación y encuentra que el equipo esta
dimensionado para soportar hasta 200Mbps de ancho de banda de Internet. Sin embargo, debido a una reciente
fusión la Compañía, el trafico esta en 290 Mbps Esta situación origina el riesgo que hay trafico sin proteger. Su
recomendación se enfoca en:
A)
Adquirir un nuevo equipo para soportar el throughput de la red
4. ¿La autenticación de doble factor es una obligación en cuál de las siguientes situaciones?
5. La Ley de Protección de datos obliga a las compañías a proteger los datos que se transmiten sobre la red. Ud. en-
cuentra que una compañía ha aumentado dramáticamente la transmisión de datos con diversos socios de negocios
y se transfieren datos personales ¿Cuál de los siguientes algoritmos Ud. recomienda utilizar para proteger la trans-
misión?
6. Ud. encuentra que un sistema de información guarda las contraseñas en plano. ¿Cuál de los siguientes algoritmos
Ud. recomienda utilizar para almacenar las contraseñas?
7. ¿En cuál de las siguientes situaciones Ud. recomendaría la implementación de tokens como mecanismo de auten-
ticación?
8. Un auditor encuentra que los usuarios de una empresa trasnacional utilizan sin ningún tipo de restricción aplica-
ciones personales de almacenamiento en la nube tales como Dropbox, Google Drive, Microsoft One Drive entre
otras para almacenar información de la Empresa. Los usuarios que utilizan estos servicios son considerados por el
auditor como:
A) Amenaza
C) Falta de control
D) Vulnerabilidad
Auditoría de sistemas
MANUAL AUTOFORMATIVO 115
9. ¿Cuál de las siguientes opciones es la que otorga la postura más robusta de seguridad?
A)
Contraseña + Token
B) Biometría + Token
D) Contraseña + Biometría
10. Ud. requiere configurar un WiFi corporativo basado en la tecnología Cisco. Al configurar el enrutador inalámbri-
co, el Sistema le presenta varias opciones para configurar la encriptación del tráfico. Al respecto, ¿Cuál de los siguien-
tes algoritmos Ud. seleccionaría?
A) 3DES
E
B) AES ste manual autoformativo es el mate- muro y las tareas, siempre acompañado de tus
rial didáctico más importante de la docentes y amigos.
C) RSA
presente asignatura. Elaborado por el
D) SHA-II
docente, orienta y facilita el auto aprendizaje El modelo educativo de la Universidad Con-