Auditoria de La Seguridad

Introducción a los sistemas de
información y su auditoría
[1.1] ¿Cómo estudiar este tema?
[1.2] Introducción a los sistemas de información y el rol de la

auditoría informática
[1.3] Definiciones de «auditoría informática» y de «control

interno informático»
[1.4] Funciones y objetivos de la auditoría informática
[1.5] Diferencias entre control interno y auditoría informática
TEMA
Esquema
TEMA 1 – Esquema
Introducción a los Sistemas de Información y su auditoría
2
Auditoría informática
Rol de la Reseñas Funciones y objetos de
Glosario vs.
auditoría históricas la auditoría informática
Control Interno Informático
© Universidad Internacional de La Rioja (UNIR)

Auditoría de la Seguridad
Ideas clave
1.1. ¿Cómo estudiar este tema?
Para estudiar este tema lee las Ideas clave que encontrarás a continuación y presta
especial atención a los diferentes libros, vídeos y páginas web recomendados en los
respectivos apartados incluidos al final de este tema.
Este tema presenta una Introducción a los sistemas de información y el rol de la auditoría
informática, diferenciándolo del Control Interno Informático.
1.2. Introducción a los sistemas de información y el rol de la

Este capítulo introductorio realiza un recorrido, a través de sus apartados, por algunos
aspectos que el alumno debe conocer para entender qué es un sistema de información,
la función de la auditoría informática en las organizaciones y su decisiva contribución a
las TIC.
Un sistema de información es el conjunto de procesos, personas, datos y actividades

que procesan la información en una determinada empresa. Los procesos pueden ser
manuales y/o automáticos
Los activos de Sistemas de Información
Según International Standard Organization (ISO): «Algo que tiene valor para la
organización» (ISO/IEC 13335-1:2004). Un activo de sistemas de información (SI)
sería todo aquello que una entidad considera valioso por contener, procesar o generar
información necesaria para el negocio de la misma. Todo sistema de información
utilizado por la organización (en régimen de propiedad, subcontratación o pago por uso)
deberá:
» Salvaguardar la propiedad de la información. Los activos de SI asegurarán que

la propiedad de los datos sea siempre de la organización.
TEMA 1 – Ideas clave 3 © Universidad Internacional de La Rioja (UNIR)

» Mantener la integridad de los datos (información). Los activos de SI deben

garantizar la integridad de la información, es decir, que la información no ha sido
alterada por terceros (físicos o humanos).
» Asegurar la confidencialidad de la información. La información solo es accesible y
entendible por quien tiene derechos.
» Garantizar la disponibilidad de la información. La organización puede
disponer de la información en el momento en que la precise.
» Llevar a cabo los fines de la organización y utilizar eficientemente los recursos.
El último punto indica que los Sistemas de Información (SI) han de ser eficientes
(cumplir con los objetivos de la organización), eficaces (deben ser útiles para la mejor
utilización por parte de los usuarios) y económicos (es decir, al menor coste posible)
en recursos y unidades monetarias.
De manera que todo sistema de información eficaz y eficiente se basa en:
» Planificación: un sistema de información no es un elemento aislado, sino que

convive de forma colaborativa con otros sistemas de información con los que
interactuará en la consecución de los objetivos de negocio.
Las personas se interrelacionan y trabajan con otras personas y departamentos, de

igual modo los datos se estructuran y agregan otros datos, las aplicaciones interactúan
entre sí y los elementos hardware son parte de una infraestructura TIC
interrelacionada sobre la que se ejecutan los aplicativos.
Por tanto, tras asumir el punto anterior como cierto, el diseño, ejecución o adquisición
de un sistema de información no debe ser una decisión aislada sino formar parte de
una plan. Es decir, todo sistema de información, si se desea que sea eficaz y eficiente,
deberá estar adecuadamente planificado.
» Controles: más adelante desarrollaremos ampliamente la definición y tipología de

los controles. Baste decir que un sistema de información eficaz y eficiente deberá estar
controlado; es decir, deberán existir mecanismos para medir y asegurar que el activo
de información lleva a cabo su cometido de una forma eficaz y eficiente.
» Procedimientos: el uso de los sistemas de información por parte de la organización
deberá estar descrito para asegurar su efectividad y eficacia y basarse en un marco de

procesos y procedimientos definido por la propia organización como sustento

necesario para la gestión, posibilitadora del adecuado gobierno.
» Estándares: el marco de gestión indicado en el punto anterior deberá basarse en los
estándares internacionales reconocidos para asegurar la interoperabilidad de la
organización con otras organizaciones y con el libre mercado.
» Sistemas de seguridad: todo sistema de información organizativo debe
desenvolverse en el contexto de un marco de gestión de la seguridad que conduzca a
asegurar la integridad, confidencialidad y disponibilidad de la información generada,
tratada o accedida por dicho sistema de información
La ausencia de alguno de los elementos anteriores como base de un sistema de

información, especialmente en un entorno informático, puede dar lugar a diversos
riesgos con impacto en la organización.
Las TIC como apoyo al plan estratégico de las empresas
El plan TIC debe dar respuesta a las necesidades del negocio expuestas en el plan
estratégico de la organización y ser coherente con este.
El alineamiento del plan estratégico y del plan de las TIC tiene una doble dirección en la
medida en que el negocio conforma las necesidades de sistemas de información y la
tecnología posibilita medios cada vez más eficaces y eficientes para cubrir los objetivos
de negocio, por lo que ambos planes han de retroalimentarse y estar alienados para
asegurar el adecuado gobierno de las TIC.
Si bien es necesario el alineamiento e integración entre el plan estratégico y el plan de

TICs, así como una adecuada coordinación entre el CIO (Chief Information Officer) y el
CEO (Chief Executive Officer) se habrá de tener siempre en cuenta que la tecnología está
al servicio del negocio, de manera que los avances tecnológicos han de ser entendidos y
digeridos por la organización a través de su plan TIC para extraer de ellos todo su
potencial y contribución al negocio, pero sin condicionar este o hacerlo dependiente de
la tecnología (esto que parece obvio evitar, acontece en buena parte de los casos).
Reseña histórica y el rol del auditor informático.
El crecimiento de las organizaciones y el avance tecnológico confluyen a mediados del

siglo XX, de manera que a partir de 1950 y durante la década de los 60, con la aparición

de ordenadores más potentes, pequeños y económicos, la informática se convierte en una

herramienta muy importante en las labores de auditoría financiera, ya que permite
realizar de forma rápida y precisa operaciones complejas que manualmente llevarían
mucho consumo de tiempo y personas. Así, se transforma en un medio decisivo para el
análisis y procesamiento de la información y en la preparación y presentación de los
resultados de auditoría.
Se desarrolla la denominada auditoría con el ordenador, a la que no se le considera

auditoría informática —y no debe confundirse con ella— ya que se trata únicamente de
una auditoría en la que se utiliza el ordenador como herramienta del auditor
financiero.
Pero es el evolucionar tecnológico lo que altera el soporte y medio de generación,

tratamiento y procesamiento de la información.
Es decir, si al inicio de la función auditora los auditores trabajaban con información

escrita, a medida que las TIC penetran en la organización como un medio de desarrollo
estratégico del negocio, el soporte de la información se vuelve electrónico y la
información es generada, tratada, almacenada y procesada a través de medios
informáticos, en algunos casos de forma automática y en otros manual.
La búsqueda de la exactitud y veracidad de la información nos lleva a plantearnos si a lo

largo de su ciclo de vida la información ha podido verse alterada por intervención
humana o por un error de procesamiento; es decir, el auditor financiero empieza a
plantearse si la información que les daban los sistemas (Mainframes) eran correctos o
estaban manipulados.
La Ilustración 1 muestra un esquema del tratamiento informático de la información:
Salida
Entrada Proceso
(Información)
MAINFRAME
Procesamiento informático de la información

Es decir, las organizaciones han diseñado e implementado o adquirido procesos

informáticos (aplicativos) capaces de generar información de salida a partir de unos
datos de entrada: elaborar un balance contable cruzando información de distintas
fuentes, generar un informe contable basado en los estados de cuentas de las distintas
unidades, etc.
Por tanto, las organizaciones necesitan poner en marcha controles para asegurar la
integridad y exactitud de la información, pero también necesitarán de una auditoría
independiente capaz de entender las interioridades de los procesos informáticos y revisar
el correcto funcionamiento de los controles existentes.
Surge entonces la figura del auditor informático que entendía lo que sucedía en
el proceso de información dentro de aquellos mainframes.
Inicialmente, el auditor informático es un perfil técnico (analistas-programadores)

independiente que extraía información del sistema informático auditado, dando soporte
a las necesidades que pudiera tener el auditor financiero, quien era el verdadero
conductor y responsable de la auditoría.
Pero pronto el auditor informático va asumiendo nuevas funciones y responsabilidades,

pasando de ser un mero soporte técnico al servicio del auditor financiero para cubrir los
aspectos tecnológicos de la auditoría a realizar funciones de una marcada importancia
para las organizaciones, entre las que podríamos destacar:
» Analista programador para el auditor financiero.

» Revisión de controles internos informáticos generales
» Revisión de controles por área o departamento
» Revisión de controles por aplicaciones
» Revisión de controles de producto informático (por ejemplo Oracle, IBM-
DB2, CISCO PIX, SAP, etc.).
» Revisión de controles de sistemas de gestión de TICs (por ejemplos
estándares ISO, NIST, etc.)
» Revisión de aspectos legales (en España y otros países existe la Ley Orgánica de
Protección de Datos–LOPD)
La Auditoría Informática se desarrolla principalmente en Estados Unidos, Reino Unido

y Australia a finales de los años 60. Concretamente, la profesión de auditoría y control

interno de las Tecnologías de la Información y las Comunicaciones se constituye con la

creación en 1969 de la EDPAA (Electronic Data Processing Auditors Association).
En 1993, el nombre de la asociación EDPAA cambia a ISACA (Information Systems

Audit and Control Association, www.isaca.org).
En 1998, ISACA funda el ITGI (IT Governance Institute), encargado de desarrollar y

divulgar conocimientos sobre el gobierno de los sistemas de información.
1.3. Definición de «auditoría informática» y «control interno

informático»
Este apartado define los conceptos de auditoría, de auditoría informática y de

control interno informático y presenta algunos tipos de auditoría.
Definición de Auditoría
Lawrence B. Sawyer (1985) (Sawyer’s Internal Auditing: The Practice of Modern Internal
Auditing) en (Sawyer’s Internal Auditing: The Practice of Modern Internal Auditing)
define la auditoría como: «Una sistemática evaluación de las diversas operaciones y
controles de una organización, para determinar si se siguen políticas y
procedimientos aceptables, si se siguen las normas establecidas, si se utilizan los recursos
eficientemente y si se han alcanzado los objetivos de la organización».
La auditoría evalúa ajustándose a un sistema con el objetivo de determinar de

forma objetiva, basada en evidencias, el uso eficiente de los sistemas de información,
la conformidad a una norma, etc.
Los resultados de una auditoría han de estar basados en evidencias
El auditor debe obtener evidencia suficiente y completa, mediante la aplicación de

procedimientos de inspección y procedimientos analíticos, para fundamentar en ella las
conclusiones de la auditoría.

Por tanto, la evidencia del auditor ha de ser suficiente y completa:
» La suficiencia mide la cantidad de la evidencia; es decir, si sustenta las

conclusiones o hay un margen de incertidumbre. Está asociada a la característica de
relevancia de la evidencia.
» La completitud mide la calidad de la evidencia y el grado en que está basada en
hechos demostrables. Está asociada a las características de neutralidad, autenticidad
y verificabilidad de la evidencia.
Algunos métodos de obtención de evidencias por parte del auditor son:
» Inspecciones (documentales o físicas).

» Observación.
» Entrevistas.
» Procedimientos analíticos.
Las evidencias pueden ser:
» Físicas: obtenidas a través de las inspecciones y la observación.

» Testimoniales: obtenidas en las entrevistas.
» Documentales: obtenidas en inspecciones y en las entrevistas.
» Analíticas: obtenida a través de cálculos, comparaciones, tendencias, etc.
Tipos de auditoría
Tradicionalmente han existido diversas clases de auditoría en función de su contenido,

objeto y finalidad:
» De Cumplimiento: tiene como objetivo verificar e informar sobre el cumplimiento

de las disposiciones, normativas y leyes laborales, civiles, estatutarias, tributarias,
comerciales, de seguridad social e industrial, medio ambiente, etc.
» Financiera: es la revisión de los controles y los registros de contabilidad de una
empresa, cuya conclusión es un dictamen acerca de la corrección de los estados
financieros de la misma.
» De Gestión: su objetivo es evaluar el grado de eficacia en el logro de los objetivos
previstos por la organización y la eficiencia en el uso de los recursos.

» Informática (o de sistemas de información): su objetivo es evaluar el

alineamiento de las TIC con la estrategia organizativa, la eficacia de los sistemas de
información y el uso eficiente de los recursos.
Desde otro enfoque, podríamos clasificar las auditorías como:
» Interna: realizada por personal vinculado laboralmente a la institución pero

independiente al ámbito auditado, con el fin de garantizar los principios de
independencia y objetividad.
» Externas: realizada por personal no vinculada a la empresa auditada.
Todas los tipos de auditoría se basan en los principios de independencia, sistematicidad

y objetividad.
Definición de control interno informático
El control interno informático es el conjunto de medidas (controles) que la organización

implementa para asegurar en el día a día el adecuado alineamiento de las TIC a los
objetivos de negocio sin perder la eficacia, eficiencia y economía. Los objetivos del
control interno informático son:
» Garantizar diariamente que todas las actividades de SI sean realizadas

cumpliendo los procedimientos, estándares y normas fijados por la Dirección de la
Organización y/o Dirección de Informática, así como los requerimientos legales.
» El grado de eficacia de los SI, es decir, la medida en que los sistemas de
información cubren los objetivos de negocio para los que fueron diseñados.
» El uso eficiente de los recursos por parte de los SI: la misión del Control
Interno Informático es asegurarse de que las medidas que se obtienen de los
mecanismos implantados por cada responsable sean correctas y válidas.

Definición de Auditoría Informática
Ron Weber (1988) ha definido la auditoria informática como el proceso de recoger,

agrupar y evaluar evidencias para determinar si un sistema informático:
» salvaguarda los activos

» mantiene la integridad de los datos
» lleva a cabo los fines de la organización
» utiliza eficientemente los recursos
Es importante mencionar que el proceso de auditoría informática no debe contemplar

únicamente los aspectos técnicos, sino también los de planificación, gestión y
organizativos.
1.4. Funciones y objetivos de la auditoría informática
El objetivo principal del auditor es el de evaluar y comprobar en determinados

momentos del tiempo los controles y procedimientos informáticos más complejos,
objeto del análisis, desarrollando y aplicando metodologías de auditoría.
La auditoría informática emplea las mismas técnicas descritas de inspección y

observación, entrevistas, documentación y procedimientos analíticos propios de
cualquier tipo de auditoría, si bien:
» En la auditoría informática, las técnicas de inspección harán un mayor uso de

software de inspección capaz de automatizar la verificación de los sistemas de
información que en el caso del resto de tipos de auditoría.
» La auditoría informática no se denomina de ese modo por este mayor uso de medios
informáticos sino porque el objeto auditado son los sistemas de información, las TIC.
Es decir, actualmente no es posible verificar manualmente procedimientos

informatizados que resumen, calculan y clasifican datos, por lo que se deberá emplear
software de auditoría–CAATS (Computer Assisted Audit Techniques).

El auditor es responsable de:
» Llevar a cabo la auditoría, lo cual implica:
o Planificar la auditoría.
o Llevar a cabo las distintas tareas definidas en las fases de la auditoría.
o Escuchar y observar (recordemos el origen latino del término: aquel que tiene la
capacidad de oír).
o Gestionar las desviaciones y riesgos que pudieran producirse durante la auditoría.
» De informar a la Dirección de la Organización acerca de:
o El diseño y funcionamiento de los controles implantados.

o La fiabilidad de la información suministrada (su competencia).
o La suficiencia de las evidencias, o la medida en que sustentan las conclusiones de
auditoría
El auditor presentará a la dirección de la organización un informe de auditoría que

contendrá, entre otros puntos:
» Las conclusiones de la auditoría.

» Las no conformidades:
o Menores y mayores
o Evidencias relacionadas
» Las observaciones:
o Evidencias relacionadas
» Una descripción de la auditoría:

o Objetivo.
o Alcance.
o Fases y fechas.
o Técnicas empleadas.
o Áreas auditadas.
o Entrevistados.

» La relación de evidencias detectadas y por cada una:

o Su competencia.
o Su suficiencia.
1.5. Diferencias entre control interno y auditoría informática
La auditoría informática es la revisión independiente, sistemática y objetiva

del control interno informático.
La Ilustración 2 esquematiza las diferencias entre control interno informático y auditoría

informática:
CONTROL INTERNO
AUDITOR INFORMÁTICO
INFORMÁTICO
• Personal interno. Conocimiento especializados en TIC
Semejanzas • Verificación del cumplimiento de controles internos, normativa y

procedimientos establecidos por Dirección Informática y la Dirección general
para los SI
• Análisis de los controles en el día a
día • Análisis de un momento informático
determinado
• Informa a la Dirección del
Departamento de Informática • Informa a la dirección General de la
Organización
Diferencias • Son personal interno
• Personal interno y/o externo
• El alcance de sus funciones es
únicamente sobre el Departamento de • Tiene cobertura sobre todos los
Informática componentes de los Sistemas de
Información de la Organización
La principal diferencia entre ambos radica en que:
» el control interno informático realiza su verificación en el día a día, asegurando la

eficacia y eficiencia de los controles.
» la auditoría informática lleva a cabo un análisis con una frecuencia puntual, en un
momento determinado y con un propósito muy concreto. Es como una «foto» en un
momento concreto.

Gobierno corporativo y gobierno de TI
El gobierno corporativo se define como un comportamiento empresarial ético por

parte de la Dirección y Gerencia para la creación y entrega de los beneficios para
todas las partes interesadas (Stakeholders).
Según IT Governance Institute (ITGI) —cuya misión es asistir a los líderes empresariales
en su responsabilidad de asegurar que las TIC están alineadas con el negocio y generan
valor, medir su rendimiento y comprobar que sus recursos son adecuadamente
administrados y sus riesgos gestionados y mitigados — el gobierno de TI es una parte
integral del gobierno corporativo. Y consiste en liderar y definir las estructuras y procesos
organizativos que aseguran que las Tecnologías de la Información y Comunicaciones
(TIC) de la empresa soportan y difunden la estrategia y los objetivos de la organización,
siendo la responsabilidad del comité de dirección y gerencia.
De ambos conceptos podemos extraer los siguientes planteamientos:
» El gobierno de TI es el alineamiento estratégico de las TI con la organización, de tal

forma que se consigue el máximo valor de negocio por medio del desarrollo y
mantenimiento de un control y responsabilidad efectivos, la gestión de la eficiencia y
la eficacia (desempeño), así como la gestión de riesgos de TI.
» El plan informático (plan TICs) se tiene que corresponder con el plan estratégico de
la empresa, en el que el primero es un Control General de más alto nivel tal, y como
veremos más adelante.
Es necesario que cada organización administre sus recursos de TI a través de un conjunto

estructurado de controles para asegurar la integridad, exactitud, confidencialidad y
disponibilidad que requiere para su negocio.
La ISACA (Information System Audit and Control Association) y el ITGI han

desarrollado un Marco de Objetivos de Control para Información y Tecnologías
Relacionadas (COBIT, en inglés: Control Objectives for Information and related
Technology) que viene a ser una guía —en su actual versión es COBIT 5— de mejores
prácticas dirigida a la gestión de tecnología de la información (TI).

Directrices del gobierno de TI
El gobierno no solo persigue el logro de los objetivos del negocio (para lo cual será
necesaria la gestión) sino que además estos objetivos habrán de lograrse asegurando la
sostenibilidad de la organización o entidad, en equilibrio y cumplimiento de unos
principios de responsabilidad, ética y conducta. Ver la siguiente ilustración.
Estructura Gobierno de TI según ISO 38500.

Fuente: ISO
Estos principios vertebran las directrices del buen gobierno mencionadas por el estándar
internacional ISO 38500; en concreto:
» Responsabilidad: todo el mundo debe comprender y asumir sus responsabilidades

en la oferta o demanda de TI. La responsabilidad sobre una acción lleva aparejada la
autoridad para su realización.
» Estrategia: la estrategia de negocio de la organización tiene en cuenta las

capacidades actuales y futuras de las TI. Los planes estratégicos de TI satisfacen las
necesidades actuales y previstas derivadas de la estrategia de negocio.
» Adquisición: las adquisiciones de TI se hacen por razones válidas, basándose en un

análisis apropiado y continuo, con decisiones claras y transparentes. Hay un
equilibrio adecuado entre beneficios, oportunidades, costes y riesgos tanto a corto
como a largo plazo. Existe una planificación.

» Rendimiento: la TI está dimensionada para dar soporte a la organización,

proporcionando los servicios con la calidad adecuada para cumplir con las
necesidades actuales y futuras. Es decir, existe una gestión de la capacidad y
continuidad de la TI para que sea resiliente, asegurando la sostenibilidad del negocio.
» Conformidad: la función de TI cumple todas las legislaciones y normas aplicables.

Las políticas y prácticas al respecto están claramente definidas, implementadas y
exigidas.
» Conducta humana: las políticas de TI, prácticas y decisiones demuestran respecto

por la conducta humana, incluyendo las necesidades actuales y emergentes de todas
las partes involucradas.
El rol de la auditoría en el gobierno de TI
La auditoría informática —o de sistemas de información— es una pieza clave

en la medición de la eficacia de los controles puestos en marcha por la organización para
asegurar el cumplimiento de los objetivos del negocio, ya que es la que está mejor
posicionada para:
» Recomendar prácticas a la alta dirección, con el fin de mejorar la calidad y efectividad

de las iniciativas y controles de gobierno de TI implantados.
» Asegurar el cumplimiento de las iniciativas de gobierno de TI.
La auditoría informática necesitará evaluar los siguientes aspectos relacionados con el

gobierno de TI:
» El alineamiento de la función de TI con la misión, la visión, los valores, los objetivos

y las estrategias de la organización.
» El logro por parte de la función de TI de los objetivos de eficiencia y eficacia
establecidos por el negocio.
» Los requisitos legales, de seguridad y los propios de la empresa.
» El entorno de control diseñado y puesto en marcha por la organización.
» Los riesgos intrínsecos dentro de TI, su probabilidad de ocurrencia y su grado de
impacto en el negocio.

Es importante destacar que recomendar e informar a la alta dirección por parte del
auditor implica:
» Definir el alcance de la auditoría, incluyendo áreas y aspectos funcionales a cubrir.

» Establecer el nivel de dirección al que se entregará el informe de auditoría.
» Garantizar el derecho de acceso a la información por parte del auditor, poniendo a su
disposición el conjunto de información necesario y la colaboración por parte de todos
los departamentos de la empresa, así como de los terceros relacionados.

Lo + recomendado
No dejes de leer…
Auditoría de los estándares ISO en las TIC: una herramienta de la dirección
Fernández, C. M. (2010). Auditoría de los estándares ISO en las TIC: una herramienta
de la Dirección. Revista red de seguridad, 45.
Este artículo elaborado por D. Carlos Manuel Fernández, Gerente de TICs de AENOR,
presenta el modelo de ISO en las TIC y el papel de la auditoría interna y externa como
herramienta para la dirección.
Accede al artículo desde el aula virtual o a través de la siguiente dirección web:

http://www.redseguridad.com/opinion/articulos/auditoria-de-los-estandares-iso-en-
las-tic-una-herramienta-de-la-direccion
No dejes de ver…
Auditoría informática y modelo COBIT
Este vídeo presenta los aspectos introductorios de los sistemas de información y el

concepto de la auditoría informática.
Accede al vídeo desde el aula virtual o a través de la siguiente dirección web:

http://www.youtube.com/watch?v=va8RRPmMaac
TEMA 1 – Lo + recomendado 18 © Universidad Internacional de La Rioja (UNIR)

+ Información
A fondo
The IS Audit process
Anantha Sayana, S., CISA, y CIA (2002). The IS Audit process. ISACA Journal, 1.
Este excelente artículo concentra en su corta extensión los aspectos clave de la auditoría
de sistemas de información con tanta completitud como concreción y brevedad en su
exposición.

https://isaudit101.wordpress.com/chapter_i/
Enlaces relacionados
ISACA
Página web de la Asociación de Auditoría y Control de Sistemas de Información. En ella

también encontrarás información sobre el ITGI, el IT Governance Institute.
Accede a la página desde el aula virtual o a través de la siguiente dirección web:

http://www.isaca.org
TEMA 1 – + Información 19 © Universidad Internacional de La Rioja (UNIR)

ISO
Página web de ISO (International Standards Organization).

http://www.iso.org
Bibliografía
Fernandez, C.M., Piattini, M., Pino, F. (2014). Modelo de madure de ingeniería del
software. AENOR Ediciones.
Fernández, C.M., Piattini, M. (2012). Modelo para el gobierno de las TIC basado en las
normas ISO. AENOR Ediciones.
Gómez, L., Fernández P.P. (2015). Cómo implantar un SGSI según UNE-ISO/IEC
27001:2014 y su aplicación en el Esquema Nacional de Seguridad. AENOR Ediciones.
Guide to Using International Standards on Auditing in the Audits of Small- and
Mediumsized Entities. NY, 2007.
ISO 20000-1 para PYMES. Como implantar un sistema de gestión de servicios de

tecnologías de la información. Nextel y AENOR Ediciones.
ICAC (2003). Norma Técnica de Auditoría sobre la auditoría de cuentas en entornos

informatizados. BOICAC nº 54.
INTOSAI: Guía para las normas de control interno del sector público. (INTOSAI GOV
9100).
Lynne, M. y Daniel, R. TIC y cambios organizativos.

Marco para la auditoría de los sistemas de información. 2009 ISACA Capítulo Madrid.
NIST SP 800-100, Information Security Handbook.
Piattini, M., Del Peso, E. (2000). Auditoría Informática: Un enfoque práctico. Editorial
Ra-MA.
Piattini, M., Del Peso, E. y Fernández, C.M. (Coautor). (2008). Auditoría de Tecnologías
y Sistemas de Información, RA-MA.
Piattini, M., Hervada, F. (2007). Gobierno de las tecnologías y los sistemas de

información. RA-MA.
The Institute of Internal Auditors (2007). The GAIT Principles. Altamonte Springs.
GTAG 1: Information Technology Controls.
VV.AA. (2009). Marco para la auditoria de los sistemas de información. ISACA Madrid.
Weber, R. (1998). EDP Auditing: Conceptual Foundations and Practice. Ed. McGraw
Hill.

Test
1. A principios de la segunda mitad del siglo XX la informática se convierte en una

herramienta muy importante para la auditoría financiera. En este ámbito, marque la
verdadera:
A. La auditoría informática es sinónima de la auditoría financiera con el ordenador.
B. La auditoría con el ordenador, como apoyo al auditor financiero, no es auditoría
informática.
C. La auditoría informática es la realización de auditorías de cualquier tipo con un
ordenador.
D. El auditor financiero y el auditor informático no colaboran entre sí.
2. En los años 60, el auditor informático:

A. No se le tiene en cuenta para ninguna actividad.
B. Es un analista financiero que aprende de las arquitecturas de sistemas de la
época y realiza él mismo las auditorías.
C. Es inicialmente un analista programador que forma parte de los mainframes
que audita.
D. Es inicialmente un analista programador independiente que presta ayuda al
auditor financiero.
3. ¿Cuál de las siguientes afirmaciones no es cierta?

A. Una función del auditor informático puede ser realizar revisiones del control
interno de una empresa.
B. Una función del auditor informático puede ser revisar aspectos legales
directamente relacionados con la tecnología.
C. Una función del auditor informático puede ser revisar el balance contable de una
empresa.
D. Una función del auditor informático puede ser revisar la instalación de un
producto software de acuerdo a unas especificaciones.
TEMA 1 – Test 22 © Universidad Internacional de La Rioja (UNIR)

4. El Gobierno de TI se puede definir como:

A. El alineamiento estratégico de las TI con la organización de tal forma que se
consigue el máximo valor de negocio por medio del desarrollo y mantenimiento de
un control y responsabilidad efectivas, gestión de la eficiencia y la eficacia.
B. El alineamiento estratégico de las TI con la organización de tal forma que se
consigue el máximo valor de negocio por medio del desarrollo y mantenimiento de
un control y responsabilidad efectivas, gestión de la eficiencia y la eficacia, así como
la gestión de riesgos de TI.
C. Consiste en liderar y definir las estructuras y procesos organizativos que
aseguran que las Tecnologías de la Información y Comunicaciones (TIC) de la
empresa soportan y difunden la estrategia y los objetivos de la organización,
manteniéndose de forma autónoma al comité de dirección y gerencia.
D. Ninguna de las anteriores.
5. Es función del gobierno de TI:

A. Gestión de eficacia y eficiencia así como gestión de riesgos, entre otros.
B. Políticas y procedimientos, gestión de riesgos entre otros.
C. Exclusivamente gestión de eficacia y eficiencia.
D. Control y responsabilidad así como gestión de riesgos entre otros.
6. ¿Cuál de las siguientes afirmaciones es cierta?

A. El plan estratégico de la empresa se tiene que corresponder con el plan
informático de TI. El primero se diseña en función del segundo.
B. Las organizaciones con consideración a las TI, tienen menor retorno de
inversión que aquellas que no lo consideran ante los mismos objetivos estratégicos,
de tal forma que con la madurez tecnológica se llegue a un estado de mayor retorno.
C. El plan informático de TI no se tiene que corresponder con el plan estratégico
de la empresa.
D. Ninguna afirmación es cierta.

7. El rol de la Auditoría en el Gobierno de TI consiste en:

A. Implantar prácticas a la alta dirección, con el fin de mejorar la calidad y
efectividad de las iniciativas del gobierno de TI implantadas y asegura el
cumplimiento de las iniciativas de gobierno de TI.
B. Asumir responsabilidades de Dirección detectando necesidades e
implantándolas como función de control interno dentro del departamento de TI.
C. Realizar evaluaciones y únicamente asegurar el cumplimiento de las iniciativas
de gobierno de TI.
D. Recomendar prácticas a la alta dirección, con el fin de mejorar la calidad y
efectividad de las iniciativas del gobierno de TI implantadas y asegura el
cumplimiento de las iniciativas de gobierno de TI.
8. El Comité de informática:
A. Se encarga de hacer de interfaz entre los usuarios y los informáticos. Está
compuesto por expertos en una materia y conocen muy bien el negocio/modelo de
datos que manejan.
B. Diseña el plan estratégico de la compañía.
C. Elabora el Plan Director de Informática, que se corresponde con el Plan
Estratégico. Puede ser a un año o a dos.
9. Señala la correcta en relación a objetivos y funciones del auditor informático:

A. Participar en las revisiones e implantaciones durante y después del diseño,
realización, implantación y explotación de aplicaciones informáticas.
B. Revisar y analizar los controles implantados en los sistemas de información para
verificar su adecuación de acuerdo a las directrices de la Dirección, requisitos
legales, protección de confidencialidad y cobertura ante errores y fraudes.
C. Revisar, analizar y en su caso corregir indicando acciones a realizar, el nivel de
eficacia, utilidad, fiabilidad y seguridad de los equipos y sistemas informáticos en
general.
D. Revisar y analizar los controles implantados en los sistemas de información para
verificar su adecuación de acuerdo a las directrices de la Dirección, estableciendo
y dirigiendo las desviaciones detectadas aplicando acciones de mejora.

10. El CII (Control Interno Informático) se diferencia del auditor informático en:
A. No tiene cobertura sobre todos los componentes del sistema de información de
la organización.
B. Son personal interno o externo.
C. Realizan un análisis del control interno informático diariamente.
D. Informan a la Dirección General en tiempo real.

Controles internos de los Sistemas de
Información
[2.2] Organigrama funcional de un centro de proceso de datos
[2.3] Clasificación de los controles de los sistemas de

información
[2.4] La regla de oro
TEMA
Esquema
TEMA 2 – Esquema
Controles internos de los Sistemas de Información
2
Organigrama Clasificación
Controles Controles de Controles Controles de La regla de
funcional de controles de
generales aplicación por área productos oro
un CPD SI

Ideas clave
Para estudiar este tema lee las Ideas clave que encontrarás a continuación y presta
especial atención a los diferentes libros, vídeos y páginas web recomendados en los
respectivos apartados incluidos al final de este tema.
Este tema presenta la estructura funcional de un Centro de Proceso de Datos (CPD) y los
principales controles internos.
2.2. Organigrama funcional de un centro de proceso de datos
La Ilustración 1 presenta el organigrama funcional de un Centro de Proceso de Datos. Es

un modelo que nos servirá de apoyo para entender más fácilmente las explicaciones de
los apartados siguientes del tema.
Comité de
informática DSI o CIO
Control interno de
Director del Dirección de sistemas tecnologías de la
CPD de información información (CITI)
Director del CPD Admón. Seg. Control de Garantía de Control del

FACTORÍA Lóg. Física sistema calidad calidad de datos
WEB
BigData/BI DESARROLLO Y EXPLOTACIÓN OFIMÁTICA MOBILITY
MASTER/
MANTENIMIENTO
COMMUNITY
MANAGER
Centro de HW SW
atención al
Cloud Jefe de usuario (CAU)
Computing proyecto
Analista Técnico de
programador sistemas
(mantienen)
Captura de
Sistema Sist. de gestión
Telecomunicaciones datos
operativo de BDD
DATA CENTER (Producción)
Distribución Preparación Planificación Operación Cintoteca
Jefe de sala
AQUÍ ESTÁN LOS DATOS
REALES
Operadores

Los Centros de Proceso de Datos concentran los recursos necesarios para el

procesamiento de la información de una organización.
El tema 2 describe cada una de las principales funciones intervinientes en un Centro de

Proceso de Datos.
2.3. Clasificación de los controles de los sistemas de información
Los controles son acciones y mecanismos definidos para prevenir o reducir el impacto de
los eventos no deseados que ponen en riesgo a los activos de una organización.
Un control puede actuar de forma preventiva:
» Reduciendo la vulnerabilidad de un activo de información.

» Reduciendo la amenaza.
Y de forma correctiva mitigando el impacto del riesgo materializado.
Algunos de los atributos de un control son:
» Objetivo del control: objetivo general del control: qué se pretende medir,
conseguir, etc.
» Descripción del control: descripción detallada del control. En qué consiste.
Descripción funcional y técnica. Dependencias, etc.
» Frecuencia del control: frecuencia de ejecución del control o elementos que lo
disparan (trigger).
» Ejecución: forma de ejecución del control (manual, automática, mixta) e
información de ejecución, explotación y operación del control.
» Monitorización: información detallada de la forma de monitorización por parte del
control, conteniendo al menos:
o Elementos que se monitorizan.
o Frecuencia de monitorización.
o Plantilla de monitorización (KPIs que se analizan).
o Informe de monitorización.

En la práctica, la función de control interno deberá describir con el suficiente nivel de

detalle el control, ya que en buena parte de los casos será el departamento de explotación
y producción quien implante el control siguiendo las indicaciones descritas por control
interno informático.
En una clasificación general de los controles, podríamos decir que estos pueden ser:
» Voluntarios: cuando la organización los diseña a fin de mejorar los procesos.

» Obligatorios: si son impuestos por autoridades externas o reguladoras.
» Manuales: cuando son ejecutados por personas.
» Automáticos: si son llevados a cabo a través de sistemas de información
automatizados.
» Generales: cuando van dirigidos al entorno donde operan otros controles.
» De aplicación: cuando operan integrados en el software.
Si atendemos a su naturaleza, podríamos clasificar los controles en controles

preventivos, detectivos y correctivos:
» Preventivos: actúan sobre la causa de los riesgos con el fin de disminuir su

probabilidad de ocurrencia. Es decir, pueden eliminar la vulnerabilidad de un activo
(lo que lo hace inseguro) o la amenaza del activo (el elemento de riesgo). También
actúan para reducir la acción de los generadores de riesgos. Es decir, puede actuar de
forma preventiva mitigando el impacto que, en caso de que se materializase el riesgo,
podría haber sobre el activo. Ver la ilustración 2.
Controles correctivos
Entrada Proceso Salida
Controles preventivos Controles detectivos
» Detectivos: los controles detectivos constituyen la segunda barrera de seguridad y

pueden informar y registrar la ocurrencia de los hechos no deseados, accionar
alarmas, bloquear la operación de un sistema, monitorizarlo de forma más exhaustiva,
dejarlo en cuarentena o alertar a las autoridades. Ver ilustración 3.

» Correctivos: estos controles actúan una vez detectado el evento y permiten el re-
establecimiento de la actividad normal después de ser detectado el evento no deseable
y la modificación de las acciones que propiciaron su ocurrencia; es decir, la
eliminación de la causa para evitar futuras ocurrencias de dicho evento. Los controles
correctivos suelen ser más costosos porque actúan cuando ya se han presentado los
hechos que implican pérdidas para la organización. Ver ilustración 4.
» Alternativos o compensatorios: estos controles están basados en la revisión y

comparación de las salidas del ordenador contra los documentos originales
A continuación se presentan las características principales de los controles generales, así

como las de los controles de aplicación.
Controles generales
Los controles generales contribuyen a asegurar el correcto funcionamiento de los

sistemas de información, creando un entorno adecuado para el correcto
funcionamiento de los controles de aplicación
La eficacia de los controles generales no es garante por sí sola de la eficacia de los

controles de aplicación.
Sin embargo, la ineficacia de los controles generales muy probablemente implicará la

ineficacia de los controles de aplicación.

» Controles de organización y operación: la efectividad de todos los controles

dependerá de los controles de organización y operación; es decir, de cómo la
organización haya definido su organización y operación. La existencia de políticas y
planes estratégicos y de TI, la gestión del presupuesto, la definición de las estructuras
organizativas para la adecuada segregación de funciones y un buen marco
procedimental son algunos de los controles de organización y operación de cuya
eficacia dependerá buena parta de la eficacia del resto de controles generales y de los
controles de aplicación.
o Plan Estratégico de la Empresa y el Plan Estratégico Informático: el plan

estratégico informático debe estar alineado con el plan estratégico de la empresa.
o Control de Presupuestos: la Dirección de Sistemas de información debe
cuantificar los costes directos e indirectos de la TI y calcular el presupuesto
necesario para cubrir lo que le requiere el negocio.
o Separación de Entornos: para una adecuada operación de los sistemas de
información tiene que existir una división entre los entornos de desarrollo, prueba
y explotación de los Sistemas de Información dentro del CPD. Ver las ilustraciones
5, de separación de entornos, y la 6, de separación de entornos en más niveles.
Entorno de Desarrollo Entorno Testing Entorno de Explotación
Entorno de Entorno Entorno de Entorno de

Desarrollo Testing Preexplotación Explotación

» Controles de desarrollo, de sistema y de documentación: son los controles

de los que se dota una organización para regular el qué, cómo y quién de las
actividades de desarrollo y sistemas del CPD. Es decir, estos controles identifican:
o El conjunto de estándares y buenas prácticas de referencia.

o Un marco de trabajo para llevar a cabo estas acciones.
o Procedimientos descriptivos de cada acción y de los responsables de llevarla a cabo.
El objetivo de los controles de desarrollo, de sistemas y documentación es el de

permitir alcanzar la eficacia del sistema de información, eficiencia en el uso de
recursos, integridad de los datos, protección de los recursos y cumplimiento con las
leyes y regulaciones.
» Controles de hardware y software de sistemas: a continuación se describen

algunos controles de hardware y software de sistemas, entre los que se destacan los
controles de seguridad lógica y de seguridad física, que se caracterizan por preservar
los siguientes aspectos:
o Confidencialidad, asegurando que solo quien esté autorizado puede acceder a la

información.
o Integridad, asegurando que la información y sus métodos de proceso son exactos
y completos.
o Disponibilidad, asegurando que los usuarios autorizados tienen acceso a la
información y a sus activos asociados cuando lo requieren.
Además, existen otros controles de hardware y software de sistemas, entre los que
podemos destacar:
o El plan de adquisición de equipos.

o Plan de gestión de la capacidad de los equipos.
o Controles para el uso eficaz de los recursos de computación: como son el calendario
de carga de trabajo y la programación de tareas.

Por último, están los controles de seguridad lógica y física, que se caracterizan por
preservar:
o Confidencialidad, asegurando que solo quien esté autorizado puede acceder a la

información.
o Integridad, asegurando que la información y sus métodos de proceso son exactos
y completos.
o Disponibilidad, asegurando que los usuarios autorizados tienen acceso a la
información y a sus activos asociados cuando lo requieren.
La siguiente ilustración presenta las principales propiedades asociadas a la

información: confidencialidad, integridad y disponibilidad:
Propiedades de la información
Fuente: Aenor
Controles de aplicación
Podríamos definir un control de aplicación como las actividades manuales y/o

automatizadas que aseguran que la información y los sistemas de información que la
generan o procesan cumplen con ciertos criterios o requerimientos del negocio. (COBIT:
requerimientos de negocio para la información).
Estos criterios son:
» Efectividad (requerimiento para los sistemas de información).

» Eficiencia (requerimiento para los sistemas de información).
» Confidencialidad (requerimiento para la información).
» Integridad (requerimiento para la información).

» Disponibilidad (requerimiento para la información).

» Cumplimiento (requerimiento para la información).
» Confiabilidad (requerimiento para la información).
Las aplicaciones deben incorporar controles que garanticen la entrada, actualización,

validez y mantenimiento completos y exactos de la información.
Entre los controles de aplicación podemos distinguir:
» Controles de entrada de datos: procedimientos de conversión y de entrada,

validación y corrección de datos.
» Controles de tratamiento de datos: para asegurar que no se dan de alta, modifican
o borran datos no autorizados para garantizar la integridad de los mismos mediante
procesos no autorizados.
» Controles de salida de datos: para la gestión de errores en las salidas, etc.
Controles por área
Son los controles que cubren las áreas funcionales ya definidas para un CPD, es decir
controles que pudieran ser específicos no de un sistema o aplicación o generales a la
organización, sino particulares de una de las áreas funcionales del CPD.
» Controles de productos informáticos: son controles que debe tener un producto

informático comercial, de forma que cumpla con la definición de Control Interno
Informático de la organización.
» Controles por motivos legales: requieren de ayuda por parte de un auditor legal. En el
sector tecnológico, en España y Europa, las leyes de propiedad intelectual (LPI), de
protección de datos (LOPD), de servicios de sociedad y de la información y comercio
electrónico (LSSICE), etc. Deben existir controles para garantizar su cumplimiento.
Nota: En México y Perú se están ya aplicando algunas de estas leyes de TICs. Asimismo,
en otros países de lengua hispana.

2.4. La regla de oro
La regla de oro que el Control Interno Informático de la organización ha de tener siempre

en mente para diseñar e implantar los controles es el principio básico de
proporcionalidad.
Es decir, deben cuantificarse los siguientes aspectos:
» Coste de diseño, implantación, monitorización y mantenimiento del control.

» Coste , que podría ser una de las siguientes opciones:
o Coste del impacto que tendría el riesgo sobre la organización en caso de que la
amenaza explotara la vulnerabilidad del activo; es decir, caso de que se
materializara el riesgo.
o Coste potencial de la no implementación del control.
Y la organización deberá aplicar la regla de oro analizando:
Riesgo vs. Control vs. Coste

Lo + recomendado
No dejes de leer…
La revisión de los controles generales en un entorno informatizado
Minguillón, A. (2010). La revisión de los controles generales en un entorno

informatizado. Revista Auditoría, 52, pp. 125-136.
Este artículo detalla los controles generales y de aplicación, así como algunas normas
técnicas de auditoria aplicables según el sector.

http://www.auditoriapublica.com/hemeroteca/PAG%20PAG%20125-136.pdf
Controles generales y controles de aplicación
Este post explica los controles generales y de aplicación en el marco COBIT.

http://cobitlinuxsop2ujmd.blogspot.com.es/p/controles-generales-de-ti-y-
controles.html

No dejes de ver…
COBIT 5: The next evolution
Este vídeo presenta el marco de gestión y gobierno del COBIT 5, la importancia de la IT

en las organizaciones y los controles internos.

http://www.youtube.com/watch?v=PEqtgFZ4Pfo
Controles internos de Sistemas de información
Este vídeo presenta los controles internos de sistemas de información de una

organización.

https://www.youtube.com/watch?v=ixJoIpycocM

+ Información
A fondo
Control interno: informe COSO
Mantilla Blanco, S. A., Committee of the Sponsoring Organizations of the Treadway

Commission (2007). Control interno: informe COSO. Bogotá: Ecoe.
Este libro, redactado por el Committee of the Sponsoring

Organization of the Treadway Comission (COSO), define en
detalle los controles generales y de aplicación.
COBIT 5
Página web del framework para la gestión y el gobierno de la IT: Cobit5.

http://www.isaca.org/COBIT/Pages/default.aspx

Bibliografía
Ciborra, C. (2002). Labyrinths of Information, Oxford, Oxford University Press.
COBIT and APPLICATION CONTROLS. A management guide. ISACA.
Estupiñan, R. (2015). Control Interno y Fraudes con base en los ciclos transaccionales.
Análisis de informe COSO I, II y III. EDICIONES Ecoe.
Gómez, L. Fernández, P.P. (2015). Cómo implantar un SGSI según UNE-ISO/IEC

Gomindan, M., Picard, J. (1990). Manifesto of Information Systems. Control and

Management.
INTOSAI: Guía para las normas de control interno del sector público. (INTOSAI GOV
9100).
IT Control Objectives for Sarbanes-Oxley. (2006). The importance of IT in the design,

implementation and sustainability of internal control over disclosure and financial
reporting. Segunda edición, Rolling Meadows.
Marco para la auditoría de los sistemas de información. 2009 ISACA Capítulo Madrid.
Piattini, M. Del Peso, E., Fernández, C.M. (Coautor). (2008). Auditoría de Tecnologías
Piattini, M. Hervada, F. (2007). Gobierno de las tecnologías y los sistemas de

información. RA-MA.
Soley, J. Basilea II: una nueva forma de relación banca empresa. MCGRAW-HILL.

The Institute of Internal Auditors (2007). The GAIT Principles. Altamonte Springs.
GTAG 1: Information Technology Controls.
US Government Accountability Office (GAO). Federal Information System Controls

Audit Manual.
VV.AA. (2009). Marco para la auditoria de los sistemas de información. ISACA Madrid.
Weber, R. (1998). EDP Auditing: Conceptual Foundations and Practice. Ed. McGraw
Hill.

Test
1. Los controles son:

A. Acciones y mecanismos definidos por el auditor para prevenir o reducir el
impacto de los eventos no deseados que ponen en riesgo a los activos de una
organización.
B. De muchos tipos. Los más habituales son los detectivos, correctivos y
preventivos. Permiten al auditor centrarse en otras actividades cuando los
encuentra implantados.
C. Acciones y mecanismos definidos para prevenir o reducir el impacto de los
eventos no deseados que ponen en riesgo a los activos de una organización.
D. Acciones y mecanismo definidos que protegen a las organizaciones solo ante
posibles pérdidas en el desarrollo normal de las actividades.
2. El CII (Control Interno Informático) garantiza:

A. Que las auditorías que se realicen, tengan un 95 % de éxito y no se detecten
debilidades y deficiencias importantes.
B. Que todas las actividades de sistemas de información sean realizadas
Organización y/o Dirección de Informática.
C. Que todas las actividades de sistemas de información sean realizadas
Organización y/o Dirección de Informática, así como los requisitos legales. Su
establecimiento evita la realización de auditorías internas y externas.
D. Que todas las actividades de sistemas de información sean realizadas
Organización y/o Dirección de Informática, así como los requisitos legales.
3. En relación a la clasificación de controles internos, según su naturaleza podemos

afirmar que:
A. Son normalmente Detectivos, Correctivos y Preventivos. En ocasiones se
incluyen los controles alternativos.
B. Voluntarios, obligatorios, manuales y automáticos.
C. Voluntarios, obligatorios, manuales, automáticos, preventivos, detectivos y
correctivos.
D. Controles generales, de aplicación, de área y legales.

4. En relación a la clasificación de controles internos, según su naturaleza podemos

afirmar que:
A. Los controles Detectivos actúan sobre la causa de los riesgos con el fin de
disminuir su probabilidad de ocurrencia.
B. Los controles Preventivos se diseñan para descubrir un evento, irregularidad o
resultado no previsto, alertan sobre la presencia de riesgos y permiten tomar
medidas inmediatas, pudiendo ser manuales o automáticos.
C. Las opciones a y b son correctas.
D. Las opciones a y b son incorrectas.
5. Los Controles Generales se clasifican en:

A. Controles de Organización y Operación, Controles de Tratamiento de Datos, así
como Controles de Hardware y Software de Sistemas.
B. Controles de Entrada de datos, Controles de Tratamiento de datos y Controles
de Salida de datos.
C. Controles de Organización y Operación, Controles de Desarrollo de Sistemas y
Documentación, así como Controles de Hardware y Software de Sistemas.
D. Ninguna de las anteriores es cierta.
6. En relación al Control General/Controles de Organización y Operación–Separación

de Entornos, habitualmente:
A. Los usuarios deben realizar Sign-off antes de su liberalización y paso a
Producción.
B. En el entorno de Testing solo se realizan pruebas de Caja Blanca porque en
Desarrollo ya se han realizado de Caja Negra.
C. Los casos de prueba planificados en el entorno de Testing solo se realizan
pruebas integradas.
D. Las pruebas realizadas en el entorno de Desarrollo deben contener datos reales.
7. Dentro de Controles Generales, podemos afirmar que NO son Controles de

Organización y Operación:
A. Seguridad Lógica y Física, controles de procesamiento y Control de
Presupuestos.
B. Procedimientos, separación de entornos y estándares y nomenclatura.
C. Seguridad Lógica y Física, controles de procesamiento y segregación de
funciones.

D. Metodologías de SDLC, controles de edición y verificación y seguridad Lógica y

Física.
8. En relación al Control General/Controles de Organización y Operación–Separación

de Entornos, habitualmente:
A. Deberían existir al menos tres entornos (reales o virtuales) que podrían ser
Desarrollo, Testing y Explotación.
B. Existen dos entornos, Desarrollo /Testing y Explotación.
C. Deberían existir tres entornos siempre reales, que serían Desarrollo, Testing y
Explotación.
D. Siempre tienen que existir cuatro entornos. Desarrollo, Testing, Paralelo y
Explotación.
9. En relación al Control General/Controles de Organización y Operación–Segregación

de Funciones, se entiende como aquel en el que:
A. Una misma persona no puede realizar funciones determinadas en un mismo
entorno.
B. Una misma persona no puede realizar funciones determinadas en un entorno y
en otro.
C. Las opciones a y b son ciertas.
D. Las opciones a y b son falsas.
10. En relación al Control General/Controles de Hardware y Software de Sistemas–

Seguridad Lógica y Física:
A. Los controles preservan las tres dimensiones de la información.
Confidencialidad, Disponibilidad y Seguridad.
B. Los controles preservan las tres dimensiones de la información. Fiabilidad,
Disponibilidad y Confidencialidad.
C. Los controles preservan dos de las tres dimensiones de la información.
Integridad, Disponibilidad y Confidencialidad.

El proceso y las fases de la auditoría de
Sistemas de Información
[3.2] Evaluación de riesgos (EDR) y otras metodologías de

[3.3] Ejecución de una auditoría de Sistemas de Información.

Fases de auditoría
[3.4] Habilidades fundamentales del auditor de Sistemas de

Información
TEMA
El proceso y las fases de la auditoría de SI
Esquema
TEMA 3 – Esquema
EDR y otras metodologías Fases de Habilidades del auditor
de auditoría informática auditoría informático
2
EDR Genérico Preparación
EDR Simplificado
Realización
(checklist)
EDR Avanzado Redacción

(producto) Informe
Distribución
Informe

Ideas clave
Para estudiar este tema lee las Ideas clave que encontrarás a continuación y que han
sido elaboradas por el profesor. Al finalizar el tema, tienes que leer el apartado «a
fondo» para reforzar los principales conocimientos desarrollados. Además, tienes que
realizar las lecturas recomendadas y apoyarte en la bibliografía y los enlaces
relacionados asociados al tema. Por último, deberás realizar el caso práctico y completar
el test de autoevaluación.
3.2. Evaluación de riesgos (EDR) y otras metodologías de

En este primer bloque temático

desarrollaremos los principios conceptuales
del término metodología y detallaremos
diversos enfoques de metodología de auditoría
de Sistemas de Información basada en la
evaluación del riesgo (EDR) o en inglés Risk
Oriented Approach (ROA).
A continuación, presentamos la estructura de este primer bloque:
» Metodologías de Auditoría Informática

» EDR Genérico: evaluación de Riesgos (ROA, Risk Oriented Approach)
» EDR Simplificado: basado en cuestionarios o checklist
» EDR Ampliado: de productos informáticos
Es importante recordar, del tema 1, que una auditoría informática (o de Sistemas de

Información) es definida por Ron Weber como:
«El proceso de recoger, agrupar y evaluar evidencias para determinar si un sistema

informático:

» salvaguarda los activos (Humanware-personas, Información, Software, Hardware,

Infraestructuras y Telecomunicaciones)
» mantiene la integridad de los datos
» lleva a cabo los fines de la organización
» utiliza eficientemente los recursos
Es importante mencionar que el proceso de auditoría informática no debe contemplar

únicamente los aspectos técnicos, sino también los aspectos de planificación, gestión y
organizativos».
La auditoría es sistemática en la medida en la que esté basada y se ajuste a una

metodología.
A lo largo del tema analizaremos la metodología de auditoría de Sistemas de Información

basada en la evaluación del riesgo EDR (ROA-Risk Oriented Approach) en cada uno de
sus enfoques posibles: genérico, simplificado y ampliado.
Pero antes, estableceremos la base conceptual sobre la que desarrollar el resto del tema
abordando el significado del término metodología.
Metodología de auditoría informática
El término metodología (del griego μέθοδος) hace referencia al conjunto de

procedimientos y procesos utilizados para alcanzar un objetivo.
Es decir, una metodología nos dice, a través de un conjunto de procedimientos, cómo

hacer las cosas para alcanzar un objetivo.
Podríamos decir que una metodología es un conjunto de métodos que se siguen de

forma sistemática y disciplinada para la realización de un fin u objetivo
determinado.
Recordaremos del Tema 1 que, en el caso de la auditoría informática, el fin es

determinar si un sistema informático salvaguarda los activos, mantiene la integridad
de los datos, lleva a cabo los fines de la organización y utiliza eficientemente los recursos.
(Ron Weber).

Por tanto, la metodología de auditoría de Sistemas de Información que analizaremos a

continuación estructura el conjunto de pasos y métodos que si se siguen de forma
sistemática conducen a la realización correcta de una auditoria de SI.
Es importante resaltar que la auditoría debe ser una herramienta de la dirección para
asegurar el alineamiento de las TIC con el negocio y que el buen auditor no solo debe
detectar hallazgos (o findings) sino que debe ser capaz de generar valor para el negocio.
Es el concepto del Value For Auditing Money (VMAF) que marcará el aspecto
evolutivo de los auditores del futuro inmediato y que está basado en Eficacia, Eficiencia
y Economía).
En realidad, no existe una metodología única de auditoría de Sistemas de Información.

Existen una directrices generales (por ejemplo ISACA) y principios clave, pero en la práctica
cada organización —sobre todo las denominadas Big Four— que ofrezca servicios de
auditoría (Deloitte, Ernst&Young, PriceWaterhouseCoopers, KPMG, etc.) o cada empresa
que lleva a cabo auditoría interna puede desarrollar una metodología propia.
La metodología de auditoría de Sistemas de Información de una organización es un

activo más de la organización en el sentido estricto del término, ya que aporta valor para
la organización. De manera que deberá irse ajustando y madurando como herramienta
de la dirección para asegurar el correcto alineamiento de las TIC con el negocio.
En la actualidad, la metodología de auditoría informática de Sistemas de Información

más difundida y que veremos a continuación es la que está basada en la Evaluación de
Riesgos o EDR–ROA (Risk Oriented Assessment) recomendada por ISACA y creada por
Arthur Andersen.
Te recomendamos servirte del material bibliográfico, entre otros, el referente a Ron

Weber (1998). EDP Auditing: Conceptual Foundations and Practice, Ed. Mc Graw Hill,
indicado al final de tema, así como de los artículos y recursos web especificados.
EDR Genérico: evaluación de Riesgos (ROA, Risk Oriented Approach)
En términos generales diremos que en la auditoría informática basada en una

metodología de evaluación de riesgos el auditor conduce todo el proceso de auditoría a
partir de la evaluación inicial del riesgo potencial existente sobre el Sistema de
Información de la Organización.

El auditor realiza un análisis del riesgo existente en los sistemas de información incluidos
en el alcance de la auditoría, determinando a través de pruebas y herramientas de
auditoría la existencia de controles y la eficacia y eficiencia de los mismos, identificando
los riesgos existentes por defecto del control o por la implementación parcial del mismo.
Es decir, como consecuencia de la ausencia de controles o bien por ser un sistema

deficiente, los riesgos sobre los sistemas de información deben ser cuantificados y
valorados por el auditor de tal forma que permita determinar el nivel de fiabilidad que le
aporta el sistema sobre la exactitud, integridad y procesamiento de la información.
No olvidemos que uno de los principales activos de una organización es la información

sobre la que basará sus decisiones (por ejemplo el departamento de compras, sus
estrategias de marketing, su portafolio de productos, etc.) y que esta información es
generada, procesada o proporcionada por Sistemas de Información.
Por lo tanto, y dicho de otra forma, la auditoría informática basada en la evaluación de

riesgos permite cuantificar el riesgo de los sistemas de información midiendo la
completitud, eficacia y eficiencia de los controles internos puestos en marcha por la
función del Control Interno Informático de la organización.
Cada riesgo asociado a los sistemas de información bajo alcance de la auditoría tendrá
un o unos objetivos de control asociados.
El objetivo de control está encaminado a prevenir, mitigar o transferir el riesgo.
Un objetivo de control estará cubierto por un o unos controles o procedimientos puestos

en marcha en la organización por parte del Control Interno de Tecnologías de la
Información (CITI) con el apoyo de la dirección y la colaboración de todos los
stakeholders.
El auditor informático que sigue un enfoque EDR en términos generales analiza los
riesgos de los sistemas de información, los cuantifica y evalúa y analiza la completitud y
grado de eficacia de los controles organizativos para la gestión del riesgo (potencial)
identificado, sirviéndose de un conjunto de pruebas que desarrollaremos en los próximos
apartados.

A continuación, detallaremos cada uno de estos elementos principales.
» Objetivos de control: el objetivo de todo control es la reducción del riesgo. Por

tanto, el objetivo de todo control es la reducción de riesgo, bien reduciendo su
probabilidad de ocurrencia o bien mitigando su impacto.
La cuantificación de los riesgos potenciales de la organización, conocidos o no, es la

base para establecer detalladamente los objetivos de control.
El auditor informático debe cuantificar y valorar el riesgo potencial asociado a los

sistemas de información en el alcance de la auditoria. Es fundamental llamar la
atención del alumno al respecto de qué riesgo potencial es el riesgo asociado a los
sistemas de información, con independencia de la existencia o no de controles.
A partir del riesgo potencial el auditor obtiene los objetivos de control que
la organización debería haber definido para la mitigación de su riesgo
potencial.
» Controles: una vez que el auditor ha identificado los riesgos potenciales y definido
los objetivos de control necesarios para su mitigación, por cada objetivo de control
encaminado a la mitigación de un riesgo potencial se deben identificar las técnicas de
control o controles —para mayor claridad utilizaremos el término controles en lugar
de técnicas de control— que deben minimizar el riesgo, logrando cumplir así el
objetivo de control.
Un mismo objetivo de control puede quedar cubierto por varios controles. Un control
podría llevar a cubrir varios objetivos de control. Por tanto, la relación objetivo de
control-controles es una relación de «muchos a muchos».
En la práctica, los controles vienen a ser procedimientos que el control interno

informático define, implanta y mantiene para cubrir un objetivo de control (o varios).
» Pruebas de cumplimiento y pruebas sustantivas: una vez que el auditor ha

cuantificado el riesgo potencial y definido los objetivos de control encaminados a la
mitigación del riesgo, deberá valorar la completitud y eficacia de los controles internos
puestos en marcha por la organización a través de su función de Control Interno
Informático. Para ello, el auditor se servirá de las pruebas.

A través de las pruebas el auditor podrá analizar los controles internos organizativos
y cuantificar el riesgo real, ya que toda opinión o evaluación de un auditor debe estar
basada en pruebas realizadas y en la evidencia obtenida de acuerdo a una normativa
profesional.
» Pruebas de cumplimiento: este tipo de pruebas son empleadas por el auditor

informático para probar, verificar, examinar el cumplimiento de un control.
Una prueba de cumplimiento reúne evidencias de auditoría para indicar:
o si un control existe
o si funciona de forma efectiva
o si logra sus objetivos de forma eficiente
La prueba de cumplimiento es el primer nivel de prueba que realiza un auditor

informático para cuantificar el riesgo real de los sistemas de información y obtener
evidencias que sustentarán las conclusiones de la auditoría.
» Pruebas sustantivas: este tipo de pruebas son empleadas por el auditor

informático únicamente cuando las pruebas de cumplimiento no han
satisfecho los objetivos del auditor. Es importante tener en cuenta que la
realización de las pruebas sustantivas generalmente requiere de una mayor
dedicación y consumo de recursos que una prueba de cumplimiento, por lo que su uso
deberá estar restringido por parte del auditor informático a los casos que se ajusten a
la necesidad anteriormente indicada.
Nota: el número de pruebas verificadas que cubran es √n, siendo el total de la

población muestral.
A continuación podemos ver el ejemplo de un EDR genérico donde se han identificado

riesgos relacionados con seguridad de la información (seguridad lógica).

Objetivo de Prueba de
Riesgos Control Prueba sustantiva
control cumplimiento
RIESGO 1: Garantizar el Procedimiento de 1. Comprobar que -Ampliar muestra
Acceso no acceso de altas y bajas de existe un de usuarios dados
autorizado a usuarios Usuario procedimiento de de alta en cada
sistemas y autorizados y altas/bajas de área.
aplicaciones. evitar el acceso usuarios
no autorizado a 2. Seleccionar -Ampliar muestra
los sistemas y varios usuarios de usuarios dados
servicios. de cada área a los de baja en cada
que se les haya área
dado de alta
recientemente
3. Seleccionar
varios usuarios
de cada área a los
que se les haya
dado de baja
recientemente.
Procedimiento 1. Comprobar que Ampliar muestra
para la existen de usuarios que
restricción de definiciones de tengan el acceso
acceso a la perfiles de correctamente
información. usuarios por definido
áreas.
2. Verificar en
Base de Datos,
Directorio Activo
(LDAP) o RACF
que un usuario
tiene el acceso
necesario a los
sistemas de
información
Procedimiento de 1. Comprobar que Ampliar muestra
gestión de existe un de usuarios que
contraseñas procedimiento tengan el acceso
que defina la correctamente
longitud y definido
robustez de las
password de
usuario
2. Verificar en
Base de Datos,
Directorio Activo,
etc. que varios
usuarios cumplen
con la definición
de password.

Objetivo de Prueba de
Riesgos Control Prueba sustantiva
control cumplimiento
RIESGO 2: Asegurar la Procedimiento de 1. Comprobar que
Ataques e protección de la protección de red existe un
intrusión a redes información en (firewall, IDS). procedimiento de
corporativas las redes y los Procedimiento de configuración
servicios de configuración (setup),
soporte de (setup) de mantenimiento y
tratamiento de la firewalls e IDS. monitorización
información. Procedimiento de de los firewall,
mantenimiento IDS, etc.
de firewalls e 2. Comprobar
IDS. que se han
Procedimiento de implantado las
monitorización, políticas de
firewall e IDS filtrado
adecuadas para el
firewall.
3. Comprobar
que los IDS
tienen
actualizados los
ficheros de firmas
y/o reglas de
acceso.
Flujo de actividades de un EDR genérico
La siguiente ilustración muestra el flujo de un EDR genérico (metodología de

funcionamiento el auditor):

EMPEZAR 2
IMPACTO)
REALIZACIÓN DE
(VER EL
¿EXISTE
2 PRUEBAS DE
CONTROL?
SUSTANTIVAS
NO
SI
PRUEBA DE
CUMPLIMIENTO ¿EXISTE
CONFIRMACIÓN DEFICIENCIAS?
MEDIANTE PRUEBAS NO
COMENTAR
SI ID VERBAL
O LEVE
COMENTARIO MEDIO
¿CONFORME
O GRAVE SEGÚN
CON EL 2
DEFICIENCIAS O
CONTROL?
NO INCIDENCIAS
FIN
SI
FIN FIN
EDR Simplificado (checklist)
Las características principales del EDR simplificado son:
» El auditor revisa los controles con la ayuda de una lista de control (checklist) que
consta de una serie de preguntas o cuestiones a verificar (en realidad, pruebas de
cumplimiento de los controles).
» La evaluación consiste en identificar la existencia de unos controles establecidos o
estandarizados.
» Ese método de auditoría informática suele utilizarse por auditores con poca
experiencia, como guía de referencia, para asegurar que se han revisado todos los
controles.
» Es habitual establecer una tabla con los siguientes campos:
o Pregunta: orientada para saber si existen controles establecidos.

o Sí: cuando la contestación a la pregunta es afirmativa.
o No: cuando la contestación a la pregunta es negativa.
o N/A: cuando la pregunta no aplica.
o Comentarios u Observaciones: anotaciones del auditor en relación a la pregunta y
su contestación.

El EDR Simplificado podrá ser un enfoque suficiente para cubrir ciertos campos de la
auditoría de los sistemas en alcance, no sirviendo en otras áreas o sistemas dentro de
alcance en los que el auditor informático habrá de realizar pruebas de cumplimiento y
sustantivas más exhaustivas a efectos de asegurar el nivel de suficiencia y competencia
de las evidencias necesarias para sustentar sus conclusiones.
A continuación podemos ver de EDR simplificado (checklist) para el área de desarrollo
PREGUNTA SI NO N/A OBSERVACIONES

DEL AUDITOR
¿Comprobar que se han desarrollado
procesos/procedimientos, han sido documentados,
divulgados y actualizados? (SDLC)
¿Comprobar que se han recogido formalmente los
requisitos de usuario?
¿Examinar que cada fase del ciclo de desarrollo ha sido
debidamente detallada?
¿Verificar que se analizan las distintas opciones,
costes, necesidades de usuarios y recursos?
¿Comprobar que se realizan estos proyectos teniendo
en cuenta los objetivos de la organización y los
proyectos tecnológicos a largo plazo?
¿Cómo se realiza la trazabilidad entre los requisitos de
usuario y las aplicaciones/software resultado
(outcome)?
EDR Ampliado (de producto)
» Motivación: a la vista de la cantidad de productos software/aplicaciones existentes en

el mercado, es razonable pensar en realizar las auditorías con un método (propio o
diseñado por la propia empresa fabricante del producto). Nota: Diseñado por M.
Touriño y Carlos M. Fernández Sánchez.
» Definición: el EDR ampliado o de productos informáticos es un EDR específico para
una tecnología o producto concreto.
» Características: un EDR ampliado o de productos informáticos, además de los
elementos principales de un EDR genérico, se basa en:
o Audit tools: son programas de utilidad que tiene el propio producto que vamos a
auditar.
o Audit retrievals: programas o scripts desarrollados al efecto de obtener
información del producto que sea de utilidad para la auditoría.
o Audit trails: son habitualmente los logs. Contienen evidencias de lo que sucede en
el interior del sistema. Tienen como desventaja que consumen mayor tiempo de
procesador, pues por cada operación se anota en el registro.

» Formato del EDR Ampliado: el formato de la metodología basada en un EDR

ampliado podría esquematizarse de forma general de la siguiente forma (obsérvese
que mantiene la estructura del EDR genérico e incorpora aspectos avanzados
específicos del producto):
o Descripción: etapa en la que se explica la herramienta, su finalidad, ámbito,

entorno de funcionamiento, etc.
o Riesgos específicos del producto y objetivos de control: el auditor explica los
riesgos específicos del producto en determinadas situaciones o escenarios, incluso
al interactuar con otras aplicaciones. «Que es lo que puede suceder si…».
o Asimismo el auditor identifica los objetivos de control encaminados a la mitigación
del riesgo potencial asociado al producto.
o Controles que minimizan los riesgos: una vez determinados los riesgos específicos
se han debido implantar controles que reduzcan el riesgo. Recordemos la regla de
oro: Riesgo vs. control. Vs. Coste.
El auditor deberá medir en primer lugar la existencia de los controles y, en su caso,

la completitud y eficacia de los mismos para la mitigación de los riesgos asociados
al producto.
o Pruebas de los controles (cumplimiento y sustantivas): el auditor realizará las

pruebas de cumplimiento y, en su caso, las sustantivas, sirviéndose de
herramientas específicas del producto. Las audit tools (herramientas de auditoría),
audit trails (pistas de auditoría) y audit retrievals (programas, scripts de
auditoría).
Los comentarios del auditor, que formarán parte del informe de auditoría, y la gravedad
de los mismos se derivarán de las pruebas de cumplimiento y sustantivas realizadas.
En el informe de auditoría o anexos, el auditor deberá especificar las herramientas de

Audit tool, trail o retrieval empleadas.

3.3. Ejecución de una auditoría de Sistemas de Información.

Fases de auditoría
Preparación de la auditoría
A continuación se presentan cada una de las actividades que el auditor deberá realizar
con el objetivo de completar adecuadamente la etapa de preparación de la auditoría y
asegurar el correcto desarrollo del resto de etapas.
» Definición del alcance: es la definición de lo que se va a revisar durante la

realización de la auditoría. El auditor deberá identificar el alcance tomando en
consideración:
o las unidades de la organización a revisar. Por ejemplo: área de desarrollo,

seguridad lógica, seguridad física, etc.
o los sistemas informáticos específicos. Por ejemplo: CRM, ERP, etc.
o las ubicaciones físicas consideradas en el alcance de la auditoría. Las diferentes
sedes organizativas o delegaciones.
o Las terceras partes incluidas en el alcance de la auditoría: proveedores, partners,
etc.
El auditor deberá evaluar el dimensionamiento del área o sistema a auditar en

términos de complejidad, tamaño a efectos de poder realizar una estimación acertada
de los plazos y recursos necesarios para la realización de la auditoría.
» Recursos y tiempo: el auditor deberá estimar los recursos necesarios para la

realización de la auditoría, así como el tiempo requerido para la misma.
Los recursos necesarios y el tiempo estimado para la realización de la auditoría serán

dependientes del alcance definido para la auditoría, de manera que cambios de
alcance por lo general derivarán en cambios en la estimación de los recursos
necesarios o el tiempo requerido para la realización de la auditoría.

Esta etapa consiste en asignar los auditores (recursos necesarios) y el tiempo para la
auditoría. La asignación será de jornadas/hombre, incluyendo más o menos jornadas
en función del alcance definido y de la experiencia de los auditores (junior/senior),
así como del dimensionamiento del área o sistema a auditar.
» Recopilación de información básica: esta actividad consiste en identificar las

fuentes de información más relevantes con el objeto de revisarla antes de la
realización de la auditoría. Entre el tipo de información básica que el auditor puede
requerir podríamos destacar:
o organigramas funcionales
o descripción de las instalaciones
o breve descripción de los sistemas existentes
o políticas
o estándares
o procedimientos
o información de los controles actualmente implementados
o informes previos de auditorías internas o de terceras partes
Una vez analizada la información básica, el auditor deberá identificar una lista de
personas a entrevistar, especificando en la medida de lo posible:
o nombre y cargo de la persona a entrevistar.

o información relacionada con el objeto de la entrevista como por ejemplo, lista de
sistemas a revisar, lista de controles o cualquier otra información que se considere
significativa.
o fecha y hora previstas para la entrevista.
o lugar de la entrevista.
o requerimientos, como por ejemplo la documentación requerida, etc.
Es importante destacar que, si la auditoría es sorpresiva, la recopilación de la

información básica será realizada por el auditor in situ.
Si la auditoría no es sorpresiva, previamente se envía una carta de apertura o

memorandum donde se indica lo que se necesita.

» Programa de trabajo: el auditor deberá definir un plan de trabajo con la asignación

de cada auditor al área, sistema o control a revisar teniendo en cuenta:
o el alcance definido
o los recursos disponibles
o el tiempo estimado
o la información básica analizada
El programa de trabajo deberá recoger la asignación de cada auditor al trabajo que va

a realizar y deberá tener el suficiente nivel de detalle para permitir la coordinación
efectiva de las distintas entrevistas y actividades realizadas durante la auditoría.
» Plan de comunicación: uno de los aspectos clave que debe quedar acordado con el
auditado y que conformarán un factor crítico de éxito en la realización de la auditoría
es el plan de comunicación. El auditor deberá explicar y acordar con el área auditada
los aspectos de comunicación, entre otros:
o el modelo de comunicación al área auditada de los comentarios obtenidos a lo largo

de la auditoría: destinatarios, forma y frecuencia de comunicación, modo de
explicación de los comentarios y gestión de los desacuerdos.
o los destinatarios de cada uno de los informes de auditoría.
o el modelo de relación con las terceras partes (proveedores, partners).
o la visibilidad de los resultados de auditoria: si es interna a la dirección y a los
empleados, si compete a la dirección de área y la dirección de la organización o
únicamente a esta última, si se hace para los partners, los proveedores o el cliente.
Realización de la auditoría
A continuación, se describen las principales etapas que el auditor de sistemas de

información deberá completar para llevar a cabo la auditoría:
» Identificación de riesgos potenciales: consiste en detectar los posibles riesgos

en ausencia de controles relacionados. Es decir, el auditor, como ya hemos visto en el
apartado anterior, cuantifica el riesgo potencial o inherente a los sistemas de
información en ausencia de control.
» Identificación de controles fuertes y débiles: el auditor detecta controles
adecuadamente implantados y eficaces (fuertes) y otros parcialmente implantados o

que no funcionan (débiles). Por cada control débil el auditor hará un comentario que
podrá ser leve, medio o grave según la gravedad y el posible impacto en el negocio.
» Selección de las pruebas y técnicas a utilizar: el auditor decide qué tipo de
pruebas —en base a los riesgos— va a diseñar con el objetivo de objetivar el análisis y
obtener evidencias suficientes y competentes que sirvan de base a sus conclusiones:
o Pruebas de cumplimiento.
o Pruebas sustantivas.
o Técnicas de Audit trail, retrieval, tools.
» Realización de pruebas y obtención de resultados: el auditor realizará tantas

pruebas (de cumplimiento, sustantivas, etc.) como haya estimado. En ocasiones se
utilizan herramientas de apoyo al auditor (CAAT, Computer Assisted Audit
Techniques). El auditor llevará un registro de las pruebas realizadas, así como de:
o Los hallazgos obtenidos.

o La fecha del hallazgo.
o La evidencia derivada.
o Los comentarios.
o Las observaciones del auditado.
Este registro es muy importante ya que permitirá demostrar una conclusión sobre la
prueba realizada y formará parte del informe de auditoría y sus anexos.
A lo largo de la auditoría, el auditor podría decidir realizar pruebas adicionales sobre

aspectos que no hubieran quedado claros o de los que no se disponga de evidencia
«suficiente y competente».
El auditor deberá manejar en todo momento el plan de trabajo, la asignación de

recursos y las posibles desviaciones en tiempo, haciendo partícipe al auditado de la
gestión de dichas desviaciones.
» Conclusiones y comentarios: el auditor debe analizar y revisar todos los

comentarios generados a lo largo de la realización de la auditoría y los resultados de
cada prueba deben valorarse, obtener una conclusión, siempre teniendo en cuenta los
objetivos y el alcance de la auditoría.

El auditor resumirá los comentarios acerca de lo analizado (riesgos, incidencias, etc.)

y adjuntarlos al informa final.
El detalle de todos los comentarios formará parte del informe final pero en un anexo.
» Revisiones y cierre de papeles de trabajo: el auditor ha de cerrar la auditoría

cuando disponga de evidencias pertinentes, suficientes y competentes que sustenten
sus conclusiones.
Para poder demostrar cualquiera de las conclusiones, el auditor debe guardar

correctamente todas las notas recogidas (cuaderno del auditor) y mantener la
trazabilidad entre el hallazgo, los comentarios asociados, la evidencia relacionada, la
conclusión que se deriva, etc.
Redacción del informe de auditoría
Habitualmente se elabora un informe preliminar que incluya:
» Alcance y Objetivo de la auditoría.

» Metodología utilizada.
» Posibles Limitaciones.
» Resumen de auditoría.
» Conclusiones en base a los resultados obtenidos.
» Discusión con los auditados.
Es muy recomendable que el auditor comente con el área auditada los principales
hallazgos y conclusiones de la auditoría, de manera que pueda resolver cuantas dudas
tenga la parte auditada y se asegure de que esta comprende las deficiencias detectadas y
las oportunidades de mejora existentes.
A continuación, se presenta el formato habitual del informe de auditoría.

Formato del informe de auditoría
El formato del informe podría ser el siguiente:
» Antecedentes: deben reflejar brevemente lo que se ha auditado. Es información de

contexto que sirve para situar a la persona que recibe el informe cómo están las cosas:
alcance inicial de la auditoria, motivación de la auditoria, etc.
» Alcance: el auditor indica aquí el alcance real; es decir, lo que realmente se ha
auditado, que puede o no coincidir con el alcance inicial de la auditoría.
» Resumen de la auditoría: el auditor resume las etapas de la auditoría y el trabajo
realizado:
o Las ubicaciones auditadas.

o Los sistemas de información analizados.
o Las entrevistas realizadas.
o Desviaciones en programa de trabajo, recursos, etc.
o Riesgos que se han producido y cómo se han gestionado
Se trata de dar información ejecutiva y breve de cómo se ha desarrollado la auditoría.
» Conclusiones: son el resumen de los comentarios (de los que pone el auditor). Las
conclusiones deben ser ejecutivas y resumir en un lenguaje claro y preciso los
comentarios más relevantes o de mayor importancia para el negocio.
Las conclusiones no han de incluir los comentarios sino resumirlos y, en todo caso,
hacer referencia a comentarios específicos que irán en un anexo al cuerpo del informe.
Las conclusiones son normalmente discutidas con el auditado y en el informe se

recogen los eventuales desacuerdos.
» Anexo y comentarios: todos los comentarios realizados por el auditor en relación a los
hallazgos obtenidos durante la auditoría se deben recoger en un anexo al cuerpo del
informe de auditoría. Es decir, las conclusiones presentan de forma ejecutiva el
resultado de la auditoría de manera que la dirección pueda conocerlos y en el anexo
se detallan los comentarios que sustentan dichas conclusiones para el caso de que
exista alguna duda que haga necesario el acceso a dicha información.

El detalle de los comentarios no debe incluirse en el cuerpo del informe, ya que lo

haría demasiado extenso y dificultaría la llegada a la dirección de la información más
significativa, que quedaría oculta tras un excesivo nivel de detalle.
Es importante que exista una trazabilidad entre el hallazgo, los comentarios del
auditor y la evidencia derivada, de manera que los auditados puedan entender los
elementos que sustentan suficientemente y de forma objetiva las conclusiones de la
auditoría.
El auditor deberá numerar cada uno de estos elementos y permitir una fácil
trazabilidad top-down entre ellos.
Es decir, el informe de auditoría y anexos deberían permitir a los auditados, desde el

perfil más técnico hasta el perfil de dirección, llegar desde una conclusión hasta el
hallazgo que provocó el comentario del auditor y la evidencia que sustenta dicha
conclusión.
Emisión y distribución del informe de auditoría
La distribución del informe de auditoría deberá realizarse de acuerdo al plan de

comunicación acordado entre auditor y auditado en la fase de preparación de la auditoría
en la que se acuerdan los aspectos de comunicación relacionados:
» La fase de realización de la auditoria:
o Cómo se presentan los comentarios durante la auditoría a cada uno de los roles
auditados.
o Qué tipo de feedback se le da a la dirección de la organización en caso de
comentarios graves, por ejemplo, y con qué frecuencia.
» Los aspectos de distribución de los informes de auditoría:
o Audiencia.
o Formato.
o Forma de envío.

Los aspectos de comunicación son clave y deberán ser escrupulosamente cuidados por el
auditor y acordados con la dirección de la organización auditada.
Podríamos distinguir dos tipos de informe:
» Informe preliminar.
» Informe final.
Informe preliminar
El informe preliminar es el informe resultante de la auditoría, que recoge las

conclusiones de la misma y todos los apartados del mismo pero que tiene un carácter de
borrador en el sentido de que el auditor lo entrega al auditado y no recoge aún las
observaciones que la organización hará tras la lectura del informe.
El auditor deberá distribuir el informe preliminar a la audiencia definida en el plan de

comunicación acordado, y el informe deberá ser leído y entendido por los destinatarios.
Habitualmente es la Dirección de la Organización o del departamento/área auditada.
El auditor deberá asegurarse de comunicar en tiempo y forma el informe preliminar a

todos los interesados, hayan participado o no en el proceso de auditoría de acuerdo al
plan de comunicación definido y acordado.
Asimismo, el auditor deberá:
» Resolver cuantas dudas pudieran surgir por parte del área auditada o de alguno de los
destinatarios del informe preliminar.
» Explicar al área auditada a cuantos lo requieran con las evidencias suficientes y
competentes que sustentan los comentarios de la auditoría, de los cuales se derivan
las conclusiones.
» Tomar nota en caso de que exista un desacuerdo por parte del área auditada en
relación a alguna de las conclusiones de la auditoría.
Una vez comunicado, explicado y acordado el informe preliminar y tomado nota de las
observaciones o de los eventuales desacuerdos que hubieran podido producirse, el
auditor deberá elaborar el informe final de la auditoría.

Informe final
El informe final de la auditoría contiene el contenido del informe preliminar y además:
» Las observaciones del área auditada.

» Los desacuerdos que pudieran existir por parte del área auditada en relación a las
conclusiones de la auditoría.
El auditor deberá comunicar en tiempo y forma el informe final de la auditoría al Comité

de Dirección de la organización, al área auditada y a cuantas terceras partes se
identifique, según lo definido y acordado en el plan de comunicación asociado a la
auditoría.
El auditor deberá presentar el informe final a la dirección de la organización en una

reunión de presentación del informe y cierre de la auditoría en la que se efectuará el
cierre del proceso de auditoría.
A continuación, se presentan dos aspectos fundamentales que deberá incluir el informe

final de auditoría:
» Historial de versiones: el informe final de auditoría deberá contener información

histórica —quién y cuándo— relacionada con:
o La generación del informe.

o Su revisión.
o Las diferentes versiones.
o Lo que diferencia una versión respecto de la anterior.
» Audiencia: el informe final de auditoría deberá especificar claramente a quién va

destinado; es decir, la audiencia a la que se distribuye.

3.4. Habilidades fundamentales del auditor de Sistemas de

Información
Un auditor en informática debería tener las siguientes habilidades terminales:
» Capacidad para revisar y evaluar el control interno del medio ambiente en que se
desarrollan los sistemas de información.
» Capacidad para revisar, evaluar y diseñar los controles necesarios en el desarrollo de
los sistemas de información.
» Capacidad para revisar y evaluar los controles en sistemas de información que estén
produciendo información.
» Capacidad para diseñar procedimientos y técnicas de auditoría con el computador.
» Capacidad de comunicación y síntesis.
» Capacidad de relación.

Lo + recomendado
No dejes de leer…
Developing a Risk-based audit plan
Este documento presenta los detalles relacionados con la elaboración de un plan de

auditoría basado en la evaluación de riesgos.

http://www.isaca.org/chapters5/Ireland/Documents/2014%20Presentations/The%20
Imperative%20of%20Risk%20Based%20Audit%20Planning.%20A%20Case%20Study
%20from%20a%20Large%20Complex%20Organisation%20-%20Joe%20Ryan.pdf
Guide to the Assessment of IT Risk (GAIT)
Esta guía describe la relación entre los riesgos de negocio y los objetivos de control, así
como, los controles asociados y el assessment de los mismos, así como recursos para el
auditor de Sistemas de Información sobre cómo orientar la auditoría. La Guide to the
Assesment of IT Risk (GAIT) incluye:
» Una metodología de auditoría de sistemas de información basada en evaluación de

riesgos.
» Una metodología para el análisis de riesgos y la selección de los controles de
mitigación asociados.

http://www.theiia.org/guidance/technology/gait/

+ Información
A fondo
The IS Audit process
Este directorio ofrece gran variedad de artículos con todo tipo de información interesante
y numerosos aspectos clave para ahondar en la auditoría de Sistemas de Información.

http://www.isaca.org/knowledge-center/itaf-is-assurance-audit-/pages/is-audit-
basics.aspx
Risk-based auditing
Griffits, P. (2005). Risk-based auditing. England: Gower Publishing.
Este ebook de Phil Griffits desarrolla diferentes aproximaciones para

la gestión de riesgos y los aspectos de planificación de una auditoría
orientada a riesgos.
Accede, parcialmente, al libro desde el aula virtual o a través de la siguiente dirección

web:
https://books.google.es/books?id=C-czZavrSyAC&printsec=frontcover

Risk IT Framework for Management of IT Related Business Risks
Este framework creado por ISACA ofrece una visión completa (end-to-end) de todos los
riesgos relacionados con la IT, y complementa el framework de COBIT, asegurando una
efectiva gestión de los riesgos de IT.
Accede al framework desde el aula virtual o a través de la siguiente dirección web:

http://www.isaca.org/Knowledge-Center/Risk-IT-IT-Risk-Management/Pages/Risk-
IT1.aspx?utm_source=multiple&utm_medium=multiple&utm_content=friendly&utm
_campaign=riskit
Assessing & Managing IT Risk
Presenta una guía de auditoría de sistemas de información basada en la evaluación

de riesgos.
http://www.isaca.org/chapters2/Pittsburgh/events/Documents/Event_Archive_2010
_2011/10OctPresentationHandouts.pdf
ISACA
Página web de la Asociación de Auditoría y Control de Sistemas de Información.

http://www.isaca.org

The Institute of Internal Auditors (IIA)
Esta web del IIA ofrece una serie de guías y recursos de gran utilidad para el futuro auditor.

https://na.theiia.org/standards-guidance/topics/Pages/Guidance-Topics.aspx
Bibliografía
Fernandez, C.M., Piattini, M., Pino, F. (2014). Modelo de madurez de ingeniería del
(2007). Guide to Using International Standards on Auditing in the Audits of Small-and

Medium sized Entities. NY.
Hannan, J. A practical guide to EDP auditing.
ISACA. (2009). Marco para la auditoría de los sistemas de información. ISACA

Capítulo Madrid. (Guías para la realización de auditorías en los sistemas de
información).
Piattini, M., Del Peso, E., Fernández, C.M. (Coautor), (2008). Auditoría de Tecnologías
Weber, R., (1998). EDP Auditing: Conceptual Foundations and Practice. Ed. McGraw
Hill.

Actividades
Trabajo: Realización de un EDR o ROA
Objetivos
Mediante esta actividad se pretende que pongas en práctica las actividades que
constituyen todo el proceso de auditoría de una organización, haciendo foco en la
realización de un EDR o ROA.
Descripción del trabajo
Viento en Popa es una empresa dedicada a la planificación de actividades náuticas así

como a impartir clases teóricas y prácticas de navegación. Ofrece la posibilidad de
obtener la certificación de Patrón de Embarcaciones de Recreo (PER).
Dentro de la estrategia empresarial, se desarrolló como canal de información y venta un

portal web el cual, y de forma somera, consta de dos partes claramente diferenciadas:
» La zona de Administración desde la cual se gestiona la información relativa a cursos

y alumnos.
» La zona de clientes y alumnos donde el usuario tiene acceso a la información de Viento
En Popa referente a actividades y cursos, y acceso a la parte privada de cada uno, con
la posibilidad de realizar exámenes, descargar temarios y documentación, etc.
Con esta información, se trata de que desarrolles los siguientes puntos:
» Planificar y realizar una auditoría basada en riesgos (EDR) del portal web Viento en
Popa.
Para ello se debe comenzar con la identificación de riesgos a partir de los cuales se
establezcan objetivos de control, controles, pruebas de cumplimiento y, si es
necesario, Pruebas Sustantivas.
» Propones la estructura de un informe dirigido a la Dirección de Viento en Popa, con

los resultados de la Auditoría siguiendo las fases explicadas.
TEMA 3 – Actividades 28 © Universidad Internacional de La Rioja (UNIR)

Datos útiles
» Equipo de dos auditores.

» Tiempo estimado del proceso completo 2 meses/hombre.
» La tecnología en la que está desarrollado el portal es Java.
Nota importante
La solución se puede presentar considerando una de las siguientes dos opciones:
» Viento en Popa tiene subcontratado un hosting de los servicios ofrecidos en la web.

» Viento en Popa tiene en sus instalaciones los servidores que dan el servicio ofrecido
en la web.
Se considerarán ejercicios válidos si contestas a todos los apartados razonando

debidamente cada decisión tomada.
Entrega del trabajo
Un documento en formato word con una extensión máxima de 7-8 páginas, fuente
Georgia 11 e interlineado 1,5.

Test
1. En relación a las metodologías de auditoría, podemos afirmar que:

A. Realmente solo existe una y es basada en Riesgos o Risk Oriented Approach.
B. Cada firma (empresa) de auditoría puede desarrollar la suya propia, siendo la
más difundida la basada en riesgos EDR (ROA).
C. La basada en cuestionarios o checklist es utilizada por auditores con experiencia
pues se la envían por correo electrónico al cliente para que la complete.
2. Realizar auditorías informáticas con metodologías evita:

A. Rapidez y uniformidad.
B. Objetividad en los criterios.
C. Dependencia de quién lo realiza y como lo realiza.
D. Consistencia y rigor.
3. Exclusivamente sobre las pruebas de cumplimiento, podemos afirmar que:

A. Nunca son suficientes. Se utilizan para probar parcialmente y verificar el
cumplimiento momentáneo de una técnica de control / controles y reúne
evidencias de auditoría para indicar si un control funciona de forma efectiva y logra
sus objetivos.
B. El diseño de las pruebas de cumplimiento, cuyo fin es el de reunir evidencias de
un funcionamiento efectivo de los controles internos, ha de tener en cuenta si se
ejecutaron los procedimientos previstos, se ejecutaron adecuadamente y si fueron
ejecutados por alguien que cumple con los requisitos de segregación de funciones.
C. Se utilizan cuando las pruebas sustantivas no han satisfecho los objetivos del
auditor y permiten comprobar la fiabilidad y consistencia de los controles
existentes e identificar la magnitud y el impacto de errores e incidencias.
D. La opciones b y c son correctas.

4. Exclusivamente sobre las pruebas de cumplimiento, podemos afirmar que:

A. Reúne evidencias para indicar si un control está implantado, funciona de forma
efectiva y logra sus objetivos.
B. No se utilizan para probar y verificar el cumplimiento de un control.
C. Solo se utilizan cuando las pruebas sustantivas no han satisfecho los objetivos
del auditor.
D. Permiten comprobar la fiabilidad y consistencia de los controles existentes e
identificar la magnitud y el impacto de errores e incidencias.
5. El EDR es una metodología de auditorías de sistemas de información basada en:

A. Amenazas.
B. Vulnerabilidades.
C. Riesgos.
D. Impactos.
6. Los elementos principales de un EDR simplificado o checklist son:

A. Prueba de cumplimiento, SI, NO, N/A, comentario u observaciones del auditor.
B. Pregunta/Prueba, SI, NO, N/A, comentario u observaciones del auditor.
C. Prueba sustantiva, SI, NO, N/A, comentario u observaciones del auditor.
D. Riesgo, objetivo de control, control, prueba de cumplimiento, prueba sustantiva.
7. Una auditoría sorpresiva:

A. La recopilación no se realiza in situ.
B. Previamente se ha enviado una carta que informas que en algún momento se
realizará una auditoría.
C. Debe contemplar los pasos habituales de cualquier auditoría, con la salvedad de
que la información se recopila in situ.
D. Siempre se envía un memorandum.

8. El informe de auditoría:
A. No admite discusión, pues debe ser aclarado todo durante la propia auditoría.
B. Antes del informe final, se distribuye un borrador al que se pueden alegar
aspectos que el auditado no esté de acuerdo.
C. El informe final de auditoría también puede ser discutido con las personas
auditadas y siempre tiene un apartado principal para la dirección de los controles
que se recomienda modificar.
D. A menudo existe un apartado con juicios de valor y un glosario con los nombres
y marcas de los productos.
9. Las pruebas sustantivas:

A. Se realizan cuando la prueba de cumplimiento realizada no cumple la
expectativa o crea duda razonable del funcionamiento del control revisado al
auditor.
B. Se realizan siempre.
C. Son optativas. Se realizan si le apetece al auditor.
10. El informe de auditoría se dirige:

A. En su versión preliminar, a la alta dirección para que evalúe oficiosamente las
debilidades detectadas.
B. A toda la organización, incluidas las áreas no auditadas pues en definitiva deben
estar informados por formar parte de la empresa.
C. Exclusivamente a los técnicos de sistemas, pues su carácter técnico hace que solo
tenga valor para ellos.
D. De forma preliminar a las partes auditadas, y en su forma final a la Alta
Dirección y a las partes auditadas.

Auditoría técnica de seguridad en
sistemas y redes
[4.2] Auditorías técnicas de seguridad. Test de intrusión.

Conceptos previos
[4.3] Auditorías de seguridad en sistemas. Herramientas de

apoyo
[4.4] Auditorías de seguridad en redes. Herramientas de apoyo
TEMA
Esquema
TEMA 4 – Esquema
Auditoría técnica de seguridad
2
Auditoría de Auditoría de
Conceptos
seguridad en seguridad en
previos
sistemas redes

Auditoría de Seguridad
Ideas clave
Para estudiar este tema lee las Ideas clave que encontrarás a continuación. Al
finalizar el tema, tienes que leer el apartado «A fondo» para reforzar los principales
conocimientos desarrollados. Además, tienes que realizar las lecturas recomendadas y
apoyarte en la bibliografía y la webgrafía asociadas al tema. Por último, deberás realizar
el caso práctico que se incluye y que te servirá para repasar los principales contenidos
del tema y adquirir los conceptos clave.
4.2. Auditorías técnicas de seguridad. Test de intrusión.

Conceptos previos
Es importante centrar los conceptos previos

relacionados con la auditoría técnica de seguridad,
el hacking ético y el test de intrusión.
Las auditorías técnicas de seguridad tienen como

objetivo analizar la seguridad implantada
en los sistemas de información de una
organización y sus servicios (web, correo, ftp-
file transfer, etc.), realizando una batería de pruebas planificadas que simulen el
comportamiento de un atacante (hacker).
Por este motivo, habitualmente se manejan indistintamente los conceptos de

hacking ético y auditorías técnicas de seguridad.
Las auditorías técnicas de seguridad engloban muchos tipos de análisis y pruebas (test)
de seguridad, en función de aquella parte de los sistemas de información que en una
empresa se quiera revisar.

El hacking ético utiliza como base para las pruebas de auditoría de seguridad los
métodos, técnicas y ataques usados por hackers de forma ética, controlada y
autorizada.
Un Test de Intrusión (PenTest) es un tipo de auditoría técnica de seguridad,

que puede ser interna (caja blanca) o externa (caja negra):
» Caja blanca, cuando el objetivo es acceder a recursos protegidos de los sistemas

de información de la organización desde el interior de la misma (red local).
Habitualmente se permite al auditor la conexión a la red interna para q u e r e a l i c e
las auditorías y tiene información previa de la organización aportada por el
auditado.
» Caja negra, cuando la finalidad es acceder a los sistemas de información de una
empresa desde el exterior (Internet). El auditor no dispone de información de la
empresa. Solo la existente de forma pública (Internet, prensa, etc.).
Dentro de las auditorías de seguridad de caja blanca, vamos a englobar los dos
primeros apartados que se tratarán en este Tema:
» Auditoría de seguridad en sistemas.

» Auditoría de seguridad en redes.
Dentro de las auditorías de seguridad de caja negra, vamos a englobar los 2 últimos
apartados que se tratarán en el Tema 5:
» Auditoría de seguridad en Internet.

» Auditoría de seguridad en dispositivos móviles.

El siguiente esquema (ilustración 1) resume los conceptos de los temas 4 y 5:
Hacking ético – Auditoría técnica de seguridad
Sistemas
Caja blanca
Redes
Test de intrusión
(PenTest)
Internet
Caja negra
Móviles
Existen diversas metodologías para la realización de auditorías técnicas de seguridad

que analizaremos en el anexo correspondiente.
Es necesario decir que, independientemente de la auditoría a realizar (caja blanca o

negra, sistema o redes e Internet o dispositivos móviles) se seguirán siempre las
siguientes fases:
» La recopilación de información del sistema a auditar y análisis de vulnerabilidades.

» Explotación o ataque de las vulnerabilidades detectadas.
» Realización de informe técnico y ejecutivo.
Existen muchas herramientas (libres o comerciales) en el mercado para UNIX, Linux o

Windows que ayudan a la realización de todas estas fases, o partes de ellas, según se
detalla en el anexo de herramientas.
Existen muchas herramientas en el mercado que realizan análisis de vulnerabilidades

sobre los sistemas y redes detectando vulnerabilidades y determinando el nivel de riesgo
que se corre si no se corrige. En algunos casos, estas herramientas pueden darnos
resultados (findings) erróneos. Podríamos obtener:

» Falsos positivos: se obtienen findings que realmente no existen (por ejemplo,

algunas vulnerabilidades, puertos abiertos, etc.).
» Falsos negativos: no se obtienen findings que realmente existen (por ejemplo,
algunas vulnerabilidades, puertos abiertos, etc.).
A lo largo del tema utilizaremos la siguiente topología de red y sistemas de una

compañía ficticia, centrándonos en Lan Usuarios y Lan Desarrollo:
Topología de red
A continuación, resumiremos algunas herramientas que emplearemos en cada uno de

los tipos de auditoría que desarrollaremos a lo largo del tema.
Auditoría de seguridad de sistemas
» Scanner de puertos: herramientas para detectar el estado de los puertos de una

máquina (y sus servicios) conectada a una red de comunicaciones. Detecta si un
puerto está abierto, cerrado o protegido por un cortafuegos.
» Footprint y Fingerprint: técnicas que permiten, a través de herramientas,
obtener información del sistema como la versión, parches, service pack, etc
(fingerprint) e información de DNS, infraestructura e información pública del
sistema informático de la organización a auditar (footprint).
» Pruebas de Fuerza bruta y Diccionarios: para recuperar una clave probando
todas las combinaciones posibles hasta encontrar aquella que permite el acceso.
Fuerza bruta se basa en todas las combinaciones posibles con un set de caracteres

definido y una longitud. Las técnicas de prueba basadas en diccionario utilizan

como base del ataque un listado de palabras.
Auditoría de seguridad de redes
» Sniffing de paquetes de red: técnica pasiva de interceptación o «escucha» de

información (paquetes de datos en una red inalámbrica o cableada). Se utilizan
herramientas de captura de paquetes de red.
» Man in the middle: técnica de interceptación y modificación de información, que
utiliza herramientas para leer, insertar y modificar los mensajes entre dos partes
sin que ninguna de ellas conozca que el enlace entre ellos ha sido violado.
» ARP Poisoning: técnica que utiliza herramientas para infiltrarse en una red
ethernet conmutada (basada en switches y no en hubs) que puede permitir al
atacante leer paquetes de datos en la Lan (red de área local), modificar el tráfico,
o incluso detenerlo. Un efecto del ARP Poisoning es el de redirigir toda la
información del switch a nuestra máquina.
4.3. Auditoría de seguridad en sistemas. Herramientas de apoyo
El objetivo de la auditoría de seguridad de sistemas es obtener acceso a los recursos de

la organización (sin tener privilegios para ello).
Dentro de sistemas podemos identificar:
» El área de desarrollo con servidores y máquinas de trabajo.

» El área de explotación y producción con servidores y los diferentes usuarios que
utilizan los servicios y aplicaciones de la organización.
Los servidores y estaciones de trabajo, así como los puestos de usuarios están
conectados entre sí por una red local que podrá estar segmentada o no.
Recordemos que la auditoría de sistemas es de caja blanca, al estar conectados al

interior de la red de la organización.
A continuación se describen a alto nivel las fases de auditoría de seguridad técnica de

sistemas:

» Fase 1: Obtención de información
o Servidores y servicios (puertos abiertos).

o Sistemas operativos (fingerprint).
» Fase 2: Ataque en base a la información obtenida (utilización de herramientas).

» Fase 3: Resultados (redacción de informe técnico)
Existen diferentes herramientas para realizar este tipo de auditorías en cada una de las
fases:
» Fase 1: utilizamos la herramienta NMAP, para hacer discover de todas las

máquinas que están en el rango de IP de la red y subred que nos encontremos. Y
sobre cada dirección IP averiguar que puertos (servicios) están abiertos/funcionando
(FTP, POP3, etc.).
Por ejemplo, se lanza nmap (zenmap) con los parámetros correspondientes (ver
anexo tema 5), y se obtiene las máquinas de la red (subred/24). La máquina con
IP 192.168.1.37 tiene por ejemplo el puerto 21 (servicio de ftp) abierto.
Pantalla de zenmap
» Fase 2: utilizamos la herramienta BRUTUS para obtener el acceso a un servidor

concreto a través de un servicio que tenga abierto (FTP, POP3, etc.). Se obtendrá el
login y password. Adicionalmente, conoceremos por fingerprint el sistema operativo,
l o q u e nos ayudará para poder realizar algún ataque a alguna vulnerabilidad.

Por ejemplo, se utilizará la herramienta BRUTUS para realizar un ataque de fuerza

bruta y diccionario sobre el servicio de FTP y obtener las credenciales:
Pantalla de zenmap (vista de sistemas)
Se configura el ataque con diccionarios contra la dirección IP. Se seleccionan los

ficheros de users y words.
Pantalla de Brutus
El resultado es user:admin y pass:nimda. Hemos obtenido acceso al ftp.
Pantalla de Brutus

Se comprueba la conexión a través del navegador:
Pantalla de Brutus
» Fase 3: se realizará el informe técnico donde se describen los pasos realizados y los
resultados (findings) obtenidos. Como hemos visto en la Ilustración 2 (Topología de
Red), podemos centrarnos como objetivo en la red de usuarios o en la de desarrollo.
Es muy habitual que las organizaciones aseguren las redes de usuarios y producción,
pero pasen por alto la securiazación de desarrollo.
Así, es muy usual tener un servidor de control de versiones de código fuente (por
ejemplo SVN–Subversion). Habitualmente el puerto que utilizan es el 3690, por lo
que se podría realizar sobre estos repositorios el análisis descrito en este apartado.
4.4. Auditoría de seguridad en redes. Herramientas de apoyo
A continuación se describen a alto nivel las fases de auditoría de seguridad técnica en

una red local de una organización.
» Fase 1. Obtención de información (direcciones IP de la red). Captura de tráfico de

red.
» Fase 2. Ataque a l información obtenida de la captura de tráfico de red (utilización
de herramientas).
» Fase 3. Resultados (redacción preliminar de informe técnico).
fases:
» Fase 1: mediante la herramienta CAIN&ABEL es posible descubrir todos los equipos

de la red, redirigir toda la información del switch a nuestra máquina (técnica ARP

Poisoning) y capturar la información que se transmite en la red local en la que nos

encontramos.
Por ejemplo, la herramienta CAIN se debe configurar indicando la tarjeta de red a

utilizar:
Pantalla principal de CAIN
Selección de tarjeta de red
En la opción de redes se puede hacer el discover de las máquinas de

su red: 192.168.1.1

Esquema de red
Se debe activar el botón de red para que pueda capturar tráfico (sniffer).
Menús de selección de opciones
Automáticamente aparecerán las máquinas de la red. El router es ip: 192.168.1.1 El

objetivo a «escuchar» es IP: 192.168.1.37.
Nosotros somos la IP: 192.68.1.34
Menús de selección de opciones
» Fase 2: una vez capturado el tráfico, es posible con la herramienta CAIN&ABEL

identificar inicio de sesiones en aplicaciones que por ejemplo estén alojadas en la nube,
o repositorios tipo GIT que requieran de login/password y descifrar su password.

En el ejemplo, se activa el ARP Poisoning, que se basa en el concepto de Man In

The Middle.
Menús de selección de la técnica ARP Poisoning
Todos los paquetes entre la dirección IP del router: 192.168.1.1 y la máquina que
queremos escuchar: 192.168.1.37, pasarán por nosotros. (IP: 192.168.1.34).
Finalmente, podemos acceder a las credenciales de la máquina 192.168.1.37 y

enumerar sus usuarios.

» Fase 3: se realizará el informe técnico donde se describen los pasos realizados y los
resultados (findings) obtenidos.

Lo + recomendado
No dejes de leer…
Hacking Ético
Tori, C. (2008). Hacking ético. Argentina: Autor.
Las 328 páginas del libro abordan el campo de la seguridad

informática con un «lenguaje simple y ordenado».
Accede al libro desde el aula virtual o a través de la siguiente dirección web:

http://www.etnassoft.com/biblioteca/hacking-etico/
ISO 25000
Este estándar de la organización ISO especifica los requisitos de calidad y la evaluación

de calidad del software, si bien su principal objetivo es proporcionar una visión general
de los contenidos, las referencias comunes, los modelos y definiciones de systems and
software Quality Requirements and Evaluation. (SQuarRE).

http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=64
764

ISO 12207
Se trata del estándar para los procesos del ciclo de vida del software de la organización
ISO. Con una terminología muy bien definida, la estructura del estándar ha sido
concebida de manera que pueda ser adaptada a las necesidades de cualquiera que lo use.
Para conseguirlo, el estándar se basa en dos principios fundamentales: modularidad y
responsabilidad.

http://www.iso.org/iso/catalogue_detail?csnumber=43447
Auditing the Software Development Lifecycle ISACA Geek Week
En este artículo se recoge el ciclo de vida de desarrollo de una auditoría de software, si

bien también se abordan, entre otras cuestiones, las metodologías comunes de desarrollo
o las principales consideraciones al respecto.

http://www.isaca.org/chapters3/Atlanta/AboutOurChapter/Documents/GW2014/Aud
iting%20SDLC%20_%20Van%20Stone%20Kamara.pdf

+ Información
A fondo
Desarrollo seguro de aplicaciones para dispositivos móviles
En este artículo se explica por qué la plataforma Android no es totalmente segura, lo que
la ha convertido en una de las más atacadas por los cibercriminales, y proporciona una
serie de consejos para desarrollar aplicaciones que sean más seguras.

https://www.incibe.es/blogs/post/Seguridad/BlogSeguridad/Articulo_y_comentarios
/desarrollo_seguro_de_aplicaciones_para_dispositivos_moviles
¿Cómo se realiza un PenTest?
Un Penetration Testing o Test de Penetración, es un procedimiento metodológico y

sistemático en el que se simula un ataque real a una red o sistema, con el fin de descubrir
y reparar sus problemas de seguridad, a continuación veremos la documentación mas
recomendada para aprender a realizar correctamente un test de penetración. En este
artículo veremos diferentes metodologías para su realización.

http://www.dragonjar.org/como-realizar-un-pentest.xhtml
Test de intrusión
En este artículo encontrarás los pasos para llevar a cabo un test de penetración en una
empresa. Aunque a grandes rasgos los test de penetración son todos similares es cierto
que cada uno tiene su arte y su punto fuerte, y eso es lo que otorga el valor añadido a las
distintas empresas que se dedican a esto.

http://www.elladodelmal.com/2007/02/test-de-intrusion-i-de-vi.html

Cain & Abel
En este caso tocaremos el tema de la recuperación de contraseñas a través del programa

Cain & Abel. Se trata de una herramienta de recuperación de contraseñas para los
sistemas operativos de Microsoft que permite una fácil recuperación.

http://www.oxid.it/cain.html
Auditar el acceso a ficheros en Windows 7 y Windows XP
En el siguiente artículo en línea veremos con detenimiento los pasos a seguir en el

proceso realizado para auditar el acceso a ficheros en Windows 7 y en Windows Xp.

http://blog.elhacker.net/2013/03/auditar-el-acceso-ficheros-carpetas-en-windows-7-
windows-xp.html
Fingerprinting
A través de este sitio web veremos algunas herramientas que nos permitirán realizar un
fingerprint a nuestro wordpress e incluso escanear posibles vulnerabilidades.

http://www.flu-project.com/2012/08/auditando-un-wordpress-parte-vi_26.html

OxWORD
Editorial de libros técnicos de seguridad.

http://0xword.com
OWASP
Comunidad libre y abierta sobre seguridad en aplicaciones.

https://www.owasp.org
OSSTMM
Open Source Security Testing Methodology Manual (OSSTMM).

http://www.isecom.org/research/osstmm.html

FOUNDSTONE (a McAffee division)
McAfee Foundstone es una de las primeras autoridades mundiales en seguridad de la

información.

http://www.foundstone.com/
Bibliografía
Álvarez, G. (2004). Seguridad Informática para empresas y particulares.

McGRawHill
Fernandez, C.M; Piattini, M., Pino, F. (2014). Modelo de madurez de ingeniería del
software. AENOR Ediciones
Gómez, A. ( 2 0 0 6 ) . Enciclopedia de la Seguridad Informática. RA-MA.
Recursos externos
Paros proxy
Paros es una aplicación basada en Java que sirve para evaluar la seguridad de las
aplicaciones web.

https://sourceforge.net/projects/paros/

Java
Java es una tecnología que se usa para el desarrollo de aplicaciones que convierten a la
web en un elemento más interesante y útil. Java no es lo mismo que javascript, que se
trata de una tecnología sencilla que se usa para crear páginas web y solamente se ejecuta
en el explorador.

http://www.java.com/es/

Actividades
Laboratorio #1: Auditoría de aplicaciones web. La importancia

del desarrollo seguro de software en web
Presentación del laboratorio
Para realizar este laboratorio, el primer paso es descargar el proxy web ParosProxy, ya
que esta será la herramienta que utilicemos. La versión necesaria es
«paros3.2.13-win.exe Last Update: 2013-08-14» y habrá que instalarla en el PC con
sistema operativo Windows. Hay que tener acceso a Internet.
Necesitaremos la última máquina virtual de java, que puede instalarse desde la web de
java.com la versión 8 update 73
Es muy importante entender el funcionamiento de un proxyweb (se verá en

clase previo al laboratorio) para poder configurar adecuadamente la herramienta.
Puedes encontrar la información necesaria del recurso en el apartado Recursos Externos

del tema.
Objetivo del laboratorio
El objetivo del laboratorio es la adquisición de las destrezas básicas por parte del alumno
para interceptar y analizar peticiones de cliente web, modificarlas, alterarlas y
determinar si existen errores de programación en la parte del servidor.
Descripción del laboratorio
Este laboratorio nos permitirá conocer los riesgos reales de seguridad asociados al
desarrollo de software (aplicaciones web) y lo que supone no considerar
recomendaciones y buenas prácticas de desarrollo seguro; desde la toma de requisitos
hasta el código fuente en aplicaciones web.

Entrega del laboratorio
Se deberá entregar un documento con dos partes:
» La primera, que contenga una descripción de los pasos realizados con la

herramienta y las conclusiones a las que se han llegado al revisar la aplicación web
propuesta para análisis. (Se indicará en una de las clases virtuales).
» La segunda, el informe automático de vulnerabilidades consecuencia de no aplicar
buenas prácticas de desarrollo seguro. (Este informe deberá ser analizado
previamente por el alumno).

Test
1. Un test de intrusión es:

A. Solo análisis de vulnerabilidades.
B. Un tipo de Hacking ético.
C. Habitualmente de caja blanca y caja negra.
D. No es un PenTest.
2. ¿Qué 3 fases habitualmente se utilizan en una auditoría técnica de seguridad (test

de intrusión)?
A. La recopilación de información del sistema a auditar y análisis de
vulnerabilidades, explotación/ataque de las vulnerabilidades detectadas,
realización de informe técnico y ejecutivo.
B. La recopilación de información del sistema a auditar, explotación/ataque de las
vulnerabilidades detectadas, nunca se realiza informe.
C. Explotación/ataque de las vulnerabilidades detectadas y realización de informe
técnico.
D. La recopilación de información del sistema a auditar y realización de informe
técnico y ejecutivo.
3. Las pruebas de fuerza bruta se basan en:

A. Solo en la utilización de ficheros con palabras en diferentes idiomas para
averiguar por ensayo/error los usuarios y/o password en las pantallas de login.
B. Utilización de todas las combinaciones posibles con un set de caracteres definido
y una longitud.
C. Lo que se denominan Rainbow Tables.
D. Ninguna es cierta.
4. ¿Qué es el sniffing de paquetes de red?:

A. Es la técnica para inyectar paquetes en redes inalámbricas.
B. Es la técnica pasiva que permite la captura de datos (paquetes de datos) que se
distribuyen en una red.
C. Es la técnica por la que se intercepta y modifica la información en una red.
D. Es la técnica por la que consigues el control de administración en las máquinas
servidoras.

5. Con la herramienta NMAP:

A. Hacemos uso de los Google Dorks.
B. Entre otras muchas funciones, obtenemos los servicios/puertos abiertos en una
red local.
C. Obtenemos las claves de cifrado en Wifi.
6. Con la herramienta BRUTUS:

A. Hacemos uso de los Google Dorks.
B. Entre otras muchas funciones, obtenemos los servicios/puertos abiertos en una
red local.
C. Automatiza los ataques de fuerza bruta y ataque basado en diccionario.
7. La herramienta CAIN:
A. Está diseñada para ataques de fuerza bruta.
B. Está diseñada para realizar ARP Poisoning.
C. Está diseñada para realizar sniffing de los paquetes de red.
D. Todas las anteriores son ciertas.
8. Los test de intrusión de caja negra son:

A. Internet y dispositivos móviles.
B. Sistemas y redes.
C. Código fuente en preproducción.
9. Los test de intrusión de caja blanca son:

A. Internet y dispositivos móviles.
B. Sistemas y redes.
C. Código fuente en preproducción.
10. La recopilación de información se realiza:

A. En todas las fases.
B. En la Fase 3.
C. En la Fase 2.
D. En la Fase 1.

Auditoría técnica de seguridad en
Internet y dispositivos móviles
[5.2] Auditoría de seguridad en Internet. Herramientas de apoyo
[5.3] Auditoría de seguridad en dispositivos móviles.

Herramientas de apoyo
[5.4] Anexo 1. Estructura de informe ejecutivo e informe técnico
[5.5] Anexo 2. Inventario de herramientas
[5.6] Anexo 3. Metodologías
TEMA
Esquema
TEMA 5 – Esquema
2
Auditoría de
Auditoría de
seguridad en
seguridad en Anexos
dispositivos
Internet
móviles

Ideas clave
Para estudiar este tema lee las Ideas clave que encontrarás a continuación y que han
sido elaboradas por el profesor. Al finalizar, el tema, debes leer el apartado «a fondo»
para reforzar los principales conocimientos desarrollados. Además, tienes que realizar las
lecturas recomendadas y apoyarte en la bibliografía y la webgrafía asociadas al tema.
Por último, deberás deberá realizar el caso práctico con el objetivo de repasar los
principales contenidos del tema y asegurar la adecuada adquisición de los conceptos
clave.
Es importante recordar los conceptos previos relacionados con la auditoría técnica

de seguridad, el hacking ético y el test de intrusión tratados en el tema 4.
Las auditorías técnicas de seguridad tienen como objetivo analizar la seguridad

implantada en los sistemas de información de una organización y sus servicios (web,
correo, ftp-file transfer, etc.), realizando una batería de pruebas planificadas que
simulen el comportamiento de un atacante (hacker).
Por este motivo habitualmente se manejan indistintamente los conceptos de

hacking ético y auditorías técnicas de seguridad.
Las auditorías técnicas de seguridad engloban muchos tipos de análisis y pruebas (test)
de seguridad, en función de aquella parte de los sistemas de información que en una
empresa se quiera revisar.
El hacking ético utiliza como base para las pruebas de auditoría de seguridad los
métodos, técnicas y ataques utilizados por hackers de forma ética, controlada y
autorizada.

Un Test de Intrusión (PenTest) es un tipo de auditoría técnica de seguridad,

que puede ser interna (caja blanca) o externa (caja negra):
» Caja blanca, cuando el objetivo es acceder a recursos protegidos de los sistemas

de información de la organización desde el interior de la misma (red local).
Habitualmente se permite al auditor la conexión a la red interna para la realización
de las auditorías y tiene información previa de la organización aportada por el
auditado.
» Caja negra, cuando la finalidad es acceder a los sistemas de información de una
empresa desde el exterior (internet). El auditor no dispone de información de la
empresa. Solo la existente de forma pública (internet, prensa, etc.).
Dentro de las auditorías de seguridad de caja blanca, vamos a englobar los dos
primeros apartados tratados en el tema 4:
» Auditoría de seguridad en sistemas.

» Auditoría de seguridad en redes.
Dentro de las auditorías de seguridad de caja negra, vamos a englobar los 2 últimos
apartados tratados en este tema:
» Auditoría de seguridad en Internet.

» Auditoría de seguridad en dispositivos móviles.
Recordemos el siguiente esquema (ilustración 1) resume los conceptos de los temas 4 y

5:
Hacking ético – Auditoría técnica de seguridad
Sistemas
Caja blanca
Redes
Test de intrusión
(PenTest)
Internet
Caja negra
Móviles

Existen diversas metodologías para la realización de auditorías técnicas de seguridad

que analizaremos en el anexo correspondiente.
Auditoría de seguridad en Internet
» Google Dorks: Técnica de utilización de parámetros para dirigir y filtrar búsquedas

en la información indexada de los buscadores. Se puede extraer información diversa,
tal como detalles de configuración de una base de datos, nombres de usuario,
contraseñas, listados de directorios, mensajes de error, etc.
» Directory listing / SQL injection:
o Directory Listing hace referencia a la visualización de la estructura de

directorios de un servidor web o servidor FTP como resultado de una mala
configuración y parametrización del servidor.
o SQL injection es una técnica que, utilizando errores en la programación, inyecta
código SQL dentro del código SQL programado, a fin de alterar el funcionamiento
normal del programa y lograr así que se ejecute la porción de código "inyectado",
en la base de datos.
Auditoría de seguridad en dispositivos móviles
» Conexiones WIFI y seguridad WEP, WPA, WPA2. WEP permite la encriptación de

la información que se transmite en una red WiFi. Su cifrado está basado en el
algoritmo RC4, pudiendo utilizar claves de 64 bits (40 bits más 24 bits del vector
de iniciación IV) o de 128 bits (104 bits más 24 bits del IV). WPA adopta la
autenticación de usuarios mediante el uso de un servidor, donde se almacenan las
credenciales y contraseñas de los usuarios de la red.
Para no obligar al uso de tal servidor para el despliegue de redes, WPA permite la
autenticación mediante una clave pre compartida, que de un modo similar al
WEP, requiere introducir la misma clave en todos los equipos de la red. Tanto la
versión 1 de WPA, como la denominada versión 2, se basan en la transmisión de las
autenticaciones soportadas en el elemento de información correspondiente. En el
caso de WPA 1, en el tag propietario de Microsoft, y en el caso de WPA2 en el tag
estándar 802.11i RSN.

» Tarjeta de red en modo monitor/promiscuo: Herramientas que modifican la

forma de trabajo de una tarjeta de red. Se habla de modo monitor en las tarjetas
de red WI-FI y modo promiscuo en las tarjetas de red cableadas.
5.2. Auditoría de seguridad en Internet. Herramientas de apoyo
Las auditorías web son, quizás, las auditorías de

seguridad más utilizadas.
A continuación, se describen a alto nivel las fases de

auditoría de seguridad técnica para un servidor web
en Internet:
» Fase 1. Obtención de información pública (utilización de herramientas).

» Fase 2. Ataque en base a la información obtenida (utilización de herramientas).
» Fase 3. Resultados (redacción preliminar de informe técnico)
Existen diferentes herramientas, para realizar este tipo de auditorías en cada una de las
fases:
» Fase 1: Mediante el uso de buscadores como Google y operadores específicos

(Google Dorks) es posible obtener información indexada sobre el servidor a auditar.
(ver anexo). Utilizando, en caso de que exista, el fichero robots.txt del servidor web
(obtienes rutas que no se desean indexen los buscadores).
Utilizando la web www.netcraft.com obtienes información del servidor.

Complementando con el uso de la herramienta de fuerza bruta DirBuster es
posible obtener parte del árbol web del servidor.
Por ejemplo, la web a auditar. A través del fichero robots.txt obtenemos la

estructura de directorios que no tiene que indexar un buscador. Este fichero nos
revela información de la estructura de directorios.

Contenido clásico de un fichero robots.txt
A través de netcraft (www.netcraft.com) podemos conocer el estado del

servidor, localización, datos de registro de dominio y webmaster, etc. Esta
información en ocasiones es útil para hacer ataques de ingeniería social
Pantalla de Netcraft
Con la herramienta DirBuster se hace mediante ataque de diccionario el discover de la

estructura de directorios del servidor web.
Pantalla de DirBuster
» Fase 2: Una vez obtenida la información, en algunos casos se podrá realizar:
o Directory Listing. Acceder a los directorios y estructura de carpetas del servidor

web (por ejemplo, si existe una configuración incompleta del servidor).

o SQL Injection. Este ataque consiste en introducir sentencias SQL en los campos
de los formularios de la web, permitiéndole tener acceso a la base de datos desde
su navegador. Si una aplicación web posee este tipo de fallo, el atacante podrá leer,
modificar, eliminar y crear registros de la base de datos, dependiendo de los
privilegios o permisos que posea este usuario. Todo esto es posible debido a una
mala validación o filtrado de las variables que son enviadas al servidor.
En el ejemplo, del resultado obtenido, se puede deducir que utiliza el gestor

WordPress. De igual forma las respuestas HTTP 200 indican que por navegador
se puede acceder a esa carpeta. (Directory Listing).
Ilustración 6. Resultado de las respuestas HTTP en DirBuster
» Fase 3: Se realizará el informe técnico, donde se describen los pasos realizados y

los resultados (findings) obtenidos.
5.3. Auditoría de seguridad en dispositivos móviles.

Herramientas de apoyo
Los dispositivos móviles han tenido una gran extensión en los últimos años.
Los denominados smartphones (teléfonos móviles con sistemas operativos propios

como iOS, Android, etc.) incorporan funciones de conectividad a redes wifi, 3G,
bluetooth, etc., los que les ha vuelto muy vulnerables.
A esto hay que añadirle que habitualmente estos dispositivos no incorporan ningún
antivirus o firewall, en cuyo caso una posible intrusión sería en muchos casos
«invisible».

Existen organizaciones que permiten el acceso a I n ternet a los dispositivos móviles

a través de una red wifi.
Es posible realizar una auditoría de seguridad técnica sobre la conexión wifi y obtener
las credenciales de acceso.
A continuación, se describen a alto nivel las fases de auditoría de seguridad en

dispositivos móviles:
» Fase 1. Obtención de información de la red wifi (SSID, canal, cifrado-

WEP,WPA,WPA2).
» Fase 2. Ataque al cifrado de la red wifi (utilización de herramientas) y captura de
tráfico de los dispositivos móviles conectados a la red.
» Fase 3. Resultados (redacción preliminar de informe técnico).
fases:
» Fase 1: Mediante la herramienta de conexión de red (wicd) de la distribución de

LINUX-WIFISLAX es posible descubrir la redes WI-FI cercanas.
Por ejemplo, con la herramienta Gestor de Red Wicd comprobamos la redes wifi
que existen
Pantalla de configuración de wicd en Linux
» Fase 2: mediante la aplicación wifite2 se obtiene la clave de acceso a la wifi de forma

automática. Una vez obtenido el acceso se podrán obtener las direcciones de todos
los dispositivos móviles conectados a la red mediante wifi.

Por ejemplo, la herramienta Wifite2 se lanza para averiguar qué redes son más
vulnerables.
Pantallas de salida de Wifite2 en Linux
Se obtiene la lista y la más vulnerable es la que nos marca todo en verde. Se selecciona
y se lanza automáticamente una serie de baterías de ataque para obtener las claves
WIFI
Pantallas de salida de Wifite2 en Linux
Una vez con la clave wifi obtenida, ya tienes acceso a la red a través del router wifi. En
este punto CAIN podrá hacer un descubrimiento de la red y comenzar a capturar el
tráfico de dispositivos móviles conectados.
Pantallas de salida de Wifite2 en Linux y CAIN en Windows

» Fase 3: Se realizará el informe técnico, donde se describen los pasos realizados y

los resultados (findings) obtenidos.
5.4. Anexo 1. Estructura de informe ejecutivo e informe técnico
Las siguientes estructuras de informe son completamente diferentes a las utilizadas en

los informes de auditoría de sistemas de información explicadas en el tema 3. A
continuación, se muestra un formato posible de informe ejecutivo:
INTRODUCCIÓN
OBJETIVO Y ALCANCE
TIPO DE AUDITORÍA
CONCLUSIONES Y RECOMENDACIONES
ANEXO. Informe técnico
A continuación, se muestra un formato posible de informe técnico:
INTRODUCCIÓN
OBJETIVO Y ALCANCE
TIPO DE AUDITORÍA
FASE 1: obtención de la información
FASE 2: herramientas y pruebas realizadas
FASE 3: resultados obtenidos, evidencias y recomendaciones

5.5. Anexo 2. Inventario de herramientas
Existen muchas herramientas para realizar las diferentes pruebas y que ayudan a
realizar las auditorías técnicas.
En www.sectools.org están clasificadas todas las herramientas de apoyo para la

realización de las auditorías técnicas de seguridad.
Auditoría de Seguridad en Internet:
» Google.com.
» Netcraft.com.
» DirBuster (www.owasp.org)
Auditoría de seguridad en dispositivos móviles.
Distribución de LINUX – WIFISLAX (herramienta Wifite2-www.wifislax.com)
5.6. Anexo 3. Metodologías
OSSTMM
El Manual de la Metodología Abierta de Comprobación de la Seguridad es uno de los

estándares de facto más utilizado en Auditorías de Seguridad para revisar la Seguridad
de los Sistemas desde Internet. Incluye un marco de trabajo que describe las fases que
habría que realizar para la ejecución de la auditoría. Se encuentra en constante
evolución y se compone de las siguientes fases:
» Seguridad de la Información.
» Seguridad de los Procesos.
» Seguridad en las tecnologías de
Internet Seguridad en las
Comunicaciones Seguridad
Inalámbrica.
» Seguridad Física.

OWASP
Es un proyecto creado por una organización

independiente dedicada a detectar y remediar las
vulnerabilidades causadas por el software inseguro.
Organizado en proyectos y capítulos locales y repartidos por todo el mundo, se

desarrollan documentaciones, herramientas y estándares de fuentes abiertas (GPL,
GFDL, LGPL). Cualquier persona y/o patrocinador puede participar. Pretende que se
desarrolle el mejor software mediante:
Pretende que se desarrolle mejor software mediante:
» El desarrollo de herramientas útiles para identificar los fallos y corregirlos.

» La educación de los grupos involucrados, para evitar que se produzcan fallos.
» La definición de estándares.
» El fomento de la discusión de problemas a través de una comunidad abierta.
Es muy importante para el desarrollo de aplicaciones, y concretamente para el

desarrollo de aplicaciones para móviles (las conocidas apps) considerar las
recomendaciones de OWASP Mobile Security Project referentes a aplicaciones para
móviles.
Pendiente de actualizar por la comunidad OWASP para 2015, se incluye el top ten en
2014 de los riesgos para las aplicaciones móviles es:
» R1–Debilidad de los controles del lado del servidor.

» R2–Almacenamiento inseguro de datos.
» R3–Protección insuficiente en la capa de transporte.
» R4–Fuga de datos no intencionada.
» R5–Pobre autorización y autenticación.
» R6–Criptografía rota.
» R7–Inyección del lado del cliente.
» R8–Decisiones de Seguridad a través de entradas no confiables.
» R9–Manejo de sesión incorrecto.
» R10–Falta de protección a nivel binario.

Para ello, OWASP propone una serie de controles de seguridad que, adecuadamente
implantados, permiten minimizar los 10 riesgos anteriores:
» C1–Identificar y proteger los datos sensibles.

» C2–Manejar de forma segura las credenciales del usuario.
» C3–Asegurar que los datos sensibles son protegidos al transmitirlos.
» C4–Implementar de forma correcta la autorización, autenticación y manejo de
sesiones.
» C5–Mantener la seguridad en el backend.
» C6-Integración de datos segura con otros servicios y aplicaciones.
» C7–Prestar atención específica a la recogida y utilización de la información de los
usuarios.
» C8–Implementar controles para prevenir el acceso no autorizado a los recursos de
pago.
» C9–Asegurar la distribución segura y el suministro de las aplicaciones móviles.
» C10–Revisar debidamente cualquier código de error en ejecución.

Lo + recomendado
No dejes de leer…
Hacking Ético
Tori, C. (2008). Hacking ético. Argentina: Autor.
Las 328 páginas del libro abordan en profundidad todas las

cuestiones tratadas en los temas 4 y 5.
Accede al libro desde el aula virtual o a través de la siguiente dirección web:

http://www.etnassoft.com/biblioteca/hacking-etico/
La biblia del Footprinting
Calles García, J.A., y González Pérez, P. (Flu Project) (2011). La biblia del Footprinting.
Este documento presenta los detalles de cómo empezar a auditar

páginas web.

https://radiosyculturalibre.com.ar/biblioteca/INFOSEC/La_Biblia_del_Footprinting.pdf

ISO 25000
Este estándar de la organización ISO especifica los requisitos de calidad y la evaluación

de calidad del software, si bien su principal objetivo es proporcionar una visión general
de los contenidos, las referencias comunes, los modelos y definiciones de systems and
software Quality Requirements and Evaluation. (SQuarRE).

http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=64
764
ISO 12207
Se trata del estándar para los procesos del ciclo de vida del software de la organización
ISO. Con una terminología muy bien definida, la estructura del estándar ha sido
concebida de manera que pueda ser adaptada a las necesidades de cualquiera que lo use.
Para conseguirlo, el estándar se basa en dos principios fundamentales: modularidad y
responsabilidad.

http://www.iso.org/iso/catalogue_detail?csnumber=43447
Auditing the Software Development Lifecycle ISACA Geek Week
En este artículo se recoge el ciclo de vida de desarrollo de una auditoría de software, si

bien también se abordan, entre otras cuestiones, las metodologías comunes de desarrollo
o las principales consideraciones al respecto.

http://www.isaca.org/chapters3/Atlanta/AboutOurChapter/Documents/GW2014/Aud
iting%20SDLC%20_%20Van%20Stone%20Kamara.pdf

+ Información
A fondo
Desarrollo seguro de aplicaciones para dispositivos móviles
En este artículo se explica por qué la plataforma Android no es totalmente segura, lo que
la ha convertido en una de las más atacadas por los cibercriminales, y proporciona una
serie de consejos para desarrollar aplicaciones que sean más seguras.

https://www.incibe.es/blogs/post/Seguridad/BlogSeguridad/Articulo_y_comentarios
/desarrollo_seguro_de_aplicaciones_para_dispositivos_moviles
Monográfico: Zenmap
En este artículo encontrarás una descripción de Nmap que ha sido diseñada para
permitir a administradores de sistemas y a usuarios curiosos en general, explorar y
realizar auditorías de seguridad de redes para determinar qué servidores se encuentran
activos y qué servicios ofrecen.

http://recursostic.educacion.es/observatorio/web/es/software/software-
general/1050-zenmap?start=1

¿Cómo se realiza un PenTest?
Un Penetration Testing o Test de Penetración, es un procedimiento metodológico y

sistemático en el que se simula un ataque real a una red o sistema, con el fin de descubrir
y reparar sus problemas de seguridad, a continuación veremos la documentación mas
recomendada para aprender a realizar correctamente un test de penetración. En este
artículo veremos diferentes metodologías para su realización.

http://www.dragonjar.org/como-realizar-un-pentest.xhtml
Test de intrusión
En este artículo encontrarás los pasos para llevar a cabo un test de penetración en una
empresa. Aunque a grandes rasgos los tests de penetración son todos similares es cierto
que cada uno tiene su arte y su punto fuerte, y eso es lo que otorga el valor añadido a las
distintas empresas que se dedican a esto.

http://www.elladodelmal.com/2007/02/test-de-intrusion-i-de-vi.html
Cain & Abel
En este caso tocaremos el tema de la recuperación de contraseñas a través del programa

Cain & Abel. Se trata de una herramienta de recuperación de contraseñas para los
sistemas operativos de Microsoft que permite una fácil recuperación.

http://www.oxid.it/cain.html

Auditar el acceso a ficheros en Windows 7 y Windows XP
En el siguiente artículo en línea veremos con detenimiento los pasos a seguir en el

proceso realizado para auditar el acceso a ficheros en Windows 7 y en Windows Xp.

http://blog.elhacker.net/2013/03/auditar-el-acceso-ficheros-carpetas-en-windows-7-
windows-xp.html
Fingerprinting
A través de este sitio web veremos algunas herramientas que nos permitirán realizar un
fingerprint a nuestro wordpress e incluso escanear posibles vulnerabilidades.

http://www.flu-project.com/2012/08/auditando-un-wordpress-parte-vi_26.html
OxWORD
Editorial de libros técnicos de seguridad.

http://0xword.com

OWASP
Comunidad libre y abierta sobre seguridad en aplicaciones.

https://www.owasp.org
OSSTMM
Open Source Security Testing Methodology Manual (OSSTMM).

http://www.isecom.org/research/osstmm.html

FOUNDSTONE (a McAffee division)
McAfee Foundstone es una de las primeras autoridades mundiales en seguridad de la

información.

http://www.foundstone.com/
Bibliografía
Álvarez, G. (2004). Seguridad Informática para empresas y particulares.

McGrawHill.
Fernandez, C.M; Piattini, M., Pino, F. (2014). Modelo de madurez de ingeniería del
Gómez, A. ( 2 0 0 6 ) . Enciclopedia de la Seguridad Informática. RA-MA.

Test
1. ¿Por qué sucede en algunos casos el llamado Directory Listing?

A. Como consecuencia del uso de herramientas de sniffing de red.
B. Como resultado de la utilización de inyección de paquetes en redes wifi.
C. Como resultado de una inadecuada configuración y parametrización de un
servidor web o servidor FTP.
D. Como consecuencia del uso del cifrado WPA.
2. La herramienta OWASP DirBuster:

A. Es una herramienta diseñada para obtener por fuerza bruta o diccionario los
nombres de directorios y archivos en servidores web.
B. Es una herramienta para obtener las claves WPA2 de un router inalámbrico.
C. Permite realizar sniffing de red.
D. Está diseñada para realizar ARP Poisoning.
3. Con el fichero robots.txt conseguimos:

A. Averiguar parte de la estructura de carpetas de una web.
B. Actualmente no se utiliza. Fue un fichero muy utilizado entre 1997 y 2001.
C. Esté bien o mal estructurado el fichero, los buscadores tipo google, bing, etc.
nunca indexarán los path a carpetas que contenga el fichero.
D. Que el servidor web aplique reglas de seguridad sobre esas carpetas.
4. Los informes de auditorías técnicas de seguridad:

A. Incluyen como anexo el informe ejecutivo.
B. Nunca describen con detalle técnico las fases de la auditoría de seguridad que
realizan.
C. No necesitan definir el objetivo y el alcance de la auditoría.

5. Para evitar inyecciones de SQL (SQL injection–SQLi) se recomienda:

A. Utilizar frameworks de desarrollo seguro muy sofisticados y de alto coste
económico.
B. Utilizar, entre otras recomendaciones, validación de parámetros en frontend y
en backend (cliente web por ejemplo y en procedimientos almacenados de SQL en
servidor dde BBDD).
C. Configurar adecuadamente el fichero robots.txt.
6. ¿Quién propone anualmente el Top Ten de riesgos en desarrollo de aplicaciones?

A. ISACA.
B. NIST.
C. OWASP.
7. Principalmente, si sobre una aplicación se puede realizar SQL Injection se debe a:

A. Mala configuración de robots.txt.
B. Mala configuración de Subversion.
C. No se han tomado al menos medidas de validación de datos de entrada en cliente
y en servidor.
D. Mala configuración del servidor de aplicaciones.
8. Principalmente, si en un portal web somos capaces de ver su estructura de directorios,

esto se debe a:
A. No se realiza en javascript validación de datos de entrada.

B. Una mala configuración del servidor web que permite esta acción.
C. Una mala configuración en la subversión (control de versiones).
9. En webs tipo www.netcraft.com, la información que nos muestra:

A. Es la misma que en el fichero robots.txt.
B. Es la misma que obtenemos al realizar un ataque de fuerza bruta en una web.
C. Información acerca del cifrado de WPA.
D. Es similar a los servicios whois de Internet.

10. El cifrado WEP para redes wifi:

A. Es el más débil. Debe aplicarse al menos WPA2.
B. Es el más robusto, incluso más que WPA2.
C. Es idéntico a WPA.

Sistema de gestión de seguridad de la
información
[6.2] Seguridad de los SI: propiedades y factores de influencia
[6.3] Riesgos empresariales y gestión de riesgos: implantación de

controles
[6.4] SG de la Seguridad de la Información (SGSI): concepto y

factores críticos para el éxito
[6.5] SGSI-Modelo PDCA
[6.6] SGSI ISO-IEC 27001: contexto de la organización
[6.7] Apartado 4. Contexto de la organización
[6.8] Apartado 5. Liderazgo
[6.9] Apartado 6. Planificación
[6.10] Apartado 7. Soporte
[6.11] Apartado 8. Operación
[6.12] Apartado 9. Evaluación del desempeño

TEMA
[6.13] Apartado 10. Mejora
[6.14] Anexo a ISO 27001/ISO-IEC 27002:

objetivos y controles
[6.15] Auditoría del SGSI

Sistema de Gestión de Seguridad de la Información (SGSI)
Esquema
TEMA 6 – Esquema
Seguridad de Riesgos Anexo A: objetivos de Auditoría
SGSI Apartados
los SI empresariales control y controles del SGSI
Concepto 4. Contexto de la organización
2
Factores 5. Liderazgo
Objeto 6. Planificación
PDCA 7. Soporte
8. Operación
9. Evaluación del desempeño
10. Mejora

Ideas clave
Para estudiar este tema lee los apuntes que constituyen las Ideas clave, elaboradas
por el profesor, sobre «Sistema de Gestión de Seguridad de la Información».
Al finalizar el tema, tienes que leer el apartado «a fondo» para reforzar los principales
conocimientos desarrollados. Además, tienes que realizar las lecturas recomendadas y
apoyarte en la bibliografía y la webgrafía asociadas al tema.
Este capítulo de la asignatura no pretende entrar en el desarrollo de cada uno de los

apartados del estándar ya que ese cometido sería el contenido de una asignatura
completa de master, sino dar una visión global del estándar y de alguno de sus principales
aspectos, facultando al alumno a un estudio más detallado a través de la lectura del
estándar o de la documentación indicada en la bibliografía.
6.2. Seguridad de los SI: propiedades y factores de influencia
La información es el oxígeno de una organización, de manera que el resto de músculos

organizativos la requieren para desempeñar su función y que el organismo corporativo
se oriente a la consecución de los objetivos del negocio.
Como vimos en los anteriores temas, un activo, en su concepción más amplia, puede ser
un fichero informático, un dispositivo electrónico, pero también lo son las personas, las
ubicaciones, los servicios de información, la documentación en papel, es decir «lo que
tiene valor para la organización».
De manera que, para conducir y operar exitosamente una organización, se requiere que:
» Se salvaguarden los activos.

» Se mantenga la integridad de los datos e infraestructura.
» Se suministre información relevante y fiable.
» Se trabaje de forma eficiente.

La organización debe tener dispuestos controles internos que aporten garantía razonable
de que los objetivos de negocio se alcanzan.
La siguiente figura muestra las tres dimensiones principales asociadas a la información:
Dimensiones de seguridad de la información
La Gestión de la Seguridad de la Información es la preservación de la disponibilidad,

confidencialidad e integridad de la información que, digámoslo así, garantiza que el
oxígeno organizativo llegue cuándo, cómo y en la forma en que lo requiere cada músculo
organizativo.
Algunos de los factores que influyen en la seguridad de los Sistemas de Información son:
» Obsolescencia tecnológica.
» Interconectividad de los sistemas. Sistemas abiertos y distribuidos.
» Cambios muy rápidos en las TICs.
» Ataques a Organizaciones.
» Factores externos: Legislación, etc.
6.3. Riesgos empresariales y gestión de riesgos: implantación de

controles
Los principales resultados de la encuesta a nivel mundial (60 entrevistas a senior

executives en USA, Francia, Alemania, Italia, Japón y Reino Unido. Dic-2013) del World
Economic Forums Annual–DAVOS meeting indican que:

» El riesgo de los Ordenadores y las TICs ocupa el primer lugar en 3 países (Japón,
Reino Unido y USA) y en el top three de los otros países, para sus negocios.
» Como herramienta primordial para mitigar estos riesgos de SI indican el Control
Interno Informático.
Es decir, el análisis del riesgo y la implantación de controles son la herramienta

primordiales para la mitigación o transferencia del riesgo a los niveles que la
organización considera admisibles.
El riesgo siempre existe, como podemos observar en un estudio realizado por Mcafee:
» Uno de cada 5 empleados deja a su familia y amigos usar sus portátiles corporativos
para acceder a Internet. (21 %).
» Uno de cada diez confiesa que baja algún tipo de contenido que no debiera mientras
está en el trabajo.
» Dos tercios admiten tener conocimientos muy limitados en materia de seguridad.
» Un 5 % dice que tienen acceso a áreas de la red corporativa que no deberían tener.
De manera que la piedra angular de un Sistema de Gestión de la Seguridad es el análisis

y gestión de los riesgos basado en los procesos de negocio y servicios de TI:
Procesos de Negocio / Servicios de TI
Activos de SI Análisis y Gestión de riesgos Riesgo Residual
- Sistemas de información R=F(X1,X2,X3,Xn) Activo1-------------R´1

(Base de Datos) - Integridad (X1)
- Software (aplicativos, etc.) - Confidencialidad (X2) Activo2-------------R´2
- Hardware - Disponibilidad (X3)
- Telecomunicaciones - Amenazas (X4) Aplicando
- Personas - Vulnerabilidades (X5) ISO/IEC 27002
- Impacto Económico (x6) (Selección de Controles)
- XN
Análisis y gestión de riesgos
Del análisis de riesgos se derivarán los controles que la organización ha de poner en

marcha para llevar el nivel de riesgo al umbral aceptable.

6.4. SG de la Seguridad de la Información (SGSI): concepto y

factores críticos para el éxito
Podríamos decir que un Sistema de Gestión de la Seguridad de la Información es un

marco de trabajo compuesto de documentación, personas y controles en un proceso
constante de mejora continua, cuyo objetivo es la preservación de la confidencialidad,
integridad y disponibilidad de la información a través de la implantación, seguimiento,
auditoría y mejora de controles.
En algunos casos, las organizaciones ya tienen en marcha sistemas de gestión de la

calidad (ISO9001), medioambientales (ISO14001) y de calidad de servicios (ISO20000),
llegando incluso a integrarlos en un Sistema de Gestión global, por lo que podríamos
decir que un SGSI es:
» Aquella parte del sistema general de gestión que comprende la política, la estructura
organizativa, los procedimientos, los procesos, y los recursos necesarios para
implantar la gestión de la seguridad de la información.
» La herramienta de que dispone la Dirección para implantar las políticas y objetivos de
Seguridad de la Información.
Un SGSI permite establecer y reordenar la seguridad de los sistemas de información en

concordancia con los Planes Estratégicos de la Organización y con sus Políticas de
Seguridad.
De manera que el SGSI viene a ser el modelo para la definición, implementación,

operación, revisión, mantenimiento y mejora del SG de la SI, si bien seguirá las pautas
de la ISO 9001/14001 y tendrá un enfoque orientado a procesos y a la mejora continua.
Los principales factores del éxito de un SGSI son:
» El diseño e implementación de una seguridad orientada al negocio.

» Implementar la seguridad en consonancia con la cultura de la empresa.
» Apoyo visible y compromiso de la Dirección.
» Buen entendimiento de los requisitos de seguridad, de la evaluación y gestión de
los riesgos.
» Convencer de la necesidad de la seguridad a directivos y empleados.
» Proveer formación y guías sobre políticas y normas a toda la organización.

» Un sistema de medición para evaluar el rendimiento de la gestión de la seguridad

y sugerir mejoras.
6.5. SGSI-Modelo PDCA
El SGSI es un Sistema de Gestión orientado a procesos y basado en la mejora continua,

modelo PDCA, Demming:
PDCA–Mejora continua.
Fuente: Aenor
La organización deberá planificar el SGSI a través de la definición de la política de

seguridad organizativa, la delimitación del alcance del SGSI, la definición del umbral de
riesgo aceptable, la realización del Análisis de Riesgo (AR) y la selección de los controles
a aplicar (Declaración de aplicabilidad).
A continuación, la organización deberá implantar los controles incluidos en la

declaración de aplicabilidad, poniendo en marcha las medidas técnicas, organizativas o
humanas necesarias.
Asimismo, la organización deberá revisar no solo la eficacia y eficiencia de cada control,

sino también la mejora continua del propio SGSI.

Por último, la organización deberá poner en marcha las acciones preventivas y

correctivas encaminadas a la mejora del SGSI, dando lugar a una nueva iteración del
círculo virtuoso de mejora continua.
6.6. SGSI ISO/IEC 27001: objetivo y alcance
La norma ISO/IEC 27001 especifica los requisitos para establecer, implantar,

documentar y evaluar un SGSI.
Esta norma especifica los requisitos de los controles de seguridad de acuerdo con las
necesidades de las organizaciones e independientemente de su tipo, tamaño o área de
actividad.
La norma se estructura en una serie de capítulos, algunos de los cuales cubren aspectos
comunes de todo sistema de gestión, como el compromiso de la dirección, los requisitos
generales y de la documentación y aspectos relacionados con la revisión y auditoría
interna del sistema y la mejora continua. La mejora continua es un motor común a los
sistemas de gestión de calidad, continuidad, etc.
Es importante destacar que existe una familia de estándares ISO 27000 de los que
destacaremos:
» ISO 27001: especificaciones del SGSI y mejora continua (es el motor del SGSI).
» ISO 27002: los controles del SGSI (es el conocimiento).
La versión de UNE-ISO/IEC 27001:2014 (ISO/IEC 27001:2013) tiene como

principales características:
» Reestructuración del estándar con Anexo SL.

» No se habla directamente de PDCA, sino de Mejora Continua.
» Mayor conocimiento del contexto de la organización y de las necesidades de las partes
interesadas
» Proceso de análisis de riesgos más general y alineado a ISO 31000.
» No se habla de la relación: Riesgos  activos  amenazas  vulnerabilidades.
» Se habla de propietario del riesgo.
» Mayor importancia al liderazgo y compromiso de la Dirección.

» Mayor relevancia a la definición de Objetivos de Seguridad.

» Mayor relevancia a la medición y monitorización. (PDCA, grupos de controles y PTR-
Plan de Tratamiento de Riesgos).
» No hay una lista de documentos obligatorios y no se distinguen documentos y
registros. Se generaliza como «información documentada».
» Revisión por Dirección no exhaustiva.
» No existen las acciones preventivas (se consideran acciones derivadas de la gestión de
riesgos) y solo existen acciones correctivas
6.7. Apartado 4. Contexto de la organización
El apartado 4 del estándar ISO/IEC 27001 define una serie de especificaciones generales
del SGSI como:
» 4.1. Entendimiento de la organización y su contexto.

» 4.2. Entendimiento de las necesidades y expectativas de las partes interesadas.
» 4.3. Determinación del campo de aplicación del Sistema de Gestión de Seguridad de
la Información.
» 4.4. Sistema de Gestión de Seguridad de la Información.
De forma general, en el apartado 4 se consideran todos los aspectos que afecten al

cumplimiento de objetivos del SGSI de forma interna y externa, así como los intereses
de los stakeholders.
6.8. Apartado 5. Responsabilidad de la Dirección
El apartado 5 del estándar ISO/IEC 27001 define una serie de subapartados:
» 5.1. Liderazgo y compromiso.

» 5.2. Política.
» 5.3. Funciones, responsabilidades y autoridad de la organización.
De forma general en el apartado 5.

» Formulación de la política de SGSI (C, I, D y cumplimiento legal).

» Establecimiento de objetivos, planes, roles y responsabilidades en SGSI.
» Comunicación de la importancia de cumplir política SGSI y responsabilidad legal.
» Decide acerca de los niveles y aceptación de riesgos (Análisis de riesgos).
» Proporciona recursos.
» Impulsa la realización de auditorías internas como compromiso de la organización
con el sistema de gestión.
» Dirige la revisión por dirección del SGSI.
6.9. Apartado 6. Planificación
» 6.1. Acciones para cubrir riesgos y oportunidades.

o 6.1.1. Generalidades.
o 6.1.2. Evaluación de riesgos en seguridad de la información.
o 6.1.3. Tratamiento del riesgo en seguridad de la información.
» 6.2. Objetivos de seguridad de la información y planes para conseguirlos.
De forma general en el apartado 6, asociado al «PLAN» de un PDCA:
» Definir alcance.
» Definir la política de SGSI (C, I, D y cumplimiento legal).
» Identificación, análisis y gestión de riesgos (Apreciación de riesgos).
» Selección de controles para tratar los riesgos (ISO 27002 / Anexo A. ISO 27001).
» Elaboración de la Declaración de Aplicabilidad (SoA).
6.10. Apartado 7. Apoyo
» 7.1. Recursos.
» 7.2. Competencia.

» 7.3. Concienciación.
» 7.4. Comunicación.
De forma general, un SGSI se apoya en recursos, competencia, concienciación y

comunicación:
» Realizar acciones de concienciación en seguridad de la información al personal de la

organización.
» Determinar competencias, experiencia de responsable SGSI, Auditor interno, etc.
» Impartir formación u otras acciones para los participantes en el SGSI.
» Llevar acabo comunicaciones adecuadas: quién, cómo, cuándo, etc. (por ejemplo, ante
incidentes de seguridad).
Un SGSI tiene documentado habitualmente:
» Política y los objetivos del SGSI.

» Alcance del SGSI.
» Objetivos de Seguridad.
» Procedimientos y mecanismos de control que soportan al SGSI (PDCA y controles).
» Descripción de la metodología de evaluación de riesgos.
» Informe de análisis de riesgos.
» Documento de aplicabilidad (Aplica / no aplica / motivos)
» Plan de tratamiento de Riesgos.
» Perfiles del responsable de SGSI y del auditor interno (formación, experiencia, etc.).
La siguiente ilustración muestra la documentación que la organización debe definir,

aprobar, implantar y mejorar y que incluye la política o manual de seguridad, los
procedimientos o procesos asociados a cada uno de los controles del SGSI, así como las
instrucciones de trabajo relacionadas y, por último, los registros o evidencia de
cumplimiento de cada uno de esos controles.
Recordemos lo indicado a lo largo de la asignatura al respecto de la diferencia entre

documentación (declaración de intenciones) y registro (prueba de cumplimiento de lo
definido en la documentación).

Documentación del SGSI
6.11. Apartado 8. Operación
» 8.1. Planificación y control operacional.

» 8.2. Evaluación de riesgos de seguridad de la información.
» 8.3. Tratamiento del riesgo de seguridad de la información.
De forma general, un SGSI asociado al «DO» de un PDCA:
» Implantar los controles seleccionados/plan tratamiento del riesgo.

» Implementar procedimientos.
» Implantar programas de formación y concienciación.
» Definir cómo medir eficacia (indicadores y métricas) de controles/ rupos de controles.
También para el PDCA. También para el Plan de Tratamiento del Riesgo.
6.12. Apartado 9. Evaluación del desempeño
» 9.1. Supervisión, medición, análisis y evaluación.

» 9.2. Auditoría Interna.

» 9.3. Revisión por la Dirección.
De forma general, un SGSI se asocia al CHECK del PDCA:
Evaluación de la eficacia (Supervisión, medición, análisis, evaluación) del

SGSI (PDCA, controles):
» Revisión de objetivos de seguridad.

» Revisión de indicadores (valor objetivo) y métrica (medición).
» Ejecutar procedimientos de supervisión, revisión y mecanismos de control.
» Medir eficacia de controles / grupos de controles.
» Realizar revisiones periódicas del funcionamiento del SGSI.
» Registro de incidentes de seguridad.
» Revisar el análisis de riesgos, riesgos aceptables y riesgos residuales.
Auditoría interna. Independencia del auditor.
» PDCA (ISO 27001-motor) y controles Anexo A. ISO 27001 /ISO 27002 –

conocimiento-controles).
Revisión por la Dirección
Consideraciones:
» Resultados de auditorías y revisiones previas.

» Técnicas, productos, procedimientos a utilizar para mejorar.
» Estado de acciones preventivas/correctivas.
» Vulnerabilidades y amenazas no tratadas actualmente.
» ……
» Mejora de la eficacia del SGSI.
» Actualización del análisis de riesgos y plan de tratamiento del riesgo.
» Modificación de procedimientos/controles.
» Necesidad de recursos.
» …..

6.13. Apartado 10. Mejora
El apartado 10 del estándar ISO/IEC 27001 define una serie de sub apartados:
» 10.1 No conformidad y acción correctiva.

» 10.2 Mejora continua.
De forma general, un SGSI se asocia al «ACT» del PDCA:
» La organización debe mejorar de manera continua la idoneidad, la adecuación y la

eficacia del SGSI.
» Análisis de causa, acción correctiva, responsables, fecha límite, etc.
6.14. SGSI-Anexo a ISO 27001/ISO-IEC 27002: objetivos y

controles
El anexo A del estandar ISO/IEC 27001 enumera 114 controles organizados en

14 áreas o dominios de control, cada una de las cuales cubre algunos de los 35
objetivos de control del estandar.
Para cada objetivo de control se definen uno o más controles de seguridad cuya
implantación debe traducirse en la consecución del objetivo de seguridad asociado.
ISO 27002-Versión 2013
14 Dominios
35 Objetivos
control
114 Controles
Dominios, objetivos de control, controles

No es objetivo de esta asignatura detallar cada uno de los 114 controles de la ISO/IEC
27002 que la ISO/IEC 27001 enumera en su Anexo A, si bien el alumno podrá
profundizar en cualquiera de ellos a través del estándar y en las clases se tratará con
mayor detalle.
A continuación, se muestra la relación de los 14 Dominios y 35 Objetivos de control:
» A.5. Políticas de seguridad de la información.

o A.5.1 Directrices de gestión de la seguridad de la información.
» A.6. Organización de la seguridad de la información.

o A.6.1. Organización interna.
o A.6.2. Los dispositivos móviles y el teletrabajo.
» A.7. Seguridad relativa a los recursos humanos.

o A.7.1. Antes del empleo.
o A.7.2. Durante el empleo.
o A.7.3. Finalización del empleo o cambio en el puesto de trabajo.
» A.8. Gestión de activos.

o A.8.1. Responsabilidad sobre los activos.
o A.8.2. Clasificación de la información.
o A.8.3. Manipulación de los soportes.
» A.9. Control de acceso.

o A.9.1. Requisitos de negocio para el control de acceso.
o A.9.2. Gestión de acceso de usuario.
o A.9.3. Responsabilidades del usuario.
o A.9.4. Control de acceso a sistemas y aplicaciones.
» A.10. Criptografía.
o A.10.1. Controles criptográficos.
» A.11. Seguridad física y del entorno.

o A.11.1. Áreas seguras.
o A.11.2. Seguridad de los equipos.

» A.12. Seguridad de las operaciones.

o A.12.1. Procedimientos y responsabilidades operacionales.
o A.12.2. Protección contra el software malicioso (malware).
o A.12.3. Copias de seguridad.
o A.12.4. Registros y supervisión.
o A.12.5. Control del software en explotación.
o A.12.6. Gestión de la vulnerabilidad técnica.
o A.12.7. Consideraciones sobre la auditoria de sistemas de información.
» A.13. Seguridad de las comunicaciones.

o A.13.1. Gestión de la seguridad de redes.
o A.13.2. Intercambio de información.
» A.14. Adquisición, desarrollo y mantenimiento de los sistemas de

información.
o A.14.1. Requisitos de seguridad en sistemas de información.
o A.14.2. Seguridad en el desarrollo y en los procesos de soporte.
o A.14.3. Datos de prueba.
» A.15. Relación con proveedores.

o A.15.1. Seguridad en las relaciones con proveedores.
o A.15.2. Gestión de la provisión de servicios del proveedor.
» A.16. Gestión de incidentes de seguridad de la información.

o A.16.1. Gestión de incidentes de seguridad de la información y mejoras.
» A.17. Aspectos de seguridad de la información para la gestión de la

continuidad del negocio.
o A.17.1. Continuidad de la seguridad de la información.
o A.17.2. Redundancias.
» A.18. Cumplimiento.
o A.18.1. Cumplimiento de los requisitos legales y contractuales.
o A.18.2. Revisiones de la seguridad de la información.

6.15. Auditoría de certificación del SGSI
La certificación del SGSI por parte de la organización tiene, entre otras, las siguientes
ventajas:
» Para los Sistemas de Información:

o Sistematizar las actividades de SI.
o Ahorro de recursos en las actividades de SI, mejorando la motivación e
implicación de los empleados.
o Analizar riesgos: identificar amenazas, vulnerabilidades e impactos en la
actividad empresarial.
o Establecer objetivos y metas que permitan aumentar el nivel de confianza en la
seguridad.
o Planificar, organizar y estructurar los recursos asignados a seguridad de la
información.
o Identificar y clasificar los activos de información.
o Seleccionar controles y dispositivos físicos y lógicos adecuados a la
estructura de la organización.
o Asegurar el nivel necesario de disponibilidad, integridad, y confidencialidad
de la información.
o Establecer planes para adecuada gestión de la continuidad del negocio.
o Establecer procesos y actividades de revisión, mejora continua y
auditoría de la gestión y tratamiento de la información.
» Para el negocio:
o Integrar la gestión de la seguridad de la información con otras modalidades
de gestión empresarial.
o Mejorar la imagen, confianza y competitividad empresarial.
Certificación y reconocimiento por terceros.
o Comprobar su compromiso con el cumplimiento de la legislación:
protección de datos de carácter personal, servicios sociedad de información,
comercio electrónico, propiedad intelectual, etc.
o Dar satisfacción a accionistas y demostrar el valor añadido de las actividades
de seguridad de la información en la empresa.
En definitiva, la certificación del SGSI por parte de la organización aporta confianza

a los sistemas de información.

La auditoría de certificación del SGSI se realiza en dos fases, como puede apreciarse en
la siguiente ilustración:
Fases de auditoría del SGSI
La auditoría del SGSI se rige por los principios de la ISO17021, de manera que se realiza
un cuestionario preliminar y solicitud de auditoría, tras el cual se efectúa la auditoría en
dos fases:
» Fase 1 (presencial) de estudio de la documentación (declaración de intenciones):

política, procedimientos/controles, informe de análisis de riesgos, declaración de
aplicabilidad. Tras la fase 1 se emite un informe con las observaciones o no
conformidades detectadas que la organización podría subsanar antes de la fase 2, en
cuyo caso no formarían parte del informe final de auditoría.
» Fase 2 (presencial) en la que se buscará evidencia de la implantación de los
controles y se generará el informe final de auditoría.
La organización deberá elaborar y presentar un Plan de Acciones Correctivas de cuya

evaluación y valoración por parte de la certificadora se desprenderá la concesión del
certificado.
Tras la concesión del certificado, la organización deberá pasar auditorías de seguimiento

al primer y segundo año y una auditoría de renovación el tercer año y así de forma
sucesiva para asegurar la mejora continua del SGSI.

Lo + recomendado
No dejes de leer…
Seguridad y calidad en el servicio de las TIC
Fernández Sánchez, C. M., y Delgado, B. (2009). Seguridad y calidad en el servicio de las

TIC. UNE: boletín mensual de AENOR, 242, 45-47.
Este artículo muestra los principales modelos de gestión, familia de Normas UNE-ISO/IEC
27000, para conseguir una adecuada gestión de la seguridad de la información en
las organizaciones.

http://www.aenor.es/Documentos/Comercial/Archivos/NOV_DOC_Tabla_AEN_189
27_1.pdf
La norma ISO 27001
Fernández Sánchez, C. M. (2012). La norma ISO 27001. Resvista Calidad, 3, 40-44.
Este artículo presenta la norma UNE ISO/IEC 27001 «Sistema de

Gestión de la Seguridad de la Información», necesaria para
identificar los riesgos que afectan, actualmente, a la
confidencialidad y seguridad de las TI en las empresas.

http://www.aec.es/c/document_library/get_file?uuid=a89e72de-d92b-47cf-ba5e-
5ea421fcbeb4&groupId=10128

+ Información
AENOR
La Asociación Española de Normalización y Certificación (AENOR), es el organismo

legalmente responsable del desarrollo y difusión de las normas técnicas en España. En
su página podrás encontrar información que te será de gran utilidad.

www.aenor.es
El portal de la ISO 27001 en español
En este portal, punto de información, podrás encontrar todo la información y recursos

referente la serie de normas ISO 27000 y de los Sistemas de Gestión de Seguridad de
la Información.

http://www.iso27000.es

ISMS Forum Spain
Red abierta de conocimiento que conecta empresas, organismos públicos y privados,

investigadores y profesionales comprometidos con el desarrollo de la Seguridad de la
Información en España.

http://www.ismsforum.es/
ISO/IEC JTC 1/SC 27 - IT Security Techniques
Las Normas Internacionales a través de comités técnicos establecidos por la organización

respectiva, para tratar con campos particulares de la actividad técnica.

http://www.iso.org/iso/iso_technical_committee?commid=45306
Bibliografía
Gómez, L. Fernández, P.P. (2015). Cómo implantar un SGSI según UNE-ISO/IEC


Test
1. ¿Cuál es la base que aportan los estándares ISO a la Gestión de las TICs?
A. Terminología técnica.
B. La aplicación de mejora continua con el ciclo de Demming/PDCA.
C. Indicadores y métricas.
2. ¿Cuáles son los elementos fundamentales en el PDCA?

A. Gestión de incidentes.
B. Análisis de riesgos.
C. Formación.
D. Objetivos orientados al negocio, formación y concienciación, auditorías internas
y revisión por dirección, acciones preventivas y correctivas.
3. ¿Un sistema de Gestión en las TICs, qué estándares utiliza usualmente?

A. Motor (PDCA)–Conocimiento (Buenas prácticas-Controles TICs).
B. Moto–Conocimiento–Autenticación.
C. Motor–Conocimiento–Testing.
4. Indicar en los sistemas de gestión en las TICs en ISO que tipos de auditoría hay:
A. Test de intrusión y análisis de vulnerabilidades.
B. Auditoría interna y auditoría externa de certificación.
C. Auditoría bienal, auditoría interna y test de intrusión.
5. El sistema de Gestión de la Seguridad de la Información–SGSI. ¿Cuál tiene PDCA?

A. La ISO 27001 y la ISO 27002.
B. Solo la ISO 27002.
C. La ISO 27001.

6. ¿Cuáles son los 3 pilares en que se fundamenta el SGSI?

A. Privacidad, integridad y disponibilidad.
B. Integridad, confidencialidad y continuidad.
C. Confidencialidad, Integridad y Disponibilidad.
D. Confidencialidad, Integridad y No repudio.
7. ¿En el análisis de riesgos en SGSI se consideran, en primer nivel?

A. Solo los activos hardware.
B. Procesos de negocio/Servicios de TI.
C. Solo los activos software y las personas.
D. Bases de datos.
8. ¿Cuál de las siguientes no es un área o capítulo de la ISO/IEC 27002?

A. Gestión de la continuidad del negocio.
B. Cumplimiento.
C. Clasificación y control de activos.
D. Plan estratégico de la seguridad.
9. ¿Cuál de las siguientes afirmaciones es incorrecta?

A. El análisis de riesgos es la piedra angular del SGSI.
B. La organización debe determinar los controles a aplicar en la declaración de
aplicabilidad.
C. El anexo A del estándar ISO/IEC 27001 enumera 133 controles organizados en
11 áreas, cada una de las cuales cubre algunos de los 39 objetivos de control.
D. La organización solo podrá certificar su SGSI si implementa los 133 controles
del estándar.
10. ¿Cuál de las siguientes afirmaciones es incorrecta?

A. La revisión por la dirección permitirá realinear los esfuerzos de implantación
del SGSI para asegurar su eficiencia y eficacia.
B. La mejora continua del SGSI se desempeña por cualquiera de los recursos de la
organización.
C. La revisión de la dirección debe realizarse a intervalos planificados y como
mínimo 1 vez al año.

GLOSARIO
Eficacia
Capacidad de lograr unos objetivos deseados o esperados. La RAE la define como:
«Capacidad de lograr el efecto que se desea o se espera (Del lat. efficacĭa)».
Eficiencia
El término eficiencia procede del latín efficientĭa y se define como la capacidad de
conseguir el objetivo en cuestión con el mínimo de recursos posibles viable
Gestión
La RAE define la gestión como la «acción y efecto de gestionar», es decir, el «hacer
diligencias conducentes al logro de un negocio o de un deseo cualquiera».
Gestión de las TIC

La gestión de las TIC (IT Service Management, ITSM) es un tipo específico de gestión
basado en procesos cuyo objetivo es alinear los servicios de TI con las
necesidades de las empresas, poniendo énfasis en los beneficios para todas las
partes interesadas (stakeholders: clientes, empleados, accionistas, etc.).
Gobierno
La RAE define Gobierno como la «acción y efecto de gobernar o gobernarse», por tanto,
mandar con autoridad o regir algo conforme a una norma, regla o idea.
Las organizaciones son entes que existen en un hábitat económico, político, normativo,
legal, medioambiental, etc. y que definen su misión y principios en el respeto y
convivencia adaptativa a dicho medio. El gobierno será la forma en que las entidades
desarrollan el logro de sus objetivos de negocio en equilibrio con el hábitat
organizativo.
El concepto de gobierno es más amplio que el de gestión, de hecho el gobierno engloba

la gestión, pero amplía su ámbito ya que su objetivo es el de lograr un desarrollo
económico, social e institucional duradero, promoviendo el sano equilibrio entre el
Estado, la sociedad civil, el mercado y la economía.
Es decir, el gobierno no solo persigue el logro de los objetivos (para lo cual será
necesario la gestión) sino que además estos objetivos habrán de lograrse asegurando la
sostenibilidad de la organización o entidad, en equilibrio y cumplimiento de unos
principios de responsabilidad, ética y conducta.
Gobierno de las TIC

El gobierno de las TIC, también denominado gobernanza de las TIC, es el conjunto de
prácticas a seguir en el uso y aprovechamiento de Tecnologías de Información para el
apoyo al logro de los objetivos de negocio y el aseguramiento de los seis principios de
gobierno definidos por la ISO/IEC 38500 —la norma ISO/IEC 38500:2008,
publicada en junio de 2008, basándose en la norma australiana AS8015:2005— que
desarrollaremos a lo largo del siguiente capítulo.
Información
En un sentido amplio podríamos definir la información como un conjunto organizado
de datos procesados, que constituyen un mensaje que configura el estado de
conocimiento del sujeto o sistema receptor de dicho mensaje.
El término clave es el de que son datos organizados, es decir, datos que tienen una
estructura útil que servirá para las sucesivas interacciones del ente poseedor de dicha
información con su entorno.
Riesgo
La probabilidad de que se produzca un impacto negativo en un activo, en un dominio o
en toda la organización (aprovechando una vulnerabilidad/debilidad de los sistemas de
información).
SI-SSII-Sistema (s) de información

Conjunto de personas, datos y actividades que procesan los datos y la información en
una determinada empresa, incluyendo procesos manuales y automáticos.
Se define como un conjunto de procesos planificados, para dar soporte y ejecutar una
actividad. Pueden ser manuales, semi-mecanizados o mecanizados
Normalmente el término es usado de manera errónea como sinónimo de sistema

informático debido a que en la mayor parte de los casos los recursos materiales de un
sistema de información están formados casi en su totalidad por sistemas informáticos.
2
Sin embargo, estrictamente hablando, un sistema de información podría ser manual y
no estar conformado por sistemas informáticos (aunque la realidad de las
organizaciones no suela ser el caso).
Se podría decir que los sistemas de información informáticos son una subclase o un
subconjunto de los sistemas de información en general.
Ciborra definió el estudio de los sistemas de información como el estudio que se centra
en el uso de la tecnología de la información en las organizaciones, instituciones de
cualquier tipo, y en la sociedad. (Ciborra, C. (2002). Labyrinths of Information, Oxford,
Oxford University Press)
TIC- Tecnología de la Información y de las Comunicaciones

Se encargan del estudio, desarrollo, implementación, almacenamiento y distribución de
la información mediante la utilización de hardware y software como medio de sistema
informático.
Las TIC son una pieza esencial en el negocio de las organizaciones, entidades y
contribuyen al bienestar social, ofreciendo al ciudadano y a la sociedad un conjunto de
servicios facilitadores que contribuyen a incrementar su nivel de vida.
Así lo manifestó Kofi Annan, en su discurso inaugural de la primera fase de la Cumbre

mundial sobre la Sociedad de la Información (WSIS) que cuenta con la participación de
los gobiernos nacionales, el sector privado, organizaciones y representantes de la
sociedad civil, Naciones Unidas y sus organismos especializados:
«Las tecnologías de la información y la comunicación no son ninguna panacea ni

fórmula mágica, pero pueden mejorar la vida de todos los habitantes del planeta. Se
dispone de herramientas para llegar a los Objetivos de Desarrollo del Milenio, de
instrumentos que harán avanzar la causa de la libertad y la democracia y de los medios
necesarios para propagar los conocimientos y facilitar la comprensión mutua». (Kofi
Annan, discurso inaugural de la primera fase de la Cumbre mundial sobre la Sociedad
de la Información, WSIS, Ginebra, 2003).

Auditoria de La Seguridad

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Auditoria de La Seguridad

Diunggah oleh

Hak Cipta:

Format Tersedia

Introducción a los sistemas de

[1.2] Introducción a los sistemas de información y el rol de la

[1.3] Definiciones de «auditoría informática» y de «control

[1.4] Funciones y objetivos de la auditoría informática

[1.5] Diferencias entre control interno y auditoría informática

© Universidad Internacional de La Rioja (UNIR)

1.1. ¿Cómo estudiar este tema?

1.2. Introducción a los sistemas de información y el rol de la

Un sistema de información es el conjunto de procesos, personas, datos y actividades

Los activos de Sistemas de Información

» Salvaguardar la propiedad de la información. Los activos de SI asegurarán que

TEMA 1 – Ideas clave 3 © Universidad Internacional de La Rioja (UNIR)

» Mantener la integridad de los datos (información). Los activos de SI deben

De manera que todo sistema de información eficaz y eficiente se basa en:

» Planificación: un sistema de información no es un elemento aislado, sino que

Las personas se interrelacionan y trabajan con otras personas y departamentos, de

» Controles: más adelante desarrollaremos ampliamente la definición y tipología de

TEMA 1 – Ideas clave 4 © Universidad Internacional de La Rioja (UNIR)

procesos y procedimientos definido por la propia organización como sustento

La ausencia de alguno de los elementos anteriores como base de un sistema de

Las TIC como apoyo al plan estratégico de las empresas

Si bien es necesario el alineamiento e integración entre el plan estratégico y el plan de

Reseña histórica y el rol del auditor informático.

El crecimiento de las organizaciones y el avance tecnológico confluyen a mediados del

TEMA 1 – Ideas clave 5 © Universidad Internacional de La Rioja (UNIR)

de ordenadores más potentes, pequeños y económicos, la informática se convierte en una

Se desarrolla la denominada auditoría con el ordenador, a la que no se le considera

Pero es el evolucionar tecnológico lo que altera el soporte y medio de generación,

Es decir, si al inicio de la función auditora los auditores trabajaban con información

La búsqueda de la exactitud y veracidad de la información nos lleva a plantearnos si a lo

La Ilustración 1 muestra un esquema del tratamiento informático de la información:

Procesamiento informático de la información

TEMA 1 – Ideas clave 6 © Universidad Internacional de La Rioja (UNIR)

Es decir, las organizaciones han diseñado e implementado o adquirido procesos

Inicialmente, el auditor informático es un perfil técnico (analistas-programadores)

Pero pronto el auditor informático va asumiendo nuevas funciones y responsabilidades,

» Analista programador para el auditor financiero.

La Auditoría Informática se desarrolla principalmente en Estados Unidos, Reino Unido

TEMA 1 – Ideas clave 7 © Universidad Internacional de La Rioja (UNIR)

interno de las Tecnologías de la Información y las Comunicaciones se constituye con la

En 1993, el nombre de la asociación EDPAA cambia a ISACA (Information Systems

En 1998, ISACA funda el ITGI (IT Governance Institute), encargado de desarrollar y

1.3. Definición de «auditoría informática» y «control interno

Este apartado define los conceptos de auditoría, de auditoría informática y de

La auditoría evalúa ajustándose a un sistema con el objetivo de determinar de

Los resultados de una auditoría han de estar basados en evidencias

El auditor debe obtener evidencia suficiente y completa, mediante la aplicación de

TEMA 1 – Ideas clave 8 © Universidad Internacional de La Rioja (UNIR)

Por tanto, la evidencia del auditor ha de ser suficiente y completa:

» La suficiencia mide la cantidad de la evidencia; es decir, si sustenta las

Algunos métodos de obtención de evidencias por parte del auditor son:

» Inspecciones (documentales o físicas).

Las evidencias pueden ser:

» Físicas: obtenidas a través de las inspecciones y la observación.

Tradicionalmente han existido diversas clases de auditoría en función de su contenido,

» De Cumplimiento: tiene como objetivo verificar e informar sobre el cumplimiento

TEMA 1 – Ideas clave 9 © Universidad Internacional de La Rioja (UNIR)

» Informática (o de sistemas de información): su objetivo es evaluar el

Desde otro enfoque, podríamos clasificar las auditorías como:

» Interna: realizada por personal vinculado laboralmente a la institución pero

Todas los tipos de auditoría se basan en los principios de independencia, sistematicidad

Definición de control interno informático

El control interno informático es el conjunto de medidas (controles) que la organización

» Garantizar diariamente que todas las actividades de SI sean realizadas