Auditoría Técnica

Auditoría Técnica
M1.810 UOC 2022

Introducción a la
Auditoría
01 Presentación
Introducción a la Auditoría TIC y

02 de Seguridad TIC
03 Solución PEC 1
-1-
Universitat Oberta
de Catalunya
Aula
M1.810 - Auditoría técnica aula 2
Módulo 1 - Introducción a la auditoria
Inicio: Fin:
16/02/22 06/03/22
00:00h 24:00h
Hora central Hora central
europea (CET) europea (CET)
Recursos d'aprenentatge
Materiales
Introducción a la auditoría TIC y de seguridad TIC

Audiolibro
ePub
Mobipocket
html5
Pdf
Introducción a la
auditoría TIC y de
seguridad TIC
PID_00285949
Rafael Estevan de Quesada
Tiempo mínimo de dedicación recomendado: 5 horas

© FUOC • PID_00285949 Introducción a la auditoría TIC y de seguridad TIC
Ingeniero superior de Telecomuni-

caciones por la Universidad Politéci-
ca de Valencia. Consultor en segu-
ridad de la información certificado
en Auditoría de Sistemas de Infor-
mación (CISA®) por la ISACA, con
formación en ingeniería de teleco-
municación y 20 años de experien-
cia en empresas multinacionales del
sector de las telecomunicaciones y
empresas consultoras especializadas
en seguridad de la información.
La revisión de este recurso de aprendizaje UOC ha sido coordinada

por el profesor: Carles Garrigues Olivella
Cuarta edición: febrero 2022

© de esta edición, Fundació Universitat Oberta de Catalunya (FUOC)
Av. Tibidabo, 39-43, 08035 Barcelona
Autoría: Rafael Estevan de Quesada
Producción: FUOC
Todos los derechos reservados
Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada,
reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio, sea este eléctrico,
mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita
del titular de los derechos.
Índice
Introducción............................................................................................... 5
1. Definición de auditoría.................................................................... 7
1.1. Principios de auditoría ................................................................ 9
2. Componentes de una auditoría...................................................... 12

2.1. Tipos genéricos de auditorías ...................................................... 12
2.1.1. Auditorías internas o de primera parte ......................... 13
2.1.2. Auditorías de segunda parte .......................................... 13
2.1.3. Auditorías de tercera parte ............................................ 13
2.2. El objetivo y criterios de auditoría ............................................. 15
2.3. Alcance de la auditoría ............................................................... 16
3. Proceso de auditoría......................................................................... 17
3.1. Tipos de pruebas ......................................................................... 19
3.2. Muestreo ...................................................................................... 19
3.3. Evidencias de auditoría ............................................................... 21
3.4. Hallazgo de auditoría .................................................................. 23
3.5. Riesgo de auditoría ...................................................................... 23
4. Programa de auditoría..................................................................... 25
4.1. Beneficios de implementar un programa de auditoría ............... 27
4.2. Establecimiento de un programa de auditoría ............................ 28
5. Estandarización de la labor de auditoría.................................... 33

5.1. IAASB y AICPA (American Institute of Certified Public
Accountants) ................................................................................ 33
5.2. ISO (International Organization for Standarization), las
entidades de certificación y de acreditación ............................... 36
5.3. ISACA (Information Systems Audit and Control Association) .... 41
5.4. IRCA (International Register of Certificated Auditors) ............... 41
6. Gobierno de las TIC........................................................................... 43

6.1. Auditoría de los sistemas de información .................................. 45
6.2. Certificación de seguridad .......................................................... 47
7. Equipo auditor.................................................................................... 48
7.1. Auditor jefe ................................................................................. 49
7.2. Auditor ......................................................................................... 51
7.3. Experto técnico ........................................................................... 52
7.4. Capacitación del equipo auditor ................................................ 52
7.5. Independencia de auditoría ........................................................ 53

7.6. Código de conducta del equipo auditor ..................................... 53
7.7. Distribución de funciones ........................................................... 54
7.8. Relación con el auditado ............................................................ 54
8. El peritaje informático..................................................................... 56
© FUOC • PID_00285949 5 Introducción a la auditoría TIC y de seguridad TIC
Introducción
Con el objetivo de reducir los incidentes de seguridad, las organizaciones tie- COBIT 2019
nen implantadas una serie de medidas con la idea de que, si ocurren, las con
Para más información sobre di-
secuencias que provoquen sean mínimas. La selección de las medidas más idó- ferencias entre COBIT5 y CO-
neas estará basada en un proceso de análisis del riesgo al que se encuentra so- BIT2019 ver:
https://www.isaca.org/re-
metida la información y, en ciertos casos, estas medidas habrán sido escogidas sources/news-and-trends/in-
dustry-news/2020/cobit-2019-
de un catálogo de buenas prácticas reconocido por la industria, por ejemplo and-cobit-5-comparison
en la Norma ISO/IEC 27002:2013 (anteriormente se denominaba 17799 y ha
sufrido diversas modificaciones y actualizaciones desde su creación) o en la
COBIT (última versión COBIT 2019, publicada en 2018).
Por otra parte, las organizaciones más preocupadas por la protección de su in-
formación son conscientes de que la seguridad total no se conseguirá nunca;
por ello, para tratar de lograr esa seguridad global en una organización, tam-
bién se requieren unos planes de continuidad de negocio.
Todas estas medidas de seguridad y los mecanismos para gestionarlas confor-

man lo que se denomina un sistema de gestión de la seguridad de la información
(SGSI), un sistema que tiene por objetivo tratar de evitar los incidentes de se-
guridad; pero, si llegan a ocurrir, que se puedan gestionar de la mejor manera
posible y, por último, que a lo largo del tiempo se pueda aprender de las con-
clusiones obtenidas y mejorar los mecanismos de seguridad.
Sin embargo, cabe recordar que la seguridad es un proceso vivo, que no es

una meta que se alcanza, que debe estar en constante revisión y que es fun-
damental que en todo momento las medidas de seguridad de que dispone la
organización reflejen la situación actual y se adecuen al entorno en que ésta
se encuentra.
Por esta razón se producen constantes cambios tanto en la configuración de los

sistemas de información, como en el mismo entorno en el que se encuentran.
Por lo que es recomendable disponer de algún tipo de mecanismo de revisión,
preferiblemente independiente, con el objetivo de que se detecten los aspectos
que puedan ser más vulnerables o que no estén correctamente configurados.
Estas revisiones de la seguridad de una organización se denominan auditorías

de seguridad. Forman parte de este ciclo vivo de la seguridad y permiten asegu-
rar que los controles de seguridad implantados son los más adecuados y están
correctamente configurados.
Cuando las auditorías de seguridad se basan en la revisión del conjunto de me-

didas y de su proceso de gestión frente a normativas vigentes, y concretamen-
te frente a la ISO/IEC 27001, nos encontramos con procesos que pretenden
comprobar que la gestión de la seguridad se realiza de manera acorde a unos

parámetros reconocidos por la industria y da como resultado las denominadas
certificaciones�de�seguridad�del�sistema�de�gestión�de�la�seguridad�de�la
información.
Por otra parte, también resulta interesante resaltar que actualmente nos en-
contramos ante la obligación legal de comprobar periódicamente las medidas
de seguridad implantadas para reducir los riesgos que amenazan la informa-
ción. Tanto en el marco de la legislación en materia de protección de datos (en
Europa, el Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo
de 27 de abril de 2016 relativo a la protección de las personas físicas en lo que
respecta al tratamiento de datos personales, conocido como GDPR, y en Espa-
ña, Ley Orgánica 15/1999 de Protección de Datos de Carácter Personal), como
en el marco financiero (en el ámbito europeo, los acuerdos Basilea III –actua-
lización respecto al II en 2010– y, para todas las empresas cotizadas en Estados
Unidos, la Ley Sarbanes-Oxley), se exige realizar periódicamente revisiones del
riesgo operacional y, por lo tanto, se deriva la necesidad de realizar auditorías
de seguridad de los sistemas de información. En este sentido, es interesante
destacar un resumen de la sección 404 de la Ley Sarbanes-Oxley disponible en
el sitio web de la AICPA, que expresa esta necesidad claramente:
"Section 404: Management Assessment of Internal Controls
Requires each annual report of an issuer to contain an "internal control report", which
shall:
1) state the responsibility of management for establishing and maintaining an adequate

internal control structure and procedures for financial reporting; and
2) contain an assessment, as of the end of the issuer's fiscal year, of the effectiveness of
the internal control structure and procedures of the issuer for financial reporting."
La cita indica que la dirección de las empresas cotizadas en los mercados de va-
lores americanos debe establecer y mantener estructuras internas para el con-
trol financiero y que anualmente debe revisarse que estos controles internos
sean efectivos. Puesto que actualmente la gestión y el control de las finanzas
recaen en su totalidad en sistemas de información, tanto los controles como
las auditorías exigidas por la Ley Sarbanes-Oxley son extensibles a los sistemas
de información.
Toda esta situación que hemos comentado ha llevado al auge de la disciplina

de la auditoría de sistemas de información como un derivado inicial de las au-
ditorías de cuentas. Este protagonismo está reforzado por el entorno actual en
que los sistemas de información participan cada día más en todos los procesos
productivos y no sólo en los de control financiero de las instituciones. Por
lo tanto, este curso tiene por objeto presentar los conceptos fundamentales
que definen las auditorías de sistemas de información y muy especialmente
la auditoría de la seguridad de la información, y mostrar al alumno el amplio
campo que existe en esta área para su propio desarrollo profesional.
1. Definición de auditoría
Actualmente, la gestión moderna de los negocios, y en especial en organiza-

ciones de gran tamaño o actividad, o simplemente maduras en cuanto a la
profesionalización de su gerencia, hace que exista cada vez más una necesidad
de comprobar que los procesos de negocio operan siguiendo la estrategia de
gobernanza establecida por la alta dirección, así como de conocer todas las
influencias externas que puedan afectar al área de negocio del proceso:
• Marcos regulatorios generales: todo el marco legal que aplique por el ám-
bito geopolítico donde se ejecute el proceso de negocio.
• Marcos regulatorios generales para todos los negocios, pero específicos en

un ámbito concreto, como por ejemplo toda la normativa de regulación
del control de la actividad financiera y contable, las leyes referentes a pri-
vacidad y protección de datos de carácter personal (RGPD y LOPD), la ley
de servicios de la sociedad de la información y el comercio electrónico
(LSSI-CE), la ley sobre firma electrónica, etc.
• Marcos regulatorios del sector en que se desarrolla la actividad de negocio,

como por ejemplo el mercado de los seguros y servicios financieros.
• Términos y condiciones concretados en las relaciones contractuales entre

cliente y proveedor, acuerdos de colaboración entre distintas empresas de
un grupo empresarial o códigos deontológicos entre organizaciones de un
sector económico.
• Buenas prácticas de la industria.
• Etc.
En este contexto, es legítimo considerar que, ya sea por iniciativa propia o por
necesidad impuesta externamente, la dirección de la empresa necesita verificar
ese cumplimiento de un modo u otro, y de aquí surge la necesidad de realizar
auditorías.
De manera muy informal, cuando se habla de auditoría se piensa en una he-

rramienta a disposición de la gerencia para el control de algún proceso de ne-
gocio. Esta actividad se entiende que debe involucrar una metodología para
establecer los criterios que ayudarán a medir la eficiencia, eficacia y posibles
desviaciones de los objetivos dados a un proceso concreto. Pero esta no es más
que una idea general y poco precisa. El objeto de este módulo es entrar en más
detalle en la definición y características que tiene el proceso de auditoría.
Definición de auditoría
Una auditoría, desde un punto de vista muy general, es un proceso eje-

cutado por un auditor, que tiene la característica de ser sistemático,�in-
dependiente�y�documentado, y que busca obtener a partir de la rea-
lización�de�pruebas�de�auditoría registros, declaraciones de hechos u
otra información conocida como evidencias�de�auditoría. Las eviden-
cias de auditoría deben ser verificables,�pertinentes�y�evaluables de
manera objetiva para, en base a ellas, determinar la medida en la cual
el hecho auditado cumple unos criterios�de�auditoría. Estos criterios
están determinados por un conjunto de políticas, procedimientos o re-
quisitos y son usados como referencia contra la que se compara la reali-
dad. Las pruebas de estas diferencias entre la realidad y la referencia son
lo que se entiende como hallazgos de auditoría. Finalmente, el proceso
concluye con el análisis de estos hallazgos para poder emitir�unas�con-
clusiones�de�la�auditoría.
Por tanto, podemos concluir que el proceso de auditoría pretende poder

objetivizar lo que, de otro modo, sería más correcto calificar como la
opinión de un experto.
Se entiende por evidencia de auditoría el conjunto de registros, declaraciones

de un hecho u otra información que se recoja durante el proceso de audito-
ría que sea verificable y pertinente para ser contrastado contra los criterios de
auditoría. Por criterio de auditoría se entiende como el conjunto de políticas,
procedimientos o requisitos usados como referencia en la auditoría y que sue-
len tener como objetivo el control de algún aspecto de la actividad del audi-
tado. Es por ello que a veces se emplea como sinónimo de controles.
Es importante entender que según el ámbito de conocimiento o de organiza-

ción se habla de distintos tipos de auditorías, aunque todas ellas tienen un
patrón común. Podemos destacar como las más comunes:
• Auditorías financieras, con muchas distinciones (auditorías de cuenta, va-

loración de empresas, etc.) y tradicionalmente es el tipo más conocido,
regulado y ampliamente aplicado por las organizaciones por las obligacio-
nes legales e implicaciones de cara al mercado.
• Auditorías a procesos productivos o de calidad, no sólo relacionadas con

la ISO 9001 sino con otros esquemas de gestión de la calidad total como
Six Sigma.
• Auditorías al proceso de gestión de recursos humanos.
• Auditorías de cumplimiento legal.

Ejemplo
Auditorías del marco legal de protección de datos de carácter personal. Anteriormente

en España el reglamento de desarrollo de la LOPD, aprobado por el Real Decreto 1702
de 2007, en su artículo 96 establecía esta obligación a partir de la implantación de me-
didas de seguridad de nivel medio. Pero este reglamento ya no es de aplicación al haber
publicado el RGPD (Reglamento de la Unión Europea 2016/679 del Parlamento Europeo
y del Consejo de 27 de abril de 2016 relativo a la protección de las personas físicas en
lo que respecta al tratamiento de datos personales). Esta es una norma más reciente y
de mayor rango por lo que el reglamento español no es de aplicación. Sin embargo, aun-
que no se explicita el término auditoría, el RGPD establece obligaciones similares, en el
art. 32 (indica que el responsable determinará las medidas apropiadas para garantizar
un nivel de seguridad apropiado al riesgo), y el principio de responsabilidad proactiva
(establece que el responsable deberá cumplir con la normativa de protección de datos y
ser capaz de demostrarlo). Por ambos principios, está claro que la organización debería
realizar acciones para revisar el grado de implantación de las medidas de seguridad que
haya establecido como necesarias.
• Auditorías a la gestión medioambiental.
• Auditorías a los sistemas de información y en general a la forma en que

es tratada y gestionada la seguridad de la información digital de una or-
ganización.
• Etc.
Conviene destacar que nos ocuparemos de las auditorías a sistemas de gestión

de la seguridad de la información. En cualquier caso, las auditorías pretenden
comprobar si el auditado está ejerciendo suficiente control sobre alguno de los
aspectos de uno o varios de sus procesos de negocio. Desde este punto de vista
común, explicaremos en este módulo los aspectos que son independientes del
hecho que se esté auditando.
1.1. Principios de auditoría
Sea cual sea el tipo de auditoría y el hecho auditado, la auditoría siempre de-
bería guiarse por unos principios que garanticen que el trabajo realizado co-
rresponde a algo más que la opinión de un experto y que puede considerarse
como una auditoría, es decir, un análisis sistémico. La adhesión a estos prin-
cipios es necesaria para que las conclusiones de la auditoría sean pertinentes y
suficientes, y para asegurar que los auditores que trabajan independientemen-
te entre sí lleguen a conclusiones similares en circunstancias similares.
Podemos afirmar que si la auditoría se rige por los siguientes principios será
suficientemente objetiva. Este es un tema tan importante que en los sectores
profesionales orientados a la auditoría es habitual documentarlos y promocio-
narlos ampliamente. Incluso en áreas de auditoría muy críticas y regulariza-
das como son por ejemplo las auditorías de cuentas se encuentran regulados
los principios (y muchos otros aspectos) en leyes. Los principios que a conti-
nuación presentamos pueden considerarse ampliamente reconocidos, y están
basados en la norma ISO/IEC 19011, Directrices para la auditoría de sistemas
de gestión.
Los principios de auditoría afectan tanto al comportamiento y características

del auditor como al proceso de auditoría en sí misma. Los siguientes están
relacionados con el modo de comportamiento de los propios auditores:
• Integridad�/�Conducta�ética. Fundamento del profesionalismo. En una

asignación de auditoría es esencial que se establezcan relaciones de con-
fianza entre el auditado y el auditor. Para ello, es necesario que el auditor
actúe con un elevado grado de integridad, confidencialidad y discreción.
Se dice que el auditor debe regirse por un estricto código de conducta. Este
código puede estar explicitado o no. Es habitual que diversas asociaciones
o entidades que emiten certificados de auditor publiquen sus propios có-
digos, aunque todos ellos responden a las características que hemos enun-
ciado.
• Presentación�justa�e�imparcial. La obligación de informar verazmente y

con exactitud. Los hallazgos realizados, las conclusiones extraídas y los re-
portes de la auditoría que se emitan deben reflejar, con veracidad y exacti-
tud, las actividades de la auditoría. En todo momento, el auditor y el audi-
tado deben tener constancia de todos los obstáculos significativos encon-
trados durante la auditoría, los aspectos no resueltos o no tratados, junto
con las razones que lo provocaron, o cualquier opinión divergente entre
el auditor y el auditado.
• Debido� cuidado� profesional. La aplicación de diligencia y juicio en la

auditoría. Los auditores proceden con todo el cuidado y la profesionali-
dad requerida de acuerdo con la importancia de la tarea que realizan y la
confianza depositada en ellos por los clientes de la auditoría y las partes
interesadas. Un prerrequisito para gozar de tal reconocimiento, por parte
del auditado y del cliente, es poseer la competencia profesional y técnica
necesaria, y quizá acreditarla mediante certificaciones profesionales, títu-
los académicos, años de experiencia o similares.
Por otra parte, otros principios de auditoría se aplican al propio proceso de

la auditoría. Una auditoría es, por definición, independiente y sistemática, y
estas características están estrechamente relacionadas con los siguientes prin-
cipios de auditoría (que por otra parte también deben regir la labor tanto del
auditor como de la organización a la que pertenece):
• Independencia. Es la base de la imparcialidad y objetividad de las con- Ley 22/2015, de 20 de

clusiones de la auditoría. Los auditores deberían ser, por definición de la julio, de Auditoría de
Cuentas
auditoría, independientes de la actividad auditada. Esto no implica que no
puedan pertenecer a la organización, sino que no deben estar influencia- Esta ley española define en la
sección 2 todos los detalles
dos de algún modo por la actividad que van a auditar. Esto implica que, que se deben cumplir para ga-
rantizar la independencia del
por supuesto, un auditor que hubiese participado de algún modo en la im- auditor de cuentas. Estos prin-
plantación de los controles que se van a auditar, directa o indirectamente cipios son completamente ex-
trapolables a casi cualquier ti-
(por haber asesorado en alguna decisión, por ejemplo), no debería partici- po de auditoría, no solo de
cuentas.
par en una auditoría ni emitir un juicio de auditoría, por estar influencia-
do. Esta influencia sobre el auditor es la que hace que, no sólo los casos
como el anterior sean los que inhabilitarían a un auditor, sino que también
los conflictos de intereses deberían tenerse en cuenta a la hora de aceptar
o no a un auditor en un equipo o en una asignación.
Los auditores tienen que mantener un estado mental objetivo durante to-
do el proceso de auditoría, para asegurar que los hallazgos y conclusiones
se basarán solamente en evidencias.
• Enfoque�basado�en�la�evidencia. La base racional para llegar a conclu-

siones de auditoría confiables y reproducibles en un proceso de auditoría
sistemático.
La auditoría se basa principalmente en un ciclo obtención de evidencias,
análisis de éstas y confrontación con los criterios de auditoría para deter-
minar la presencia o no de un hallazgo de auditoría, el cual será el sopor-
te para la conclusión. Por lo tanto, la obtención de la evidencia de la au-
ditoría es crucial, puesto que debe soportar su puesta en duda y, por lo
tanto, debe derivarse de hechos verificables. La evidencia se debe basar en
muestras de información disponible. El uso apropiado del muestreo está
muy relacionado con la confianza que se puede tener en las conclusiones
de las auditorías.
• Confidencialidad. Finalmente, las partes implicadas en la auditoría

(cliente y auditado) deben poder confiar plenamente en la discreción y
profesionalidad de la entidad auditora (y por ende, de los auditores asig-
nados) a la hora de tratar con la información que es necesario comunicar
para poder realizar las pruebas de auditoría. Todas las partes deben confiar
en que la organización auditora o los auditores nunca harán un mal uso
de la información que obtengan en una asignación de auditoría.
Si un auditor se ciñe a los principios descritos, el resultado de su trabajo será

sólido y podrá soportar su puesta en duda.
2. Componentes de una auditoría
Existen varios elementos que definen una auditoría. Del análisis de ellos po-
dremos ir profundizando en los detalles generales y comunes a todo tipo de
auditoría.
2.1. Tipos genéricos de auditorías
En el proceso de auditoría aparecen tres actores principales que están íntima-

mente relacionados entre ellos y que siempre aparecen en una auditoría:
Relaciones entre los actores de una auditoría
• El auditor, o mejor dicho, el equipo auditor: es el grupo de personas (o una

sola) que han sido designados para ejecutar la auditoría en el interés del
cliente de la auditoría.
• El auditado: es la organización (o podría también ser la persona, aunque

esto es menos común que se dé) responsable del hecho que se audita.
• El cliente de la auditoría: es la persona u organización interesada en cono-

cer la conclusión de la auditoría.
De la existencia o no de los tres actores de una auditoría, la relación que ten-

gan entre ellos, la organización a la que pertenezca el equipo auditor, y la mo-
tivación que exista en la asignación, se derivan los tres tipos genéricos tipos
de auditorías, que son las siguientes:
• Auditorías internas o de primera parte.

• Auditorías de segunda parte.
• Auditorías de tercera parte.
2.1.1. Auditorías internas o de primera parte
En este caso, las auditorías son ejecutadas por un equipo auditor que puede
ser propio de la organización responsable del hecho auditado, o bien externo,
pero designado por la organización auditada. En estas situaciones, el destina-
tario final de los resultados del trabajo es la propia organización.
Este trabajo, en ciertas ocasiones, es empleado por las organizaciones para rea-
lizar una autoevaluación previa a otros tipos de auditoría. También puede te-
ner otros objetivos más prácticos, como detectar puntos de mejora en el hecho
auditado. En cualquier caso, el interesado en la auditoría es directamente el
propio auditado.
2.1.2. Auditorías de segunda parte
En ciertas ocasiones, una segunda organización puede tener un interés legíti-

mo para realizar una auditoría a la organización. En este caso, esta "segunda
parte" es la que designa al personal que realiza la auditoría, y es ella la desti-
nataria final de los resultados del trabajo de auditoría.
Existen múltiples situaciones reales que exigen este tipo de auditoría. La más
habitual que se suele dar es la encargada por una organización cliente sobre
su proveedor, por eso, en ocasiones también se denominan "auditorías de pro-
veedores". Cada vez más, las organizaciones externalizan partes de su activi-
dad, pero suelen reservarse el derecho de realizar auditorías para determinar el
grado de cumplimiento de los acuerdos de nivel de servicio. Otras situaciones
donde también se pueden dar auditorías de segunda parte son aquellas en las
que una empresa está en situación de absorber a otra. Aquí, es habitual encon-
trarnos con encargos de auditorías de cuentas o de valoración de la tomadora
de control sobre la absorbida. En caso de fusiones, al existir mayor equilibrio
de fuerzas, es posible que cada parte encargue una auditoría de segunda parte
de algún tipo sobre la otra empresa. Sin embargo, suele ser económicamente
más eficiente, y por tanto más común, que la auditoría la realice una tercera
parte acordada por ambas empresas, lo que nos introduce el siguiente tipo.
2.1.3. Auditorías de tercera parte
Las auditorías de tercera parte son las realizadas por organizaciones auditoras
externas e independientes de la parte auditada y del interesado en el resultado
de la auditoría. Dentro de este tipo de auditorías, encontraríamos las auditorías
de certificación de conformidad con los requisitos de una norma.
En estas auditorías, las tres partes (auditado, auditor, cliente) son absoluta-
mente independientes entre sí. En ocasiones, en el momento de realizar la
auditoría puede ser que ni siquiera esté definido quién es el cliente de ésta. El
auditor puede realizar la auditoría a petición del auditado porque este último
quiere que una parte independiente certifique/audite algún aspecto, en previ-
sión de que en un futuro pueda existir un cliente de auditoría interesado en
el resultado de la auditoría. También puede darse el caso de que el auditado
encargue la auditoría sencillamente porque existe un requerimiento (legal, re-
gulatorio del mercado o contractual) de que se disponga de una auditoría rea-
lizada por una parte independiente. Este tipo de auditorías también tienen lu-
gar en casos en los que el cliente de la auditoría es muy genérico, como puede
ser la Administración pública. En estos casos, el mercado marca los objetivos
de la auditoría mediante reglamentos, normas, contratos, etc. Las auditorías
de certificación contra una norma entran dentro de este tipo de auditorías de
terceras partes. Las auditorías de certificación permiten al auditado acreditar
el cumplimiento de los requisitos de la norma ante una comunidad amplia
y a priori indeterminada, pero potencialmente interesada, como podrían ser,
por ejemplo, sus clientes. Para ofrecer la máxima objetividad, se recurre a una
entidad externa a los interesados (el auditado y la comunidad). Por esto, esta
auditoría es clasificada como de tercera parte.
Finalmente, conviene destacar que las entidades que realizan este tipo de au-
ditorías deben tener reconocido su prestigio ante la comunidad, para que los
resultados de la auditoría sean considerados válidos. Esto conlleva la existen-
cia, en ciertas ocasiones y para determinados sectores, de requisitos que regu-
lan las actividades de los auditores. Este es el caso, por ejemplo, de los audito-
res de cuentas, los auditores de certificación contra normas, y cada vez más
también de los auditores de sistemas, aunque en este sector la regulación se
está realizando por el propio mercado.
Resumen�de�los�tres�tipos�básicos�de�auditoría
Relación
Tipo Auditor�frente�a�auditado Cliente�auditoría�frente�a�auditado Cliente�auditoría�frente�a�auditor
De�prime- Pueden pertenecer a la misma organi- Pertenecen a la misma organización. Pueden pertenecer a la misma organiza-
ra�parte zación, siempre que haya suficiente in- ción siempre que haya suficiente inde-
dependencia. pendencia.
Tampoco es extraño que sean diferen- Tampoco es extraño que sean diferen-
tes si en la organización cliente no hay tes si en la organización cliente no hay
el conocimiento técnico suficiente o los el conocimiento técnico suficiente o los
recursos disponibles. recursos disponibles.
De�segun- Pertenecen claramente a dos organiza- Existe una relación entre ellos que hace Suelen pertenecer a la misma organiza-
da�parte ciones distintas. que el cliente tenga un interés legítimo ción, aunque tampoco es extraño que
en exigir al auditado la realización de la sean diferentes si en la organización
auditoría. cliente no hay el conocimiento técnico
suficiente o los recursos disponibles.
De�terce- Pertenecen claramente a dos organiza- El cliente no existe a priori o es, de ma- Son diferentes.
ra�parte ciones distintas. nera genérica, el mercado o una comu- En estos casos, el auditor representa al
nidad de interesados muy amplia. Los cliente de la auditoría.
intereses del cliente están representa-
dos por el auditor.
Conviene destacar que sólo en entornos muy específicos y conocedores de la

terminología suele emplearse la distinción que hemos expuesto. Lo más co-
mún es que se haga mención al concepto de auditoría interna frente auditoría
externa. Con esta separación, se suele simplemente describir el hecho de que
el auditor pertenece o no a la organización auditada. Sin embargo, y como
hemos visto en la definición anterior de auditorías, esta visión es simplista y
sólo recoge los aspectos económicos. El aspecto más determinante no es si el
auditor es o no interno a la organización, sino más bien si la organización es la
principal "consumidora" del trabajo de auditoría, o bien si por el contrario lo es
una organización externa. Es decir, si es la propia organización quien ha defi-
nido el objetivo de la auditoría, o bien ha sido una externa quien ha decidido.
Los aspectos económicos son complejos y pueden darse todo tipo de situacio-
nes. Esta distinción es la que debería reflejarse, y no el aspecto económico.
''Plan, do, check/study, act''
De hecho, en los sistemas de gestión que implementan el ciclo de "Plan, Do, Check/
Study, Act", la auditoría interna es un elemento más para la mejora continua de al-
gún aspecto de la organización: la calidad, el impacto medioambiental de la organi-
zación, o la seguridad de la información. Cuando se determina que, en estos tipos
de sistemas de gestión, es necesario implementar la función de auditoría interna, se
pide exactamente que sea la propia organización quien defina los objetivos de la au-
ditoría y defina un plan de auditoría. Desde este punto de vista, es irrelevante si la
organización implementa la función de auditoría con recursos propios o si bien los
externaliza. Las razones para elegir una opción u otra son puramente económicas, y
no propias de la auditoría, salvo por el hecho de que la auditoría resultante debe ser
acorde a los principios de auditoría.
2.2. El objetivo y criterios de auditoría
Aparte de esta clasificación fundamental y absolutamente genérica de las audi-

torías, si nos fijamos en el hecho auditado, tenemos tantos tipos de auditorías
como temas auditables existen. En nuestro caso, nos es de especial relevancia
las auditorías informáticas, que serán aquellas en las que el hecho auditado
sean los sistemas de información y, más especialmente a lo largo del curso, las
que se refieren a la seguridad de la información tratada por estos sistemas. Este
concepto es el "objetivo de auditoría".
El objetivo de auditoría se refiere a las metas específicas que deben cumplirse

por parte de la auditoría. Los objetivos de auditoría son determinados por el
cliente de la auditoría, y se centran a menudo en validar si se implementan
ciertos controles definidos por unas políticas, normas y/o procedimientos. Es-
tas políticas, normas y/o procedimientos constituyen los criterios de auditoría
contra los que se evaluarán las evidencias.
Los objetivos pueden incluir aspectos como comprobar el nivel de cumpli-

miento de ciertos requerimientos legales, regulatorios o contractuales (estas
auditorías son las que contempla el marco legal español de protección de datos
de carácter personal). También pueden incluir la evaluación de los controles
implantados en una organización para garantizar la seguridad (confidenciali-
dad, integridad y disponibilidad) de la información tratada por los sistemas de

información o, más genéricamente, por los procesos de negocio de la organi-
zación. Por tanto, los objetivos son variados y es necesario que el cliente de
la auditoría (auditorías) los defina.
Así pues, los objetivos de la auditoría definen qué es lo que se va a conseguir

durante la misma. Los objetivos de una auditoría pueden incluir uno o varios
de los siguientes aspectos:
• Determinar el grado de conformidad del sistema de gestión del auditado,

o parte de él, con los criterios de auditoría.
• Evaluar la capacidad de los sistemas de gestión para asegurar el cumpli-
miento con requerimientos legales o contractuales.
• Evaluar la eficacia del sistema de gestión para lograr los objetivos especi-
ficados.
• Identificar áreas potenciales de mejora del sistema de gestión.
Posteriormente, es tarea del auditor traducir estos objetivos de auditoría a pun-

tos específicos de control que se deberán verificar. A partir de estos puntos de
control, se irán desgranando las comprobaciones y pruebas que se planificarán
y ejecutarán.
2.3. Alcance de la auditoría
Las organizaciones auditadas pueden tener múltiples procesos asociados, eje-

cutados en un área geográfica que puede ser muy amplia, con unos medios
muy diversos y por personal también variado. Por lo tanto, no sólo se tendrá
que definir el objetivo de la auditoría, sino también qué parte de la organiza-
ción abarca, es decir, cuál será su alcance.
El alcance de la auditoría describe la extensión y los límites de la auditoría. Por

ejemplo, las localizaciones físicas, las unidades organizativas, las actividades o
los procesos a ser auditados en el período de tiempo cubierto por la auditoría.
Es decir, todos los parámetros que limitan física, temporal y lógicamente la
actividad del auditor dentro de la organización auditada.
3. Proceso de auditoría
Aunque cada proyecto de auditoría es específico en sí mismo, incluso cuando

se audita un mismo hecho, pero en distintos momentos, podemos afirmar
que todas las asignaciones de auditoría se rigen por un proceso en cuatro fases
genéricas:
Fases generales de una auditoría
• La fase de planificación debería incluir todas las actividades necesarias para

dotar a la auditoría de un marco de trabajo, los recursos necesarios y los
objetivos a cumplir. Por lo tanto, incluirá tareas como:
– Designar al equipo auditor.
– Definir el alcance, los objetivos y los criterios generales de la auditoría

con el cliente, teniendo en cuenta las directrices estratégicas de la or-
ganización en la que se encuadre la función de auditoría.
– Recopilar el material necesario para el trabajo de campo y para el aná-

lisis posterior. Esto puede implicar la preparación de herramientas para
alguna tarea específica durante el trabajo de campo, o la identificación
y estudio previo de algún tipo de documentación.
– Reunirse con el auditado para la reunión de inicio de la auditoría.
– Identificación de los criterios de auditoría, y elaboración de un plan

de la auditoría que identifique el conjunto de pruebas que se van a
realizar, de modo que los criterios estén alineados con los objetivos
y alcance de la auditoría. Estos criterios serán la referencia contra la
que el auditor comparará los hechos que constate durante el trabajo

de campo.
• El trabajo de campo constituye la actividad principal de una auditoría.

Este trabajo consistirá en la ejecución del plan de auditoría realizando las
diversas pruebas de auditoría que buscarán comprobar el modo en que se
cumplen los criterios de la misma.
• Todo trabajo de campo debe culminar en la transferencia al auditado ini-

cialmente, y al cliente de la auditoría finalmente, de los resultados obte-
nidos. Se deberán analizar las pruebas realizadas y determinar si los resul-
tados se pueden catalogar como evidencias de auditoría, es decir, si son
relevantes para determinar conclusiones alineadas con el objetivo de la
auditoría. Estos resultados son contrastados primeramente con el audita-
do, para que pueda dar su opinión y ésta sea reflejada en las conclusiones.
Estas conclusiones serán expuestas normalmente en un documento final
denominado informe de auditoría.
• Las conclusiones de la auditoría deberían llevar al auditado a actuar de

algún modo para corregir los defectos que fueron evidenciados durante la
auditoría. Es recomendable que la organización auditora ofrezca una revi-
sión de los puntos auditados y, llegado el caso, sugiriera de manera general
propuestas de solución al auditado. Sin embargo, deberá vigilar que estas
recomendaciones no comprometan su independencia de cara a la futura
relación con el auditado y otras organizaciones. Debe existir siempre una
clara separación entre el trabajo de auditoría y el de consultoría, especial-
mente en determinados tipos de auditoría que más adelante identificare-
mos.
Finalmente, si nos centramos en la fase principal del proceso de auditoría, la

realización práctica de una auditoría, se ha de tener siempre en cuenta que las
pruebas deberán ser relevantes para el objetivo de la auditoría. Tendrán que ser
seleccionadas de la manera más adecuada para proporcionar la información
necesaria a la hora de emitir una conclusión. La experiencia técnica permiti-
rá a un auditor escoger y realizar las pruebas más adecuadas, facilitando así
la interpretación de resultados y la obtención de evidencias. La elección de
pruebas útiles en este sentido es lo que marcará, en cierto modo, la pericia de
un auditor y lo distinguirá frente a otro. Este es el punto diferenciador que
permitirá a un auditor ser más eficiente en términos de costes y resultados,
puesto que no olvidemos que la función de auditoría también rinde cuentas
económicas en la organización en que se encuadre.
3.1. Tipos de pruebas
El auditor podrá realizar diferentes tipos de pruebas basándose en criterios

técnicos respecto de la materia que está auditando. Sin embargo, desde un
punto de vista más teórico, es interesante destacar que al auditor se le plantea
la posibilidad de realizar dos tipos de pruebas:
• Pruebas de cumplimiento o de controles. Se trata de procedimientos de

auditoría que se diseñan con la finalidad de comprobar la efectividad y el
cumplimiento del auditado con la normativa que describe el control sobre
el proceso que se está auditando. Es decir, buscan obtener evidencias de
que los controles internos están funcionando.
• Pruebas sustantivas o de detalles. Tienen una finalidad más práctica y sue-

len ser necesarias cuando no es suficiente con las pruebas de cumplimien-
to. Estas pruebas buscan detectar de manera afirmativa debilidades de los
controles que están materializadas. Es decir, se buscan evidencias de cómo
el proceso que se quiere controlar es realizado, de su integridad y del mo-
do en que los controles consiguen realmente sus objetivos. Con este tipo
de pruebas más concretas, se obtienen no sólo las evidencias del cumpli-
miento de los controles, sino también las evidencias de su eficacia. Este
tipo de pruebas son más costosas y difíciles de realizar, puesto que pueden
implicar que el auditor deba realizar tareas que habitualmente se llevan a
cabo de manera automática y que tal vez tenga que repetir verificaciones
o cálculos relativos a una muestra de datos o de registros para dar fe de
que los procesos de control implantados coinciden con lo que él realiza
fuera del sistema de control.
Es decir, la prueba de cumplimiento busca comprobar si se implementan los

controles tal y como se recoge en la normativa de referencia (puede ser interna
a la organización auditada, o bien externa, como una ley, un reglamento, etc.).
Si los resultados de este tipo de pruebas son satisfactorios, puede hacerse in-
necesaria la realización de pruebas sustantivas, las cuales son inherentemente
más costosas y complejas.
Debe tenerse en cuenta, sobre todo en las pruebas sustantivas, que puede re-
sultar poco práctico o directamente inabarcable realizar una comprobación
exhaustiva o completa. En muchos casos, se impone la necesidad de seleccio-
nar sólo unas cuantas comprobaciones. Esta selección es lo que se denomina
muestreo.
3.2. Muestreo
El muestreo se usa cuando las consideraciones de tiempo y de costo impiden la

verificación completa y total requerida por una prueba sustantiva. En algunas
circunstancias, en una prueba de cumplimiento puede imponerse también la
necesidad de realizar un muestreo. Éste resulta necesario cuando no se tienen

suficientes recursos para realizar las pruebas sobre todos los elementos que se
deberían analizar.
Cuando nos referimos a procesos de muestreo, denominamos población a la

totalidad de los elementos que se deben examinar para realizar las pruebas.
Cualquier subconjunto de esta población se denomina muestra. El muestreo
es un proceso estadístico conocido y usado para inferir características de una
población en base a la observación de un subconjunto representativo y en
el contexto de la auditoría, sería igualmente obtener un subconjunto de ele-
mentos representativos que, al aplicar las pruebas diseñadas por el auditor, le
permita obtener una conclusión con un cierto nivel de confianza en que los
objetivos de la auditoría se hayan alcanzado. Existe, por tanto, un riesgo in-
herente de la auditoría por el hecho de realizar muestreos.
El muestreo se puede afrontar de dos modos:
• Muestreo estadístico. Es el enfoque más objetivo y más científico, y emplea

las técnicas de las matemáticas estadísticas para calcular el tamaño de las
muestras, seleccionar los objetos de la muestra, evaluar los resultados de
la muestra, y decidir cuantitativamente (con un porcentaje de error) el
grado en que los resultados de la muestra representan a la población total.
Para que un muestreo sea estadístico, cada uno de los elementos de la
población tiene que tener la misma probabilidad de ser seleccionado para
formar parte de la muestra. En los casos en los que se evalúen aspectos
cuantificables, el auditor deberá dominar conceptos estadísticos como:
– Coeficiente o nivel de confianza
– Precisión
– Tasa de error esperado
– Media de la muestra
– Desviación estándar de la muestra
– Tasa tolerable de error
– Desviación estándar de la población
Un parámetro importante que se debe conocer en el caso de aplicarse este

tipo de muestreo es el nivel de riesgo muestral (o también se habla de nivel
de confianza aceptable, que es el 100 % menos el nivel de riesgo muestral)
que el auditor estará dispuesto a aceptar. Este nivel de riesgo muestral es
un porcentaje que refleja el porcentaje de muestras que no reflejarían los
valores reales (por las razones que fueran) si se examinara el 100 % de la
población.
En el entorno de las auditorías relacionadas con la informática, se dan con
relativa poca frecuencia este tipo de muestreos, debido a las características
de las pruebas a realizar o la dificultad extrema de aplicar técnicas estadís-
ticas.
• Muestreo no estadístico o también denominado basado en un criterio. En
este caso, el método de muestreo, el tamaño de la muestra y la selección
de la muestra queda a criterio del auditor, en base a su experiencia y punto

de vista subjetivo. A pesar de ser más subjetivo, resulta más práctico.
En cualquier caso, el proceso que tiene que desarrollar el auditor es:
• Determinar los objetivos de la prueba.

• Definir la población de la que se obtendrá la muestra.
• Determinar el método de muestreo.
• Calcular el tamaño de la muestra.
• Seleccionar la muestra.
• Evaluar la muestra desde la perspectiva de la auditoría.
Este proceso puede conllevar errores, puesto que se sacará una conclusión en
base a una muestra. Sin embargo, estos errores son conocidos por el auditor y,
si la muestra se ha realizado estadísticamente, pueden ser incluso medidos.
3.3. Evidencias de auditoría
La evidencia es cualquier información usada por el auditor para determinar si

algún aspecto del proceso auditado cumple con los criterios de auditoría. Asi-
mismo, la confrontación de las evidencias de auditoría con los criterios permi-
te al auditor concluir si se ha realizado un hallazgo de auditoría. Finalmente,
a la vista de la totalidad de los hallazgos realizados, el auditor podrá emitir un
juicio y dar una conclusión que dé respuesta al objetivo de auditoría.
Por tanto, la importancia de las evidencias es clara. Todo el proceso de audi-

toría se reduce a la realización de pruebas para la recogida de evidencias.
Las evidencias serán cuantitativas o cualitativas, y pueden ser de muchos tipos.

Todo ello dependerá, principalmente, de la naturaleza del tema auditado, pero
las evidencias pueden tratarse de:
• Observaciones del auditor realizadas durante una visita y se pueden mate-

rializar mediante soporte fotográfico.
• Información recogida en entrevistas y plasmada en actas de entrevistas.
• Documentación (contratos, registros, formularios, etc.) que el auditado fa-

cilita al auditor (ya sea porque fue identificada con antelación a la realiza-
ción de las visitas o entrevistas o bien porque haya sido identificada du-
rante estas y se facilita posteriormente).
• Resultados de pruebas de auditoría que pueden tener a su vez formas muy

variadas, aunque cada vez más tendrán un soporte informatizado (archivos
informáticos, resultados de la ejecución de algún programa informático
que ayude a la auditoría).
Como hemos visto, la evidencia es la piedra angular del trabajo del auditor y,
por lo tanto, debe cumplir con ciertas características:
• Confiabilidad. La confianza en la información facilitada por una eviden-

cia dependerá de la forma en que ésta se obtenga. Por lo tanto, para que la
confiabilidad en la evidencia sea lo más elevada posible, se deberá evaluar:
– La independencia de la fuente que proporciona la evidencia. Puede
tratarse de una persona o bien de un sistema de información. En am-
bos casos, es lícito evaluar la independencia de la persona en base a
sus relaciones con el auditado o, si es interno, con el área auditada.
En cuanto a un sistema de información, el auditor deberá evaluar la
posibilidad de que haya sido adulterado.
– La objetividad de la evidencia. Cuanta menos interpretación requiera

una evidencia, mayor será su confiabilidad.
– Tiempo de disponibilidad de la evidencia. El auditor deberá asegurarse

de que la evidencia esté disponible para futuras comprobaciones y, en
caso de que pueda destruirse, realizará las copias de manera confiable.
• Relevancia. El auditor se encontrará frente a varias evidencias, pero no

todas serán igual de relevantes para cubrir los objetivos de la auditoría. El
auditor únicamente debería tener en cuenta aquellas que sean relevantes,
y descartar o no considerar de igual modo aquellas que sean relevantes de
manera tangencial.
• Suficiencia. En ciertas evidencias que se basan en la cantidad (por ejem-

plo, número de registros no válidos en una base de datos después de haber
realizado una determinada prueba), será necesario disponer de una canti-
dad suficiente para poder determinar que se ha realizado un hallazgo. Ade-
más de disponer de una cantidad suficiente, la evidencia deberá estar ba-
sada en hechos objetivos y deberá permitir a un observador correctamente
informado llegar a la misma conclusión que el auditor. Sólo en este caso, la
evidencia podrá ser considerada como suficiente. Como se ve, la suficien-
cia no está exclusivamente relacionada con la cantidad, aunque puede ser
necesario que la cantidad esté presente para obtener la suficiencia.
• Competencia. Además de suficiencia, toda evidencia debe tener también

la característica de competencia. Se entiende por competencia la caracte-
rística de calidad de la evidencia, es decir, su capacidad para permitir al
auditor determinar si ha realizado o no un hallazgo de auditoría. A veces,
se decide que una evidencia es competente cuando es válida, relevante y
confiable.
3.4. Hallazgo de auditoría
Las evidencias que cumplan las características de suficiencia y competencia se

confrontarán contra los criterios de auditoría para determinar si se ha realizado
un hallazgo o no y de qué tipo. Es importante destacar que en este proceso de
confrontar evidencias con criterios.
Los hallazgos resultan pues de clasificar las evidencias como:
• No conformidades (puede existir algún tipo de nivel de gradación, por

ejemplo, en las auditorías de certificación que se tratarán más adelante en
el curso, se dividen en graves y menores) cuando el hallazgo pone en evi-
dencia que en el proceso auditado no se cumple alguno de los criterios de
control de la auditoría, ya sea porque no existe control, no se ha imple-
mentado con arreglo al criterio de auditoría o no es eficaz.
• Observaciones. Cuando el auditor tiene puntos de interés que quiere pre-
sentar, pero no suficiente evidencia para emitir una no conformidad, pue-
de presentar observaciones.
• Posibilidades de mejora. Puede que el control sobre el proceso sea eficaz,
pero no tan eficiente como podría serlo. En este caso, el auditor podría
facilitar alguna observación para mejorarlo, siempre con mucha atención,
sobre todo en auditorías de terceras partes o cuando estas observaciones
no sean una consulta o asesoría encubierta, lo que afectaría a su posterior
independencia.
• Conformidades. Confirman que el criterio de auditoría se cumple. En la
práctica no se presentan de manera detallada, sino como simples puntos
fuertes del sistema de control del proceso auditado.
3.5. Riesgo de auditoría
La tarea de determinar cuándo una o varias evidencias respaldan un hallazgo

(que llevará a unas conclusiones de auditoría) conlleva un riesgo inherente de
error. Es el riesgo de que el auditor concluya de manera errónea, en cualquiera
de los sentidos, tanto positivo respecto a que el criterio se respeta, como todo lo
contrario. El auditor debe conocer este riesgo, denominado riesgo de auditoría.
Intervienen muchos factores que inciden en este riesgo de auditoría:
• El�muestreo. Se trata de una actividad que se realizará prácticamente en

todas las asignaciones de auditoría a las que se enfrente un auditor en su
carrera profesional. El muestreo puede deberse a una planificación muy
ajustada, a una falta de recursos o sencillamente al hecho de enfrentarse a
un número total y potencial de pruebas a realizar totalmente desorbitado.
• Evaluación�errónea�de�la/s�evidencia/s. Ya sea por falta de experiencia,

o porque la evidencia resultó no ser confiable, existe la posibilidad de que
el auditor interprete incorrectamente la evidencia.
• Falta�de�suficientes�evidencias.
En todos los casos, el auditor deberá ser consciente de los riesgos y reconocer
que existe un riesgo de error al emitir su juicio de auditoría. Pero, de todos
modos, el hecho de realizar la auditoría ajustándose a planes de trabajo, si-
guiendo metodologías reconocidas y respetando los códigos éticos de la pro-
fesión, da garantías al auditor a la hora de valorar los hallazgos y emitir sus
conclusiones. Y además, el auditor debe reconocer esta posibilidad, en especial
cuando se haya realizado un muestreo muy agresivo, y dejarla reflejada en su
informe final de auditoría.
4. Programa de auditoría
Hasta ahora, hemos estado hablando de auditoría como una actividad aislada
que se realiza una única vez, o quizá más veces, pero sin existir un objetivo
estratégico para la actividad general de auditoría ni unas relaciones entre varias
auditorías.
En muchas ocasiones, las organizaciones sólo se plantean esta actividad de

auditoría en momentos puntuales, sobre todo cuando se trata de auditorías de
segundas o terceras partes. En estas situaciones, el cliente encarga la auditoría
en un momento dado y, una vez ejecutada, adopta las acciones que tenga
previstas y la relación con el auditor finaliza aquí o a lo sumo existe una fase
final de seguimiento en la que los auditores verifican si las no conformidades
se han resuelto o no.
Sin embargo, una organizació obtiene las mayores fortalezas y beneficios de

la labor de auditoría cuando éstas se suceden en el tiempo de manera planifi-
cada, organizadas con arreglo a una estrategia general, y si tiene recursos su-
ficientes, con un equipo auditor propio (completo o externalizado parcial o
totalmente, pero coordinado por alguien interno). En estas situaciones se di-
ce que la organización implanta la "función de auditoría" y que esta organiza
su actividad con arreglo a lo que se denomina un programa de auditoría. Los
beneficios que se pueden obtener de implantar un programa de auditoría son
los siguientes (más adelante se detallan en un apartado específico):
• Los equipos de auditoría pueden planificar mejor el esfuerzo y la asigna-

ción de recursos.
• Se facilita la consistencia de las actuaciones de los equipos auditores, se

refinan sus técnicas y se mejora así su capacitación. De esta manera, se
aumenta la calidad del trabajo, disminuyen los errores y se optimiza el
tiempo dedicado a la realización de pruebas.
• Se maximizan los recursos y se obtienen mejores resultados.
• Se consigue un seguimiento correcto del nivel de mejora continua de los

procesos auditados.
Estos programas suelen surgir en organizaciones en las que los sistemas de

gestión están ampliamente implantados y entendidos. Por lo tanto, es muy
habitual encontrarnos con programas de auditorías tanto de primera como de
terceras partes en el contexto de sistemas de gestión de la calidad, medioam-
biental, o también de seguridad de la información, aunque también podrían

darse para realizar auditorías de segunda parte o de proveedores si la organi-
zación, de manera recurrente, evalúa a sus proveedores.
Existe una relación entre los programas de auditoría y los sistemas de gestión.
Los sistemas de gestión están basados en la implantación de un proceso con-

tinuo de mejora que suele ser conocido como ciclo PDCA (o ciclo de Deming
o Shewhart). El ciclo PDCA está formado por cuatro procesos que se van repi-
tiendo de forma iterativa para el control de un sistema: planificar, implemen-
tar (para llevar a cabo lo planificado), comprobar (para analizar el funciona-
miento de lo implantado) y actuar (en base a la revisión realizada).
En este ciclo, es necesaria la realización de auditorías de primera parte en la

fase comprobar. Por otra parte, puesto que este ciclo PDCA se debe realizar
continuamente para garantizar el correcto control del proceso en cuestión, la
realización de auditorías es también continua. Estas auditorías no se realizan
de manera independiente unas de otras, sino que más bien son organizadas
por los responsables de gestionar la función de auditoría en la organización.
Es en este contexto donde se crean programas de auditoría, que son el marco
por el que se gestiona la función de auditoría, de un modo similar a cualquier
otro sistema de gestión, pero con un objetivo más concreto. Aunque más ade-
lante se ampliará en el apartado de implementación, de manera general este
programa incluye:
• Los objetivos generales del programa y de las principales acciones de au-

ditoría, es decir, qué se pretende conseguir con el programa de auditoría.
• La planificación de las auditorías para un periodo de tiempo. Aunque en

conjunto todo tiene un objetivo general, la labor de auditoría puede sepa-
rarse temporalmente y cada auditoría planificada tendrá un objetivo espe-
cífico o más.
• Los procedimientos para operar todos los aspectos del programa.
• Los criterios de auditoría.
• Los métodos y las técnicas de auditoría.
• La gestión de los equipos de auditores (selección y capacitación).
• La gestión de los aspectos logísticos y presupuestarios.
En este punto es importante no confundir el concepto de programa de audi-

toría que aquí se describe, alineado con la concepción del mismo que se aplica
en las entidades de certificación y reflejada en la norma ISO/IEC 19011, con lo
que se entiende por programa de auditoría en otros ambientes como ISACA.
En ese entorno, los programas de auditoría son procedimientos más detallados

para la auditoría de aspectos concretos de control de algún tipo de proceso.
Mediante una consulta al website de ISACA, en el apartado de "Audit/Assuran-
ce Programs" el lector podrá comprobar esta diferencia de concepto.
4.1. Beneficios de implementar un programa de auditoría
Dentro de este contexto, los responsables de auditoría tienen la posibilidad de

obtener ciertos beneficios de desarrollar este programa:
• Los programas de auditoría pueden asistir a los gestores de la función de

auditoría en la planificación del esfuerzo y la asignación de recursos. Por
ejemplo, la gerencia dispondrá de información previa para poder estimar el
esfuerzo requerido para realizar una auditoría basándose en la cantidad de
tiempo dedicado en anteriores auditorías. De este modo, la organización
podrá proveer partidas presupuestarias realistas.
• Se promueve la consistencia en la manera de actuar de los auditores y per-

mite ir refinando las técnicas e ir mejorando la capacitación del personal
auditor, lo que redunda en una mejor calidad del trabajo (menos errores
de auditoría, posibilidad de comparar resultados de distintas auditorías en
el tiempo). Durante la planificación y la preparación para una auditoría,
los materiales (guías, listas de comprobación, herramientas, equipos espe-
cíficos, etc.) usados durante anteriores asignaciones pueden ser empleados
generalmente como la base para los pasos que se realizarán durante la ac-
tual. Esto no se aplica, obviamente, en los casos en que se audite un pro-
ceso que nunca antes se ha revisado, o donde el proceso ha cambiado per-
ceptiblemente. En estos casos, los materiales deben ser creados desde cero.
• Se maximizan los recursos de auditoría y se permite obtener mejores re-

sultados. Distribuyendo en el tiempo distintas auditorías, se pueden pla-
nificar mejor los recursos. Por ejemplo, si parte de las pruebas de determi-
nadas auditorías del programa que se realiza contando con expertos inter-
nos, el programa de auditoría ayudará a planificar la disponibilidad de los
mismos, si es que estos no desarrollan permanentemente sus labores pro-
fesionales en la función de auditoría.
Más allá de los comentados beneficios, una organización que necesite realizar
auditorías continuas para verificar los controles aplicados a un proceso debería
implementar y gestionar un programa de auditoría efectivo. El propósito de
un programa es planear el tipo y número de auditorías, e identificar y sumi-
nistrar los recursos necesarios para realizarlas. El programa de auditoría puede
incluir auditorías con una gran variedad de objetivos, establecerse más de un
programa de auditoría, y el número de auditorías que contenga el programa
dependerá mucho del tamaño, naturaleza y complejidad de la organización
por auditar.
Programas de auditoría para mediana empresa
Por ejemplo, una organización de un tamaño medio (por encima de las 100 personas)
que tuviera implantado un sistema para la gestión de la seguridad de la información
podría plantearse los siguientes programas de auditoría, para revisar de manera continua
los principales puntos de su sistema:
• Verificación anual de la conformidad del sistema con la Norma ISO27001:2005.

• Auditorías trimestrales del funcionamiento de los controles de seguridad lógica.
• Auditoría anual del estado de los controles de seguridad física.
• Revisión anual del plan de continuidad y de sus pruebas.
• Auditoría bienal de protección de datos de carácter personal (en España).
4.2. Establecimiento de un programa de auditoría
La forma de implementar y gestionar un programa de auditoría que hemos

repasado no difiere de la implantación de cualquier otro sistema de gestión
que pretenda controlar una actividad, en este caso la actividad de la función
de auditoría. El sistema debe poner en valor tanto las fases que se planifican
y las que se ejecutan, como las posteriores fases de revisión de la ejecución
y extracción de conclusiones. Implantar un programa de auditoría no es más
que aplicar un ciclo de gestión PDCA (Deming) a la función de auditoría de
una organización, lo cual nos permite ver el proceso de gestión del programa
de auditoría como un ciclo que se refleja en el siguiente diagrama, inspirado
en la descripción dada en la norma ISO/IEC 19011:2011.
Diagrama general de la gestión de un programa de auditoría
Tal y como puede verse, la gestión de un programa de auditoría es un proceso

que va más allá de simplemente planificar las auditorías que se van a realizar
a lo largo de una determinada ventana de tiempo. Se trata, más bien, de un
sistema de gestión que pretende controlar de manera continua el proceso de
auditoría. Por lo tanto, sería lógico que se integrara con los procesos que pre-
tende verificar y que siguen la misma filosofía de gestión, como podría ser la
gestión de la calidad, la gestión medioambiental, la gestión de los sistemas de
información, o de la seguridad de la información. Integrar la auditoría con los
distintos sistemas de gestión de una organización ayuda a incrementar su efi-

cacia y eficiencia, puesto que gran parte del conocimiento necesario (todo lo
relativo a las generalidades de la auditoría y de la gestión del programa) es co-
mún y controlado por unos mismos responsables. Esto conlleva la necesidad
de que estos sistemas de gestión implementen una nueva función organizati-
va: la de auditoría (también se suele denominar control interno). Esta función
tendrá como objetivo realizar todos los procesos que permitan comprobar que
se están aplicando los controles internos sobre el resto de los procesos de la
organización.
En el caso que se decida crear una función de auditoría para que gestione
un programa de auditoría, la dirección de la organización debería oficializar
esta función, y dotarla de autoridad para dirigir el programa de auditoría e
implementar un sistema que ejecute las fases descritas en el diagrama.
Los responsables del programa de auditoría tendrán que planificar y dirigir el

proceso de auditoría continua en la organización. Por lo tanto, deberán:
1) Establecer los objetivos y la extensión del programa de auditoría. Estos ob-

jetivos se pueden basar en:
• Estrategia y prioridades de la dirección.

• Requisitos del sistema de gestión (si los controles a auditar se encuentran
certificados).
• Requisitos reglamentarios o contractuales.
• Necesidad de evaluación de proveedores.
• Requisitos de los clientes.
• Necesidades de las partes interesadas.
• Riesgos potenciales para la organización.
La extensión o el alcance de un programa de auditoría puede variar, tal y como

hemos dicho, por varios factores:
• El alcance, el objetivo y la duración de cada auditoría.

• La frecuencia de las auditorías.
• El tamaño, la naturaleza y la complejidad de la organización auditada.
• El número, la importancia, la complejidad, la similitud y la ubicación de
las actividades por auditar.
• Normas, requisitos reglamentarios y contractuales, y otros criterios de au-
ditoría.
• Necesidad de acreditación o certificación/registro.
• Los resultados de las auditorías previas o la revisión del programa de au-
ditoría previo.
• Aspectos lingüísticos, culturales y sociales.
• Preocupaciones de las partes interesadas.
• Cambios significativos para una organización o sus operaciones.
Todos estos factores pueden variar incluso durante el periodo de tiempo en

que se está ejecutando un programa, por lo que es necesario que el programa
sea gestionado de manera continua. Más adelante, veremos algunos aspectos
relacionados con la gestión continua del mismo.
2) Establecer las responsabilidades. Las personas a quienes se asigne la respon-

sabilidad de dirigir el programa de auditoría habrán de definir, implementar,
hacer seguimiento, revisar y mejorar el programa de auditoría. Además, desde
el punto de vista del día a día, deberán identificar y suministrar los recursos
para el programa de auditoría.
Es por ello que la responsabilidad de la gestión de un programa de auditoría

debería asignarse a una o más personas con las siguientes características:
• Conocimientos generales de los principios de la auditoría.
• Conocimiento de la competencia de los auditores disponibles en los con-

ceptos generales de auditoría y en la aplicación de técnicas de auditoría,
así como en los aspectos técnicos que hayan de auditar.
• Habilidades para la gestión.
• Conocimientos técnicos y del negocio pertinentes para las actividades que

van a auditarse.
3) Estimar y planificar los recursos necesarios. A la hora de determinar los re-

cursos necesarios para la implementación del programa, los responsables de-
berían considerar aspectos como los siguientes:
• Los recursos financieros necesarios para el desarrollo, la implementación,

la gestión y la mejora de las actividades de auditoría. Para presupuestar
correctamente el programa, es necesario que dispongan de conocimientos
sobre gestión de recursos y toda información de pasados programas que
pudiera existir.
• Las técnicas de auditoría que se deberán aplicar, puesto que puede que los
auditores no dispongan de la capacitación necesaria y/o de las herramien-
tas o técnicas necesarias.
• Los procesos para lograr y mantener la competencia de los auditores, y

mejorar la calidad y rendimiento del trabajo de éstos.
• La disponibilidad de los auditores y expertos técnicos que posean la com-

petencia apropiada para los objetivos del programa de auditoría particular.
• La duración prevista de las auditorías.

• Los tiempos de desplazamiento, el alojamiento y otras necesidades logís-

ticas durante la realización de la auditoría.
4) Asegurar la implementación del programa de auditoría. La implementación

del programa de auditoría va más allá de la simple ejecución de las auditorías
que se han programado. Estas tareas implican gestionar y controlar la función
de auditoría realizando las siguientes tareas:
• Comunicar el programa de auditoría a las partes pertinentes. Existe una

labor necesaria de comunicación y divulgación a la dirección de los obje-
tivos generales del programa y de los específicos de cada una de las audi-
torías.
• Preparar material para facilitar la realización de las auditorías (procedi-

mientos, listas de comprobaciones, plantillas de informes, procedimientos
de evaluación de la calidad de la labor de auditoría, planes de desarrollo
de los auditores, etc.).
• Coordinar y programar las auditorías y otras actividades del programa de

auditoría. Es decir, controlar el proceso de ejecución de las distintas partes
del programa:
– Planificación y asignación de los recursos a los distintos equipos au-
ditores.
– Control de ejecución de acuerdo con los objetivos del programa.
– Evaluación de las auditorías. Este aspecto vendría a ser la "auditoría"

de la ejecución de la auditoría.
– Revisión de los informes de auditoría y comunicación a los clientes y

partes interesadas.
– Asegurar que se realizan las acciones complementarias de la auditoría,

en el caso de que sean aplicables (por ejemplo, revisiones o nuevas
auditorías después de periodos de corrección de no conformidades).
• Establecer y mantener un proceso para la evaluación inicial y progresiva de

los auditores. Este proceso evaluará sus necesidades de formación y desa-
rrollo profesional, de modo que sean competentes en la materia y se vaya
adecuando su capacitación a las circunstancias evolutivas de los mercados.
Durante la ejecución de un programa de auditoría, en una organización, exis-

te la posibilidad de que dos o más organizaciones auditoras puedan cooperar
en la realización de una auditoría conjunta. En este caso, se debería prestar
atención especial a la división de responsabilidades, el suministro de recursos
adicionales, la competencia adicional necesaria en el equipo de auditoría y los

procedimientos apropiados. Se debería llegar a un acuerdo sobre estos proce-
dimientos y otros aspectos de orden práctico antes de comenzar la auditoría.
5) Hacer seguimiento, revisar y mejorar el programa de auditoría. El programa

de auditoría necesita un mantenimiento continuo para adecuarlo a cambios
en la organización, las tecnologías o, simplemente, a las conclusiones que se
saquen respecto a cómo se está desarrollando. Por lo tanto, es recomendable
que, a intervalos apropiados, se realice una revisión del programa para evaluar
si sus objetivos se han cumplido, y para identificar oportunidades de mejora.
Ejemplos de seguimiento
Este seguimiento se puede realizar, por ejemplo, midiendo y revisando:
• La capacitación de los equipos auditores para implementar el plan de auditoría. Para

ello, se deberá tener un control sobre el modo en que han desarrollado sus activida-
des, su formación actual y los cambios en el entorno que no queden cubiertos por
las capacidades actuales de los auditores.
• La conformidad de la ejecución de las auditorías con las previsiones de los programas

y cronogramas previstos para cada auditoría.
• La satisfacción de los clientes de la auditoría, de los auditados y de los auditores.
Estos indicadores deben servir para identificar los puntos de mejora del programa de
auditoría y para diseñar las acciones correctivas que permitan alinear mejor el programa
de auditoría con las necesidades del cliente.
5. Estandarización de la labor de auditoría
Ya hemos visto que una de las principales características del proceso de audi-
toría tiene que ser la objetividad y la sistematización del proceso. Esto permite
que las conclusiones de la auditoría sean independientes de la subjetividad del
auditor. Estas dos características hacen que sea posible plantearse describir la
tarea de auditoría desde un punto de vista teórico o independiente del ámbito
concreto auditado. Por lo tanto, es posible dar ciertos parámetros, aspectos y
elementos que son comunes a cualquier ámbito auditado, o al menos que lo
son dentro de un cierto ámbito muy general.
Esta posibilidad de uniformizar las características del proceso de auditoría se

encuentra reflejada en el hecho de que existen estándares cuyo objetivo es
dar las guías de cómo debe realizarse la labor de auditoría para preservar las
características de objetividad y sistematización del proceso.
La realidad es que el conjunto de estándares es muy amplio. La labor de audi-

toría en un sector ha conllevado casi siempre la publicación de estándares de
auditoría aplicables al menos en su sector, y a veces extensibles a otros. Estos
estándares son publicados por parte de entidades con más o menos prestigio
en su sector y con capacidad para imponer sus estándares.
Podemos destacar algunos de los organismos que más actividad normativa

han realizado en el tema de la auditoría.
5.1. IAASB y AICPA (American Institute of Certified Public

Accountants)
El IAASB (International Auditing and Assurance Board) es un organismo in-

ternacional que agrupa entidades públicas y privadas del sector de la auditoría
financiera fundamentalmente y que elabora estándares, guías de buenas prác-
ticas y otros servicios para apoyar la labor de auditoría financiera. El AICPA es
la asociación norteamericana de los auditores públicos de cuentas, aunque no
todos sus miembros son auditores públicos de cuentas.
Aunque el ámbito de la auditoría de cuentas no es el que nos ocupa, merece la

pena destacar la actividad tanto del IAASB como del AICPA, tanto por la larga
historia de labor de estandarización que ha realizado como por ser el AICPA
la iniciadora, en parte, de la auditoría de sistemas de información.
La función fundamental de este tipo de organizaciones es promover la profe-

sión de la auditoría de cuentas. Para lograr esto, tiene una variedad de funcio-
nes, entre las cuales nos interesa la de elaboración de estándares profesionales
para la auditoría del estado de cuentas y otros tipos de auditorías financieras o
relacionadas. Existe un gran número de estos estándares. Entre los estándares

que publica el AICPA, es interesante destacar los siguientes por tener relación
con la auditoría de sistemas de información:
• SAS55 (enmendado por SAS78) "Consideration of Internal Control in a

Financial Statement Audit". Este estándar requiere al auditor obtener un
conocimiento y comprensión de los mecanismos de control interno de
una entidad que le permita, primero, planificar una auditoría y, segundo,
identificar los controles más relevantes y evaluarlos posteriormente. En
este contexto, debe tenerse en cuenta que la normativa financiera exige
que se realicen ciertas provisiones para prever riesgos operacionales, en-
tre los que se incluyen los riesgos que introduce el tratamiento de datos
financieros mediante sistemas de información. Por lo tanto, la evaluación
de los controles internos, para garantizar la corrección de las cuentas y la
inexistencia de errores o fraudes, debe por fuerza incluir la auditoría de los
sistemas de información.
• SAS70 (enmendado por SAS78) "Reports on the Processing of Transactions

by Service Organizations" o también conocido como "Service Organiza-
tions". Se entiende como "Service Organizations" organizaciones que pres-
tan un servicio al auditado relevante para su sistema de control interno. Es
decir, se trata de organizaciones que ofrecen servicios (muy habitualmen-
te, los sistemas de información) externalizados por otras organizaciones,
los cuales son relevantes para la exactitud de las cuentas. Por lo tanto, el
SAS70 será aplicable en escenarios como: proveedores de comunicaciones,
proveedores de aplicaciones como un servicio totalmente externalizado
(se le conoce como modo ASP: Application Service Provider, o también
como SaaS: Software as a Service), servicios de seguridad gestionada (tanto
lógica como física), etc.
El SAS70 define los estándares que debe seguir un auditor para la compro-
bación de los controles internos en una organización que presta servicios
externalizados por otras. Asimismo, define la forma que debe cumplir el
informe de auditoría que se genere para que pueda ser utilizado en otra
auditoría en la organización que ha externalizado el servicio.
La relevancia de este estándar proviene de la necesidad de cumplir con el
SAS55 (y SAS78), que obliga a que cada auditoría en una organización in-
cluya también una auditoría en las organizaciones donde se ha externali-
zado un servicio. El cumplimiento de este estándar implicaría innumera-
bles auditorías en las organizaciones proveedoras de servicios. Para evitar
esto y reducir los costes de las auditorías, el SAS70 da las directrices sobre
la realización y el reporte de las auditorías en organizaciones de servicios,
para que sus resultados puedan ser comunicados y utilizados por las orga-
nizaciones que externalizan el servicio.
• SAS94 "The effect of Information Technology on the Auditor's Conside-

ration of Internal Control in a Financial Statement Audit". Este estándar
obliga al auditor a poner especial atención en el papel que juegan los sis-
temas de información en el proceso de control del estado financiero de

una entidad.
• SSAE 18 / ISAE 3402 (reemplazaron mayoritariamente SAS78). Estos están-

dares, muy similares (el primero, elaborado por el AICPA y de relevancia en
el ámbito de los Estados Unidos; y el segundo, desarrollado por el IAASB,
aplicado para el resto del mundo), definen los procesos de auditoría a apli-
car en proveedores de servicios. Los reportes de auditoría generados en
base a estos estándares tienen como objetivo proporcionar a los clientes
de estos proveedores de servicios y a los auditores financieros de la infor-
mación necesaria y relevante sobre las políticas, procedimientos y, en ge-
neral, los procesos de control que aplica el proveedor para garantizar a sus
clientes la exactitud del procesado de transacciones (en general, del servi-
cio que presta), y esto contempla, por lo tanto, la seguridad de la infor-
mación. Las auditorías realizadas tomando estos estándares son completa-
mente de tercera parte, y los reportes de auditoría que genera son puestos a
disposición del cliente según sus necesidades. De este modo, el cliente del
proveedor y su auditor obtienen un conocimiento y un entendimiento de
los controles de seguridad que está aplicando el proveedor en los aspectos
que les puedan afectar, y podrían excluir, por lo tanto, el hecho de realizar
una auditoría completa al proveedor. Típicamente estas auditorías pueden
generar tres tipos de informes denominados “SOC Report” (Service Orga-
nization Control Report). El primer tipo es básicamente una declaración
de los controles que son de relevancia para la auditoría financiera, mien-
tras que los reportes SOC2 y SOC3 son más específicos y aplicables en el
ámbito de la seguridad de la información. Los informes SOC2 se centran
más en ciertos puntos de referencia predefinidos y estandarizados para los
controles relacionados con la seguridad, la integridad del procesamiento,
la confidencialidad o la privacidad del sistema y la información de los cen-
tros o servicios de procesamiento de datos. La evaluación se basa en los
siguientes cinco principios de seguridad:
– Protección: ¿existe suficiente protección contra el acceso no autoriza-
do?
– Disponibilidad: valor esperado del tiempo de actividad de un sistema
al agregado de valores esperados de tiempo de actividad y de inactivi-
dad. Más fácil: ¿hasta qué punto puedo confiar en el sistema?
– Integridad del proceso: ¿el procesamiento del sistema cumple con los
objetivos de la entidad, es decir, completo, válido, exacto, oportuno
y autorizado?
– Confidencialidad: ¿la información designada como confidencial está
protegida para cumplir con objetivos de la entidad?
– Privacidad: ¿se recopila, utiliza, conserva, divulga y elimina la infor-
mación personal para cumplir con los objetivos de la entidad?
Y el reporte SOC3 es más de alto nivel y puramente declarativo, y sim-

plemente certifica la excelencia y corrección del sistema de controles del
proveedor.
Como se puede observar, el grado de detalle que ofrecen los estándares del
AICPA y el IAASB es muy elevado. Llega incluso a puntos tan concretos como
indicar qué tipo de contenido debe estar incluido y en qué apartados especí-
ficos de un tipo de informe particular.
Debido a su exhaustividad y complejidad, estos estándares han sido habitual-

mente aplicados en Estados Unidos. Más concretamente, se han aplicado en
el ámbito de auditorías financieras y de cumplimiento con normativa legal
también del sector, como por ejemplo la Sarbanes-Oxley Act. Su uso no se ha
extendido tanto en España. Sin embargo, ya comienza a ser habitual encon-
trarlo debido a la internacionalización de las actividades de las organizaciones
y también en el ámbito de los grandes proveedores de procesado de informa-
ción como son los proveedores de computación en la nube (Cloud Compu-
ting) como pueden ser Amazon Web Services, Azure o Google Cloud Platform.
Estos grandes proveedores de servicios en la nube facilitan en sus sitios web
evidencia de la realización de este tipo de auditorías.
5.2. ISO (International Organization for Standarization), las

entidades de certificación y de acreditación
Como ya hemos comprobado en el apartado anterior, existen organizaciones

que tienen un gran control sobre el trabajo que se realiza con arreglo a sus
estándares. En el otro extremo, se encuentran organizaciones que dan guías,
buenas prácticas y estándares relevantes para el proceso de auditoría, pero con
un afán de ser más universales. Entre ellas, se encuentra la ISO (Internacional
Organization for Standarization), que ha desarrollado al respecto ciertas nor-
mas que son de nuestro interés.
Dentro del ámbito de la certificación de sistemas de gestión de calidad (ISO

9001) y medio ambiental (ISO 14001), ISO ha realizado un esfuerzo extra para
sistematizar la auditoría de los mismos. Por ello, se ha definido un estándar
que da las directrices para la auditoría de los sistemas de gestión de la calidad
y ambiental, la Norma ISO 19011. Aunque esta norma se ha desarrollado ini-
cialmente para la auditoría de esos tipos de sistemas de gestión, sus directrices
se pueden ampliar a las auditorías de otros tipos de sistemas de gestión y otros
ámbitos.
Por una parte, el estándar es fácilmente aplicable para la auditoría de cualquier

tipo de sistema de gestión basado en el ciclo PDCA en los términos que ISO
ha definido. En particular, el estándar es fácilmente aplicable a los sistemas
de gestión de la seguridad de la información sin grandes modificaciones. Ade-
más, los términos que ISO ha definido se repiten en las Normas ISO 9001,
ISO 14001, ISO 27001, y futuras relacionadas con la continuidad de negocio
ISO25999, gestión de servicios IT, y familia ISO20000. Esta es la razón por la
que la ISO 19011 está siendo empleada para la elaboración del estándar ISO/
IEC 27007 (Information Technology - Security techniques - Guidelines for In-
formation Security Management Systems Auditing), el cual se encuentra to-

davía (a fecha del 2009) en fase de borrador. Este estándar se engloba en la
familia de normas dedicadas a la seguridad de la información, y tendrá como
objeto definir y dar guías para la auditoría de los sistemas de gestión de la se-
guridad de la información.
Por otra parte, si se observa la Norma ISO 19011 desde el punto de vista de un
auditor con experiencia, se detectan elementos generales y comunes a otros
estándares y códigos profesionales, lo que nos confirma su capacidad de servir
como guía para asuntos como la auditoría de sistemas de información.
Respecto a la auditoría de sistemas de información y de sistemas de gestión

de la seguridad de la información, conviene destacar que tanto la Norma ISO
19011 como la Norma más específica ISO/IEC 27007, son completamente apli-
cables a cualquiera de los tipos de auditoría descritos inicialmente. Es decir,
son aplicables a auditorías de primera, segunda y tercera parte. Sin embargo,
se tiene que destacar que las auditorías de tercera parte tienen un tratamiento
especial por parte de ISO. Cuando se habla de auditorías de tercera parte de
un sistema de gestión, se entiende que los criterios de auditoría son los que
están reflejados en algún tipo de norma o legislación. En lo que corresponde a
los sistemas de gestión que están normalizados por ISO, en cada una de las fa-
milias de Normas (ISO9000, 14000 o 27000) existe una norma específica para
definir los requerimientos de un sistema de gestión (las ISO 9001, ISO 14001,
y ISO/IEC 27001). Las auditorías que buscan comprobar el sistema de gestión
implantado en una organización, para controlar una determinada actividad,
son denominadas auditorías de certificación, y son realizadas por organizacio-
nes que están fuertemente reguladas: las entidades de certificación.
Estas entidades de certificación tienen que demostrar su verdadera indepen-

dencia para que los dictámenes que realicen (auditorías de certificación) sean
tomados en consideración por el mercado. Es decir, tienen que demostrar su
independencia para que los resultados de sus auditorías sean reconocidos por
una organización distinta del auditado y el auditor. Por lo tanto, estas entida-
des deberán gestionar sus propios procesos de auditoría de acuerdo con, no ya
unas directrices o guías (que es lo que son las Normas ISO 19011 e ISO/IEC
27007), sino con una norma o conjunto de requisitos definidos por un cuerpo
normativo superior. Este cuerpo normativo superior puede ser, por ejemplo
ISO, internacional, o también de ámbito nacional, como AENOR en España.
Se habla entonces de que la entidad de certificación tiene que estar acreditada
por otra entidad, que se denomina entidad de acreditación, para realizar au-
ditorías de certificación contra una norma.
Esta relación entidad de certificación / entidad de acreditación viene a cubrir

una necesidad obvia, que es: ¿quién audita al auditor? Tal y como acabamos de
decir, este problema sólo está correctamente resuelto para unos cuantos tipos
de auditorías, como las auditorías de cuentas o auditorías de certificación. Es-
tas auditorías de certificación son realizadas por entidades de certificación que
no son más que empresas (pocas son organismos públicos, aunque también
podrían serlo) que han pasado un proceso de auditoría por parte de una enti-
dad de acreditación. La entidad de acreditación certifica que la empresa realiza
las asignaciones de auditoría con arreglo a ciertos estándares, como la Norma
ISO 17021, que especifica los requisitos (en el ámbito de las normas de la fa-
milia ISO 27001, le complementaría la Norma ISO/IEC 27006). Este proceso
se denomina de acreditación, porque acredita a la entidad de certificación a
realizar un cierto trabajo y que sus conclusiones de auditoría sean reconocidas
dentro del ámbito de reconocimiento que tenga la entidad de acreditación.
Es interesante constatar que la Norma ISO 17021 es más estricta que la ISO
19011, y da los requisitos para que tanto el auditado como los potenciales
interesados en los resultados de la auditoría puedan confiar en la entidad de
certificación. Esta confianza se garantiza mediante el aseguramiento de los
principios de:
• Imparcialidad.
• Competencia a la hora de realizar las auditorías.
• Responsabilidad.
• Publicidad. Publicidad
En el sentido de hacer pública

• Confidencialidad. la información que se pueda
revelar a los interesados, como
por ejemplo el estatus de un
• Capacidad para resolución de los conflictos con los auditados. certificado emitido por ella.
Los requerimientos que impone son variados y amplios como:

Aspectos organizativos
• Legales. Se refiere a estructuras y dota-

ción en cuanto a recursos hu-
manos.
• Organizativos.
• Gestión de la documentación (formatos, registros, etc.) e información (ti-

po de información que debe ser revelada y tipo que debe ser confidencial)
relacionada con la auditoría de certificación.
• Forma en la que se debe realizar la auditoría de certificación y el programa

de auditoría que se debe implantar.
Gracias a estos puntos, el trabajo de la entidad de certificación puede gozar

de un reconocimiento dentro de un ámbito que dependerá, en cierta medida,
de la entidad de acreditación. Habitualmente, las entidades de acreditación
son entidades públicas, por lo que este reconocimiento suele tener siempre un
carácter nacional, dentro de un estado.
Al tener estas entidades de acreditación un ámbito de actuación geográfico,

habitualmente un estado, el ámbito de reconocimiento de los certificados emi-
tidos por entidades de certificación que se hayan acreditado tendría un reco-
nocimiento limitado geográficamente a ese ámbito. Sin embargo, las organi-
zaciones pueden y quieren que los certificados tengan un reconocimiento in-
ternacional. Para resolver este problema, las distintas entidades de acredita-
ción se agrupan y realizan acuerdos de reconocimiento mutuo de los esquemas
de acreditación. De este modo, se amplía geográficamente el ámbito de reco-
nocimiento de una determinada certificación. Las organizaciones que deseen
certificarse deben tener en cuenta este punto a la hora de escoger la entidad
de certificación que haya de realizar la auditoría de certificación, puesto que,
por necesidades de negocio, quizá existan problemas de reconocimiento del
certificado obtenido.
Normalmente, cada país tiene sus propias entidades de acreditación, y éstas

se reconocen mutuamente y se agrupan en entidades supranacionales que "vi-
gilan" a estas entidades nacionales o más concretamente establecen criterios
para equiparar las formas de trabajar de las entidades de acreditación validan-
do esos acuerdos mutuos. La organización que se encarga de esta labor es el
International Accreditation Forum (http://www.iaf.nu/).
En definitiva, que la auditoría realizada por una entidad de certificación y pos-

teriormente el certificado emitido sean reconocidos por el mercado se basa en
esta cadena de confianza. Sin embargo, en la práctica, tampoco aporta mucha
certeza sobre la calidad puntual de un trabajo de auditoría, pero sí de manera
general sobre el comportamiento y tratamiento profesional de todos los ele-
mentos de la cadena: entidad de acreditación - entidades de certificación - au-
ditado.
A continuación, se facilita un listado de las entidades de acreditación más

relevantes en nuestro entorno:
Argentina Luxemburgo
Organismo Argentino de Acreditacion (OAA) Luxembourg Office of Accreditation (OLAS)
Austria Malasia
Federal Ministry for Economic Affairs and Labor (BMWA) Department of Standards Malaysia (DSM)
Australia�y�Nueva�Zelanda Mauricio
Joint Accreditation System of Australia and New Zealand (JAS- Mauritias Accreditation Service (MAURITAS)
ANZ)
Bélgica México
Belgian Accreditation System for Bodies Operating Certification of Mexican Accreditation Entity (EMA)
Products, Quality Systems or Persons (BELCERT)
Brasil Países�Bajos
General Coordination for Accreditation - Cgcre, of National Insti- Dutch Accreditation Council (RvA)
tute of Metrology, Standardization and Industrial Quality (INME-
TRO)
Canadá Noruega
Standards Council of Canada (SCC) Norwegian Accreditation (NA)
Chile Pakistán
Instituto Nacional de Normalizacion (INN) Pakistan National Accreditation Council (PNAC)
República�Checa Filipinas
Czech Accreditation Institute (CAI) Bureau of Product Standards Accreditation Scheme
China Polonia
China National Accreditation Board for Certifiers (CNAB) Polish Centre for Accreditation (PCA)
Dinamarca Rumania
Danish Accreditation (DANAK) Romanian Accreditation Association (Asociatia de Acreditare din
Romania (RENAR)
Finlandia Singapur
The Finnish Accreditation Service (FINAS) Singapore Accreditation Council (SAC)
Francia Eslovaquia
Comite Francais d'Accreditation (COFRAC) Slovak National Accreditation Service (SNAS)
Grecia Eslovenia
Hellenic Accreditation System S. A. (ESYD) Slovenska Akreditacija (S. A.)
Alemania Sudáfrica
German Accreditation Council (DAR) South African National Accreditation System (SANAS)
Hong�Kong,�China Corea�del�Sur
Hong Kong Accreditation Service (HKAS) Republic of Korea Accreditation System (KAS)
India España
National Accreditation Board for Certification Bodies (NABCB) Entidad Nacional de Acreditacion (ENAC)
Indonesia Suecia
Komite Akreditasi Nasional (KAN) Swedish Board for Accreditation and Conformity Assessment
(SWEDAC)
Irán Suiza
Iran Accreditation System (IAS) Swiss Accreditation Service (SAS)
Irlanda Taipei
The Irish National Accreditation Board (INAB) Taiwan Accreditation Foundation (TAF)
Italia Tailandia
Sistema Nazionale di Accreditamento degli Organsimi di Certi- National Accreditation Council of Thailand (NAC)
ficazione e Ispezione - Italian Federation for Accreditation (SIN-
CERT-FIDEA)
Japón Reino�Unido
The Japan Accreditation Board for Conformity Assessment (JAB) United Kingdom Accreditation Service (UKAS)
Estados�Unidos
ANSI-ASQ National Accreditation Board (ANAB)
En otro tipo de auditorías no relacionadas con certificaciones, como auditorías

de primera parte realizadas por una organización externa (por falta de recursos
o conocimientos en la organización auditada), no existen estas entidades de
control. En este caso, para garantizar la calidad del trabajo de auditoría, no hay
más recursos que confiar en las certificaciones profesionales de terceros. Estas
certificaciones profesionales permiten tener una opinión sobre la calidad del
trabajo que es capaz de realizar un auditor a título individual. Por el momento,
no existe un esquema como la acreditación que sea aplicable en el sector de
las auditorías de primera parte realizadas por un externo.
En este último caso, la fiabilidad y el grado de confianza que da una certifica-

ción profesional lo da el mercado. Actualmente, en el ámbito de la seguridad
de la información, hay dos certificaciones destacables:
• CISA de ISACA
• CISSP de ISCC (Information Systems Security Certification Consortium,
Inc.)
Estas certificaciones se obtienen en un momento dado, y luego la persona cer-

tificada tiene que mantener la certificación acreditando que se continúa for-
mando. Pero estas entidades no responden de ningún modo sobre el trabajo
que realiza un auditor, y no realizan controles sobre los trabajos que estos pro-
fesionales realicen, únicamente garantizan mediante sus programas de reno-
vación de las certificaciones que el profesional está capacitado para ejecutar
labores de auditoría.
5.3. ISACA (Information Systems Audit and Control Association)
Otro de los esfuerzos que merecen ser destacados es la labor de la ISACA (In-
formation Systems Audit and Control Association), aunque no se tratará en
este apartado por encontrarse más desarrollado en otro módulo de este curso.
5.4. IRCA (International Register of Certificated Auditors)
IRCA es una organización actualmente internacional, pero de origen británico,

que surgió promovida por el gobierno británico al mismo tiempo que UKAS
(la entidad de acreditación del Reino Unido) y BSI (British Standards Institute),
como iniciativa para mejorar la industria y los negocios a través de la imple-
mentación de principios y mejores prácticas relacionadas con la calidad.
Como organización, IRCA está orientada al ámbito de la auditoría de sistemas

de gestión (es decir, aspectos como las auditorías de cuentas quedan fuera de
su ámbito) y tiene por objetivo general promover la profesión de auditor y
proporcionar confianza en la calidad del trabajo de auditoría de sistemas de
gestión mediante la estandarización tanto de la labor de auditoría como de la
formación de los auditores, cuya certificación figura entre sus actividades. Es
decir, IRCA es una organización que da garantía de la profesionalidad y calidad
del trabajo realizado por un auditor certificado por ella.
Esto lo lleva a cabo apoyándose en las entidades de certificación que realizan

formaciones de auditores de acuerdo con parámetros y métodos acordados
con IRCA, de manera que un auditor formado por una de esas entidades puede
acreditarse ante IRCA y mostrar al mercado que su profesionalidad está respal-
dada por una comunidad que estandariza y controla el modo en que se deben
realizar las auditorías de sistemas de gestión.
Al tratarse de sistemas de gestión y también tener una vocación internacional,

sus metodologías están guiadas en esencia por normas internacionales ISO
y, muy especialmente, por las normas ISO 19011 e ISO 17021, comentadas
anteriormente.
6. Gobierno de las TIC
La Organización para la Cooperación y el Desarrollo Económicos (OCDE),

cuando emitió sus "Principios del Gobierno Corporativo" (1999), definió el
gobierno corporativo como "el sistema por el cual las corporaciones de negocio
son dirigidas y controladas". Cada país en la OCDE está desarrollando, a dife-
rentes velocidades, sus propios esquemas para el control del gobierno corpo-
rativo, reflejando su propia cultura y requisitos. Dentro de su acercamiento al
gobierno corporativo, cada organización tiene que determinar cómo maneja-
rá su información. Aquí, la información es entendida como la combinación
tanto de los activos de la información base de su modelo de negocio, como
de la tecnología de información que los trata. Esta necesidad ha conducido
a la aparición del gobierno de las TIC (tecnologías de la información y comu-
nicaciones) como componente específico, y cada vez más importante, de la
cultura de gobierno de una organización.
Habitualmente, se define gobierno como "el marco para la dirección (estruc-

turas organizativas, y procesos del negocio, estándares y la conformidad con
respecto a estos estándares) que se asegura de que los sistemas de información
y comunicaciones de la organización apoyen y permitan el logro de sus estra-
tegias y objetivos".
Una organización puede estar interesada en implantar estrategias para el go-

bierno TIC por distintos motivos:
• Requerimientos legales, regulatorios o sectoriales.
La Ley Sarbanes-Oxley para las empresas cotizadas en Estados Unidos, o los acuerdos de
Basilea III en el marco europeo.
• Aumento creciente del valor del capital intelectual de una organización.
• Necesidad de alinear la evolución de los sistemas de información con los

objetivos estratégicos del negocio, y asegurar que proporcionan los bene-
ficios planificados.
• Proliferación y progresiva complicación de las amenazas a la información,

con el consecuente impacto en la reputación, beneficio y rentabilidad del
negocio.
Hay dos factores fundamentales en la gestión efectiva de los riesgos relacio-

nados con las TIC. El primero está relacionado con el despliegue de las TIC
de forma alineada con los objetivos de negocio. Los proyectos TIC represen-
tan, a menudo, una importante inversión de recursos financieros y humanos.
Por tanto, los intereses de los propietarios del negocio deberían defenderse
mediante mecanismos de control interno que garanticen, de manera transpa-

rente y eficaz, que las TIC son planificadas, gestionadas, y monitorizadas ade-
cuadamente. Esto implica que los administradores del negocio deben tener en
cuenta los riesgos que les puedan afectar y que puedan tener impacto en el ne-
gocio. El segundo factor es, en sí mismo, cómo estos riesgos son gestionados.
Es evidente que la seguridad de la información es un componente dominante

del gobierno TIC. Cuando las TIC y la información en sí misma se convierten
en el factor determinante de la estrategia de negocio, y en determinados casos
en la misma piedra angular del modelo de negocio, la seguridad de las mismas
se convierte en una de las preocupaciones básicas de las juntas de dirección
de las organizaciones.
Se tiene que destacar que la auditoría de sistemas de información nació antes

de que se definiera el concepto de gobierno de las TIC. Surgió como una ne-
cesidad durante el proceso de auditoría financiera. Con el progresivo auge de
los sistemas de información, los auditores de cuentas tenían que confiar cada
vez más en la exactitud de los datos proporcionados por los sistemas, y cada
vez menos en lo que se encontraban en soportes tangibles (libros de cuentas,
extractos, facturas, albaranes, etc.). Esto era así sobre todo por el enorme volu-
men de datos, y también por su progresiva desaparición debido al incremento
de las transacciones puramente electrónicas. Por lo tanto, resultó necesario
desde el primer momento comprobar si la información de estos sistemas era
correcta, y si no había podido ser manipulada. Es en este contexto, por tan-
to, que se inició la disciplina de la auditoría de los sistemas de información
(y seguridad de éstos), y fue evolucionando y adquiriendo más protagonismo
al mismo ritmo que fueron haciéndolo los propios sistemas de información.
Actualmente, en toda auditoría financiera existe un componente de auditoría
de los sistemas de información, pero ha transcendido a ellas y existe por sí
misma en diferentes contextos.
Por tanto, desde este punto de vista, para garantizar un buen gobierno TIC
es esencial que exista una revisión del gobierno TIC. Más específicamente,
es esencial que esta función de auditoría de los sistemas de información esté
integrada en los mecanismos de gobierno TIC. La función de auditoría debe
comprobar cómo se están gestionando los mecanismos de control implanta-
dos en las TIC para garantizar la seguridad.
De manera general, los objetivos de auditoría que persigue una auditoría de

sistemas de información son:
• Validar los aspectos organizativos y administrativos relativos al proceso de

gestión de los sistemas de seguridad, con el objetivo de garantizar que no
suponen un riesgo para la seguridad de la información.
• Validar los controles aplicados a la gestión del ciclo de vida de un sistema

de información, especialmente en sus fases iniciales de diseño, implemen-
tación y puesta en producción.
• Validar del control de acceso físico a instalaciones, terminales, bibliotecas

de cintas, etc.
• Automatizar los controles de auditoría integrados en los sistemas de infor-

mación.
• Formar, capacitar y sensibilizar de los usuarios en general y, específicamen-

te, del personal dedicado a la gestión, operación, y mantenimiento de los
sistemas de información.
• Controlar el proceso de auditoría de los Sistemas de Información.
Estos objetivos que hemos expuesto corresponden tanto a la auditoría de sis-

temas de información como también, en general, al proceso de gestión de se-
guridad de la información. Esta coincidencia de objetivos es más destacable
si el sistema de gestión de la seguridad de la información (SGSI) está alineado
con la Norma ISO/IEC 27002, antes denominada ISO/IEC 17799, y más aún si
el SGSI está implementado cumpliendo con los requerimientos de la Norma
ISO/IEC 27001. Es decir, los objetivos de una auditoría de sistemas de infor-
mación (SSII) son los mismos que busca un SGSI. Por tanto, existe la posibili-
dad de realizar dos tipos de auditoría a los sistemas de información:
• Auditoría de seguridad a los sistemas de información.

• Auditoría de certificación del sistema de gestión de la seguridad de la in-
formación.
Se tiene que destacar que la certificación de un SGSI asegura que la entidad

auditada gestiona con arreglo al estándar y, por lo tanto, deberá realizar au-
ditorías internas de seguridad a los sistemas de información. Este es el nexo
común entre ambos tipos.
6.1. Auditoría de los sistemas de información
Este tipo de auditoría se incorpora directamente al proceso interno de gestión

de la seguridad de la información. Su función es comprobar que la implanta-
ción de los controles de seguridad cumple con lo establecido en las diferentes
políticas dictadas por la organización, y que estos controles han sido implan-
tados de forma técnicamente correcta. La auditoría consiste, por tanto, en la
revisión de las medidas de seguridad, sin más objetivo que el de dictaminar si
la seguridad es correcta o si presenta deficiencias. La revisión de las medidas de
seguridad se hace frente a una referencia dada, que puede ser la propia política
de seguridad de la organización, o una norma de referencia como la ISO/IEC
27002 o COBIT.
Es importante destacar que, al tratarse de un proceso interno del SGSI, la au-

ditoría tendrá un alcance que, como máximo, será el del propio SGSI. Sin em-
bargo, la auditoría también podrá centrarse en un alcance más reducido co-
mo, por ejemplo, un tipo concreto de infraestructura, aplicación o proceso del
SGSI.
La auditoría puede centrarse en el cumplimiento de algún aspecto legal relativo a la pri-

vacidad, la protección de datos personales, o los procesos relacionados con la gestión del
personal (procesos de selección, entrenamiento, terminación de contratos, etc.).
En cualquier caso, antes de abordar un proceso de auditoría, es esencial definir

tanto el alcance como la referencia contra la que se quiere auditar. En este
sentido, tenemos que destacar que, más adelante, trataremos en mayor detalle
los aspectos que intervienen en una auditoría de revisión de implantación de
controles. Por lo tanto, nos interesaremos en las revisiones a realizar en los
controles técnicos de seguridad implantados en la infraestructura de red, o los
servicios que se ofrecen sobre estas infraestructuras.
Estas auditorías tienen consideración de auditoría de primera parte y, por tan-

to, pueden ser realizadas por un grupo interno o por una entidad externa. Sin
embargo, en cualquiera de los dos casos, es importante una independencia
suficiente entre el equipo auditor y el equipo implantador y de operaciones,
para poder garantizar la calidad del resultado.
Las auditorías internas podrán realizarse siempre que las organizaciones po-
sean un grupo de auditoría independiente del área a analizar. Este grupo inde-
pendiente deberá tener los conocimientos de seguridad suficientes para dicta-
minar si las medidas de seguridad son suficientes y si, a la vez, están correcta-
mente configuradas.
Las auditorías externas son las que se realizan por empresas externas que se
encargan de revisar las diferentes medidas de seguridad. Estas empresas deben
ser totalmente independientes de la organización y tener conocimientos acre-
ditados de seguridad.
En los dos casos, el resultado de estos procesos de auditoría consiste en la ela-

boración de un informe en el que se dictaminan las deficiencias de seguridad
que se hayan podido detectar, siempre dentro del alcance que se haya deter-
minado para la auditoría. Es importante destacar que este informe debe ser
lo más objetivo, claro, conciso y directo posible. Muy posiblemente, tendrá
como público objetivo tanto a personal directivo de alto nivel como mandos
intermedios y operativos, por lo que deberá organizarse teniendo en cuenta
esta circunstancia.
Más adelante, detallaremos los aspectos más importantes acerca de las audito-
rías de seguridad.
6.2. Certificación de seguridad
Para la materia que nos ocupa, el proceso de certificación de seguridad lo lleva

a cabo una organización que ha implantado un sistema de gestión de la segu-
ridad de la información. Esta implantación se ha hecho con arreglo a la nor-
mativa ISO/IEC 27001. Para obtener la certificación de seguridad, la organiza-
ción consulta con una entidad externa que está acreditada y que se encargará
de ver la correcta implantación de esta normativa. El objetivo de la entidad
externa es dictaminar si la implantación es correcta y, una vez finalizada su
revisión, elaborará un informe. En el caso de que el informe sea favorable, se
le entrega a la organización un sello que certifica el cumplimiento y correcta
implantación de la normativa.
Estas certificaciones de seguridad únicamente pueden ser realizadas por orga-

nizaciones debidamente acreditadas por organizaciones superiores, denomi-
nadas organismos de acreditación, como por ejemplo ENAC en España. Es de-
cir, la certificación únicamente la pueden otorgar aquellas organizaciones que
cumplen con una serie de requisitos comprobados (auditados) por un tercero
de confianza (el organismo de acreditación). Otro aspecto importante a desta-
car es que estas organizaciones de certificación son independientes, es decir,
no ofrecen servicios de consultoría sino que son expresamente auditoras.
Algunas de esas empresas son: AENOR, APPLUS, BSi (British Standard Institute), TüV, etc.
En cuanto a la realización de la auditoría y la certificación, siempre que sea en

base a la normativa anterior, se realizan de la misma forma y la única diferencia
es el resultado final, que en el segundo caso es únicamente un informe de
certificación.
7. Equipo auditor
En esta sección, veremos los diferentes aspectos que tienen relación con los
equipos de auditorías que realizan revisiones de los sistemas de gestión de la
seguridad de la información. La descripción de los equipos de auditorías que
se proporcionará es válida tanto para revisiones de cara a la certificación como
para revisiones de cara únicamente a la auditoría de sistemas de información.
Los aspectos descritos en esta sección se corresponden con los requisitos im-
puestos a las entidades de certificación (ISO 17021, ISO 27006 y también en
parte la ISO 19011), por lo que tienen que ser vistos como un ejercicio de
máximos. Es decir, estos requisitos son completamente aplicables a entidades
de certificación. Aquellas organizaciones que, no siendo entidades de certifi-
cación, se dediquen a la auditoría no estarán obligadas a cumplir con la tota-
lidad de los aspectos que aquí se describen. Sin embargo, es recomendable que
las organizaciones auditoras tengan en cuentas estos requisitos y los tomen
como una recomendación.
El equipo auditor es el equipo de personas que estará encargado de ejecutar

el proyecto de auditoría, tanto para la revisión de las medidas de seguridad
(auditoría de seguridad), como para la revisión de la correcta implantación de
la normativa ISO/IEC 27001 (en caso de búsqueda de la obtención de la certi-
ficación). Este equipo estará idealmente compuesto por un grupo de auditores
organizado idealmente del siguiente modo:
Estructura básica de un equipo de auditoría
El equipo auditor está compuesto, como mínimo, por un auditor jefe, que
es el responsable final de la asignación de auditoría. Podrán asistirle uno o
varios auditores y/o expertos técnicos para la ejecución de las pruebas. Los
expertos técnicos trabajarán en aquellas pruebas en las que los conocimientos
y la experiencia del auditor jefe o el equipo de auditores sean insuficientes.
El número final de personas incluido dependerá de las limitaciones de tiem-

po/coste y el alcance de la auditoría. Por otra parte, no es necesaria la partici-
pación de todos los auditores y expertos durante todo el marco temporal en el
que se desarrolle la auditoría. Sin embargo, este no es el caso del auditor jefe,
que participará en todo momento puesto que es el punto de contacto entre
la organización auditada y la auditora, y es también el responsable último del
trabajo desarrollado.
Los requisitos recomendables que se necesitan para poder pertenecer a un

equipo de auditoría, así como sus responsabilidades, se describen a continua-
ción. Estos requisitos son impuestos de forma estricta cuando el equipo debe
certificar un SGSI contra la Norma ISO/IEC 27001. En este caso, estos requi-
sitos son impuestos por el organismo de acreditación. En otras situaciones,
deben ser tomados como recomendaciones.
Por otro lado, el equipo auditor no es el único involucrado en la realización de

la auditoría y, por parte del auditado, es necesaria la participación de diversos
interlocutores. Este punto se tratará más adelante.
7.1. Auditor jefe
El auditor jefe es designado por la dirección del programa de auditoría en que

se encuadre la auditoría o por la dirección de la organización auditora. En caso
de que se realicen auditorías conjuntas (varias entidades auditoras), se deberá
aclarar quién posee la dirección de la labor de auditoría.
En definitiva, el auditor jefe es el responsable último del resultado de la audi-

toría tanto frente al cliente de la misma, como frente al auditado y, en general,
de cara a la dirección de la organización a la que pertenece (por ejemplo, en el
caso de las entidades de certificación o empresas que realizan auditorías más
técnicas sobre sistemas de información). Esta responsabilidad incluye:
• Los objetivos de auditoría, el alcance, los criterios y la duración estimada

de la auditoría.
• La competencia general del equipo auditor necesaria para conseguir los

objetivos de la auditoría.
• Los requisitos necesarios de los organismos de acreditación/certificación,

si es de aplicación.
• La necesidad de asegurar la independencia del equipo auditor de las acti-

vidades a ser auditadas, y evitar conflictos de intereses.
• La capacidad de los miembros del equipo auditor para interactuar eficaz-

mente con el auditado y trabajar conjuntamente.
• El idioma de la auditoría y la comprensión de las características sociales y

culturales del auditado, bien a través de las propias capacidades del auditor
o a través del apoyo de un experto técnico.
• Liderar las reuniones de inicio y cierre de las auditorías (son reuniones que
siempre se realizan).
• Controlar que la auditoría se esté desarrollando correctamente, que esté

avanzando de acuerdo con el plan, y comprobar si los objetivos de la au-
ditoría se podrán conseguir.
• Realizar el seguimiento de las evidencias que se vayan encontrando. El au-

ditor jefe es el último responsable de la categorización de las mismas como
hallazgo, así como de su nivel de clasificación como no conformidad.
• Asistir al equipo auditor si existen problemas, incidencias o conflictos du-

rante el desarrollo de la auditoría.
Desde el punto de vista de sus características, es recomendable que los audi-

tores jefe tengan conocimientos y habilidades adicionales a las del resto de
los auditores del equipo. Estas habilidades adicionales son las de liderazgo de
la auditoría, para permitir al equipo auditor llevar a cabo la auditoría de ma-
nera eficiente y eficaz. Los conocimientos y habilidades en esta área deben
contemplar:
• Planificación y gestión de recursos.
• Capacidad de comunicación con el cliente de la auditoría y el auditado,

para representar y defender al equipo auditor.
• Capacidad de liderazgo de personas.
• Conocimientos técnicos suficientes para conducir al equipo auditor y al-

canzar conclusiones de la auditoría. Para ello, se le exigirá la formación
académica que sea relevante en el área a auditar.
• Capacidad de previsión y resolución de conflictos.
• Finalmente, es recomendable (y necesario en auditoría de certificación)

que el auditor haya participado, como mínimo, en tres auditorías como
miembro de un equipo auditor realizando labores de auditor jefe bajo la
supervisión del auditor jefe.
7.2. Auditor
El auditor (y también, por extensión, el auditor jefe) debe acreditar la forma-

ción adecuada que demuestre los siguientes conocimientos y habilidades:
• Conocimientos sobre los principios de auditoría, procedimientos y técni-

cas que le permitan asegurarse de que las auditorías se llevan a cabo de
manera coherente y sistemática. Si nos ocupamos de entornos de audito-
rías de certificación de SGSI, este conocimiento es recomendable que se
acredite mediante formación específica en auditoría, y también mediante
experiencia.
– Revisión de la documentación del SGSI.
– Revisión del análisis de riesgos de una organización.
– Haber auditado la implantación de un SGSI.
– Haber desarrollado los informes relativos a la auditoría en la que par-
ticipó.
• Conocimientos específicos en el ámbito de la actividad auditada. Esto in-

cluye: conocer documentos de referencia y características de los sistemas
de gestión y de control, conocer aspectos técnicos que le permitan enten-
der el alcance de la auditoría y aplicar los criterios de auditoría. Este re-
quisito está muy relacionado con la formación académica que haya reci-
bido el auditor. Respecto a la formación académica, puede ser suficiente
acreditar la experiencia profesional equivalente. En el caso de la auditoría
de sistemas de información, se suele considerar suficiente una experiencia
de cuatro años en el ámbito de las tecnologías de la información, y por
lo menos de dos años en seguridad de las tecnologías de la información.
También es necesario haber realizado un curso de cinco días de auditoría.
• Capacidad para entender las situaciones particulares e idiosincrasia de la

organización auditada, que le permita entender el contexto de las opera-
ciones de la organización. Esto incluye entender el modelo de negocio del
auditado, su sector y las características sociales del mismo.
• Conocimiento de la legislación aplicable, reglamentos y otros requisitos

relevantes a la disciplina, que le permita trabajar con ellos y ser consciente
de los requisitos aplicables a la organización que se está auditando.
A estos requisitos de conocimientos y habilidades, de orden profesional, hay

que añadir ciertas capacidades y habilidades personales que garanticen el éxi-
to de su trabajo. Las cualidades personales que contribuyen al rendimiento
exitoso de un auditor son:
• Ser ético, imparcial, sincero, honesto y discreto.

• Tener una actitud abierta y estar dispuesto a considerar ideas o puntos de
vista alternativos.
• Mostrarse diplomático y hábil en las relaciones con la gente.
• Ser observador, constante y activamente consciente de los entornos físicos

y las actividades.
• Ser perspicaz, instintivamente consciente y capaz de entender y adaptarse
a las situaciones.
• Ser versátil, capaz de adaptarse a diferentes situaciones.
• Ser tenaz, persistente y orientado sobre la consecución de los objetivos.
• Tener poder de decisión, siendo capaz de alcanzar conclusiones oportunas
basadas en el razonamiento lógico y el análisis.
• Mostrarse independiente en las actuaciones, relacionándose al mismo
tiempo con otros de manera eficaz.
Por supuesto, todas las características exigibles al auditor valen también para
el auditor jefe.
7.3. Experto técnico
Las habilidades técnicas requeridas por el equipo auditor dependerán, exclusi-

vamente, del entorno a auditar. Si estos conocimientos y habilidades necesa-
rias para ejecutar ciertas pruebas de auditoría no se encuentran cubiertos por
el equipo auditor, se pueden satisfacer incluyendo expertos técnicos. En cual-
quier caso, los expertos técnicos operan siempre bajo la dirección de un au-
ditor y no deben actuar como auditores propiamente dichos emitiendo con-
clusiones de auditorías derivadas de la ejecución de las tareas que se les haya
encomendado. El equipo auditor necesita, por tanto, tener un nivel de cono-
cimiento tecnológico amplio y, sobre todo, debe conocer las interrelaciones
de los diferentes ámbitos de su especialidad, pero no necesariamente este co-
nocimiento debe ser exhaustivo en un área en particular.
Otra circunstancia en la que puede ser necesaria la participación de un experto

es cuando puedan existir dificultades logísticas o incluso de comunicación por
desconocimiento de un idioma común entre auditor y auditado.
7.4. Capacitación del equipo auditor
Cuando la auditoría a realizar es de tercera parte, existen claras implicaciones

en cuanto a la confianza que se debe dar al mercado respecto al tipo de trabajo
que se ha realizado en términos de calidad, independencia, profesionalidad
y en general todos los principios de auditoría. Es por esta razón que dentro
de los requerimientos que deben cumplir las organizaciones auditoras estén
también los de capacitación del equipo auditor.
Como se ha comentado anteriormente, cuando el equipo auditor vaya a eje-

cutar una auditoría de certificación es necesario que el personal asignado esté
debidamente capacitado y tenga la experiencia adecuada. Los auditores miem-
bros del equipo deben cumplir con requerimientos estrictos para poder ejercer
la posición. Estos requerimientos pueden variar algo según la entidad de cer-
tificación, pero básicamente son los siguientes.
Para ambas posiciones es necesaria la realización de cursos específicos de audi-

tor ISO 27001. Este curso suele ofrecerse habitualmente con el título “Auditor
Jefe ISO 27001”, aunque la realización del curso por sí solo no es suficiente. En
muchas ocasiones las mismas entidades de certificación ofrecen este curso ya
que, aunque no puedan ofrecer servicios de auditoría, sí pueden ofrecer for-
mación y suelen tener un catálogo bien amplio. Tras obtener esta certificación
personal, para poder realizar auditorías, es necesario acreditar un determinado
número de horas de práctica de auditorías y además pasar antes por el rol de
“auditor” y luego por el de “auditor jefe”. Cada uno de estos roles requiere su
propio periodo previo de prácticas antes de pasar a ejercer el rol oficialmente.
Estas auditorías suelen ejecutarse en calidad de “auditor en formación” y nun-
ca son ejecutadas sin el liderazgo y la supervisión de un auditor debidamente
acreditado.
7.5. Independencia de auditoría
El equipo auditor, con el fin de garantizar su imparcialidad, no puede parti-

cipar en la elaboración de manuales, políticas o procedimientos de una orga-
nización. Tampoco puede formar parte del grupo que toma decisiones sobre
el estado del sistema de gestión de la seguridad de la información, y tampo-
co puede dar recomendaciones específicas para el desarrollo del SGSI. Sí po-
drá, una vez finalizada la auditoría, emitir las recomendaciones que considere
oportunas.
Por el contrario, el equipo auditor sí puede, y de hecho tiene la obligación, No conformidad

de auditar, detectar las no conformidades, y realizar el seguimiento de las no
Es un error, en la creación del
conformidades que se hayan detectado. SGSI al respecto de la Norma-
tiva ISO/IEC 27001, o cual-
quier otro marco que se tome
Por otra parte, un miembro del equipo auditor también tiene capacidad de como referencia, contra el que
se está auditando.
impartir formación genérica sobre normativas o aspectos de seguridad, realizar
publicaciones sobre interpretaciones relativas a la normativa y, por último,
hacer realizar auditorías previas a la certificación, para verificar el estado del
sistema de gestión de la seguridad de la información.
7.6. Código de conducta del equipo auditor
Especialmente cuando se trata de auditorías de certificación, los miembros del

equipo auditor tienen un código de conducta que seguir, el cual asegura la
correcta realización de sus tareas. En este sentido, su código de conducta es:
• Actuar de forma veraz e imparcial.

• Evitar cualquier tipo de asignación que pueda causar un conflicto de in-
tereses.
• No aceptar ningún tipo de incentivo, comisión, descuento u otro tipo de

provecho por parte de la organización auditada.
• No revelar las observaciones de las auditorías a terceros.
• No actuar de forma que pueda perjudicar a ninguna de las partes implica-
das en la auditoría.
En caso de incumplimiento de este código, se procederá a una investi-

gación en la que el equipo auditor colaborará para su esclarecimiento.
7.7. Distribución de funciones
Dentro del proceso de auditoría, el auditor jefe tiene las siguientes funciones:
• Planifica y gestiona todas las fases de la auditoría.

• Dirige la primera fase.
• Colabora en la selección del equipo de auditores.
• Controla los conflictos y maneja las situaciones difíciles.
• Dirige las reuniones con el equipo auditor y el personal auditado.
• Toma decisiones en materia de la auditoría y el SGSI.
Las funciones que pertenecen a los auditores del equipo de auditoría son:
• Apoyar al auditor jefe.

• Documentar y apoyar todos los hallazgos.
• Realizar el seguimiento de las acciones correctoras para corregir las no con-
formidades encontradas.
7.8. Relación con el auditado
Durante la realización de las auditorías, pueden participar más personas de las

que se han nombrado hasta ahora (auditor jefe, auditores y auditado).
El personal que puede intervenir en un proceso de auditoría es:
• Equipo�auditor
– Jefe� y� miembros� del� equipo. Normalmente, se trata de una o más
personas.
– Auditores�en�formación. Personal en formación para convertirse en
auditor.
– Observadores,�auditor�provisional. Puede ser un observador del or-
ganismo de acreditación (por ejemplo, ENAC) que supervise la audi-
toría. Pero en ningún caso podrá participar en ninguna de las activi-
dades de auditoría.
– Expertos,�personal�asesor. Personal que asesora al auditor sobre temas
técnicos o concretos del negocio o las tecnologías a auditar, aunque
no vaya a actuar en ninguna prueba de auditoría; únicamente facilita

soporte técnico.
– Testigos�e�invitados.
• Equipo�del�auditado. Habitualmente se contará con:

– Representante de la dirección más acorde con el objetivo y alcance de
la auditoría (por ejemplo, en una auditoría de certificación en la que
existen requerimientos aplicables a la alta dirección, se deberá contar
con un representante máximo de la dirección; pero en una auditoría
técnica sobre una infraestructura TI, podría tratarse simplemente del
responsable del área de infraestructuras TI de la organización auditada
o bien su superior).
– Personas auditadas. Es muy habitual que parte de las pruebas de au-
ditoría requieran de la interlocución con personal del auditado. Las
áreas o grupos de trabajo pueden ser seleccionados por el auditado,
pero es labor del auditor escoger las personas concretas finalmente en-
trevistadas.
– Guía. Es recomendable que el auditado identifique a una persona co-
mo guía para el equipo auditor que le permita resolver aspectos logís-
ticos, aportar aclaraciones sobre respuestas dadas por personas que son
entrevistadas, facilitar documentación, etc.
– Observadores, personal en formación. Normalmente, se trata de per-
sonal de la empresa en formación para auditor interno.
– Consultores. Cuando la empresa contrata un consultor externo (por
ejemplo para que le asesorare en el desarrollo del SGSI), este puede
observar la auditoría, pero no debe intervenir en ella en ningún mo-
mento.
8. El peritaje informático
De manera general, el peritaje, o más exactamente la prueba pericial, es un

medio más de prueba para la resolución de conflictos. Esta prueba la aporta
una persona con conocimientos técnicos especializados en el tema para ayudar
a interpretar los hechos bajo prueba pericial y dirimir el conflicto.
Los tipos de peritajes son múltiples y casi tantos como áreas del conocimien-
to, aunque los más frecuentes suelen ser: caligráfico, grafológico, documen-
toscópico, inmobiliario (tasación), falsificación de marcas, reconstrucción de
accidentes (laborales, de tráfico), peritaje de incendios (valoración de daños,
reconstrucciones), sociolaborales, peritaje de joyas, análisis de voces, medici-
na pericial, plagio textual, etc.
Con la creciente penetración de los sistemas de información en la práctica

totalidad de los ámbitos de la sociedad y de la actividad humana desarrolla-
da, los sistemas de información se encuentran cada vez más involucrados en
situaciones de conflicto que necesitan ser resueltas. Por lo tanto, cada vez es
más frecuente que, en los conflictos entre personas u organizaciones, existan
elementos relacionados o contenidos en los sistemas de información. En es-
te contexto, se ha vuelto cada vez más frecuente la necesidad de contar con
un peritaje informático, que sea capaz de analizar una realidad con todas las
garantías legales, y que pueda dar una explicación basada en los hechos y la
lógica, siguiendo además unas ciertas reglas.
Los casos a peritar abarcan un amplio abanico de posibilidades, y van desde

despidos de personal por uso improcedente del equipamiento informático,
demandas por incumplimientos de contrato en la creación de aplicaciones
informáticas, tasación de bienes materiales e inmateriales, etc. Por lo tanto,
se tiene que comprender y romper con la idea de que el peritaje informático
está relacionado directamente con delitos informáticos. No es así. El peritaje
informático tiene un campo de aplicación mucho más amplio, y puede estar
presente en prácticamente cualquier conflicto en el que los sistemas de infor-
mación tengan alguna función.
Conviene indicar que un tribunal no es la única demandante de pericias. Tam-

bién empresas y particulares pueden necesitar, por diversos motivos, una prue-
ba pericial informática en sus equipos. Por ejemplo: determinar dónde está la
pérdida de correos internos, análisis de los sistemas de seguridad para detectar
usos indebidos, etc.
Es interesante destacar que existe cierta similitud entre la auditoría de sistemas

de información y la prueba pericial informática.
En los peritajes, al igual que en las auditorías, la información se obtiene me-

diante un proceso de análisis sistemático, lógico, repetible y objetivo al estar
absolutamente basado en los hechos y la realidad observable. Sin embargo,
existen diferencias muy notables, la principal de las cuales es que el objetivo
de ambos procesos es distinto. La auditoría tiene por objetivo analizar la reali-
dad para determinar si se ajusta a unas normativas determinadas (los criterios
de auditoría), mientras que el peritaje simplemente analiza la realidad para
poder explicarla y responder a las dudas que un neófito pueda tener de la in-
terpretación.
Otra diferencia importante que se ha de tener siempre en cuenta es que el

dictamen pericial (resultado de efectuar la prueba pericial) es una conclusión
emitida por una persona individual, el perito, mientras que las conclusiones
de auditoría son emitidas por la organización auditora. La diferencia es sutil,
puesto que se puede pensar que es el auditor jefe quien responde del resultado
de la auditoría, pero esto sólo es cierto de manera interna a la organización
encargada de realizar la auditoría. La auditoría es un proceso en el que se re-
lacionan organizaciones, el auditor y el auditado. Obviamente, puede ser que
la auditoría esté realizada por una única persona, y que en el contrato de au-
ditoría asuma las responsabilidades de manera personal. Sin embargo, en la
prueba pericial es el perito quien se expone y podría llegar a ser sancionado.
Por último, es interesante destacar la relación existente entre la informática

forense y el peritaje informático. La informática forense es una de las activi-
dades que pueden estar involucradas en una prueba pericial. Es decir, no todas
las pruebas periciales comportan necesariamente la realización de actividades
forenses. La informática forense consiste en una serie de técnicas y procedi-
mientos metodológicos que permiten capturar evidencias contenidas en equi-
pamientos computacionales y dispositivos digitales, las cuales pueden presen-
tarse como evidencia en una prueba.
M1.810 · Auditoría Técnica · PAC-1 · Marzo 2022
Máster Interuniversitario en Seguridad de las TIC
RESOLUCIÓN DE LA PRUEBA DE EVALUACIÓN 1

Introducción a la Auditoría Informática
La resolución de la prueba no es única. El enunciado de la prueba está
planteado de modo abierto y cada alumno tiene la opción de elaborar la
respuesta según su gusto y experiencia profesional. Por tanto la solución a la
PEC no es un documento único cerrado. En este documento daremos, para
cada una de las cuestiones planteadas, el conjunto de aspectos que se
consideran que deberían de contener la respuesta del alumno.
Reproducimos el enunciado marcando los aspectos que son claves y en los
que el alumno debería de centrar la atención.
Criterios de resolución
• Cuestión 1 – Principios de Auditoría
Explicar porque la independencia es uno de los principios de auditoría y de
qué manera afecta al resultado y validez de una auditoria.
Tomando el escenario de la empresa ejemplo descrita en el anexo, imaginad
y describid 3 situaciones en las que se plantee un conflicto de independencia
de la auditoria. Al menos 1 de estas situaciones debe ser una auditoria de 1ª
parte realizada por una entidad externa. Explicad las razones y en qué modo
afectaría a los resultados de la auditoria.
Puntos de material del curso importantes:
Módulo 1 – Introducción a la auditoría informática
Punto 1.1 Principios de auditoría
Punto 2.1 Tipos genéricos de auditoría
La respuesta ha de contemplar 2 aspectos, una explicación teórica sobre el

concepto de independencia del auditor y luego la aplicación práctica en 3
ejemplos.
En la explicación teórica se debe mostrar que se ha comprendido
correctamente la relación entre los objetivos de la auditoría, y la
independencia del equipo auditor respecto del objeto auditado, y explicar
correctamente como el resultado de una auditoria sin suficiente
independencia no es de utilidad para el cliente de la auditoría, aunque este
cliente sea el propio auditado (caso de auditoría de 1ª parte). Esta
independencia debe verse como circunstancias intrínsecas al auditor (por
relaciones personales o profesionales o circunstancias financieras propias
1
también) y las extrínsecas relacionadas con la organización (relaciones

empresariales entre cliente, auditado y auditor que pudieran afectar a la
independencia de la propia entidad auditora) a la que pertenece y que a pesar
de su buen hacer profesional, podría poner en tela de juicio la objetividad de
los resultados. En este sentido, como valor añadido al ejercicio se puede
hacer mención a marcos legales de auditorías de cuentas que suelen definir
en leyes (en España Ley 22/2015, de 20 de julio, de Auditoría de Cuentas) de
manera más precisa los requerimientos que tienen que complir los auditores
(de cuentas) para preservar la independència de la auditoria. También será
muy positivo si se relaciona con otros principios de la actividad auditora como
“presentación justa”, “código ético” y “debido cuidado profesional” ya que se
puede relacionar fácilmente la falta de independencia del auditor con la
puesta en duda de cualquiera de estos otros 3 aspectos que debe cumplir el
trabajo de un auditor. Ahora bien, uno de los errores a no cometer es
confundir “independencia” con “código ético” y “profesionalidad”, ni en la
explicación teórica ni en los ejemplos.
En la parte práctica no existe ningún tipo de situación previa que se considere
más acertada que otra. El alumno puede presentar cualquiera dentro del
contexto de la empresa de ejemplo que se proporciona en el anexo. Sí que
será necesario que el alumno explique quienes son los distintos actores de la
auditoria (auditor, auditado y cliente de la auditoría) tanto para dar ejemplo de
situaciones que pongan en peligro la independencia tanto como para explicar
cuál es el ejemplo escogido de auditoría de 1ª parte (el cliente de auditoría y
el auditado son la misma organización) y mostrar que se entiende el concepto
de auditorías de 1ª parte.
Un simple ejemplo válido de auditoría de 1ª parte con el principio de auditoría
puesto en compromiso sería el siguiente: El área de Seguridad ha identificado
el sistema de control de proyectos como un sistema con un alto valor en el
análisis de riesgos por la criticidad para el negocio de la información que
maneja (código fuente de productos, planes de desarrollo, documentación,
etc.) y necesita tener una mejor percepción de los riesgos que le afectan y por
tanto desea que se realice una auditoría de dicho sistema. Esto es claramente
una auditoría de 1ª parte puesto que la misma entidad es a la vez el cliente de
la auditoría y el auditado. La auditoría será ejecutada y gestionada desde
Revisión Interna pero su personal no tiene los suficientes conocimientos
técnicos para ejecutar las tareas concretas de auditoría y por tanto deberá
contar con expertos de fuera de su área. Se decide contratar a una empresa
externa para realizar dichas tareas. Dicha empresa es colaboradora con el
proyecto Opensource que desarrolla el producto sobre el que se ha
desarrollado el sistema de control de proyectos. Este último hecho pone en
duda la independencia de los expertos de la entidad externa que ejecutan las
tareas de auditorías y por tanto el resultado final de la auditoría. La empresa
2
externa debería de poner este hecho en conocimiento del cliente de la

auditoría.
• Cuestión 2 – Programa de Auditoria

Describid qué aspectos mínimos debe incluir el Programa de Auditoría y
porqué, basándoos en cual es el objeto de disponer de un Programa de
Auditoría que determina el modo en que se organiza la Función de Auditoría
de una organización.
Tomando el escenario de la empresa ejemplo descrita en el anexo. Proponed
una estructura de personas para el Área de Revisión Interna que sería la que
implementaría la Función de Auditoría. Indicad los roles que se deben cubrir
con sus características y papel dentro del grupo. Por último, reflexionad y
exponed qué problemas de dimensionamiento y disponibilidad de recursos se
le plantearían a la organización y qué opciones podéis proponer para
resolverlas.
Punto 4 Programa de auditoría
Punto 4.2 Establecimiento de un programa de auditoría
Nuevamente la respuesta ha de contemplar 2 aspectos, una xplicación

teórica sobre los aspectos fundamentales de un Programa de auditoría y
luego una reflexión para dar un ejemplo de posible organización del área
auditora
A pesar de ser una cuestión importante y útil (la organización ISO lo incluye
dentro de las Directrices que da a las entidades de certificación para la
auditoría de Sistemas de Gestión de la Calidad y Medioambientales, la norma
ISO 19011, y en la norma ISO 27007 que da las directrices específicas para
auditoría interna o externa de SGSI), es poco conocido fuera del ámbito
profesional de la auditoría formalizada (por ejemplo entidades de certificación
o de acreditación) y puede ser confundido con el uso del término “Programa”
por organizaciones como ISACA para definir procedimientos de auditorias con
un alcance muy concreto y que facilita en su sitio web1. Por lo tanto puede ser
difícil de expresar por el alumno, por lo que se valorará el modo en que se ha
1
http://www.isaca.org/Knowledge-Center/Research/Pages/Audit-Assurance-Programs.aspx
3
reflejado el contenido del punto 4 del material del curso y en concreto el punto
4.2. De este último punto se debe reflejar los siguientes aspectos
• Una declaración de misión o la Carta de Auditoría: una declaración
que esboce el propósito, objetivos, organización, autoridades y
responsabilidades del auditor interno, el personal de auditoría, gestión
de auditoría y el comité de auditoría, y demuestre el soporte que esta
función de auditoría recibe por parte de la dirección de la organización.
• Un proceso de evaluación de riesgos para describir y analizar los
riesgos inherentes de la actividad de auditoría dentro de la
organización. Los auditores deben actualizar la evaluación del riesgo
por lo menos una vez al año, o más frecuentemente si es necesario,
para reflejar los cambios de control interno o de los procesos de
trabajo, e incorporar nuevas líneas de negocio. El nivel de riesgo debe
ser uno de los factores más significativos en cuenta para determinar la
frecuencia de las auditorías. En el caso de una función de auditoría
orientada al control de la Seguridad de la Información, este análisis del
riesgo iría alineado con el propio del SGSI. En definitiva, este análisis
del riesgo debe ser empleado para definir los puntos principales a los
que debe orientarse la actividad auditora.
• Un plan general de auditoría que detalla los procesos de financiación y
planificación. El plan debe describir los objetivos de la auditoría,
planificaciones, necesidades de personal, y presentación de informes.
El plan de auditoría debe abarcar al menos 12 meses (menos tiempo
podría no ser aplicable, aunque sí que podría ser más largo, por
ejemplo planes bienales) y debe ser definido por la combinación de los
resultados de la evaluación del riesgo y los recursos necesarios para
cumplir las planificaciones y frecuencia de las auditorías internas
previstas. Un comité de auditoría debe aprobar oficialmente el plan
general de auditoría anual, o lo modificará anualmente en el caso de
los planes de auditoría de varios años. Los auditores internos deben
informar de la situación de las auditorías previstas versus realizadas, y
cualquier cambio en el plan anual de auditoría, al comité de auditoría
para su aprobación en forma periódica.
• Un ciclo de auditoría que identifica la frecuencia de las auditorías. Los
auditores suelen determinar la frecuencia mediante la realización de
una evaluación de riesgos, como se señaló anteriormente, de las
áreas a auditar. Si bien la disponibilidad de personal y el tiempo
pueden influir en el ciclo de auditoría, no deben ser factores
primordiales para reducir la frecuencia de las auditorías a las zonas de
alto riesgo.
• Programas de Trabajo de Auditoría que se establece para cada área
de auditoría el alcance y los recursos necesarios, incluida la selección
4
de los procedimientos de auditoría, el alcance de las pruebas, y la

base para las conclusiones. Bien planificadas, bien estructurado, los
programas de auditoría son esenciales y muy útiles para la gestión del
riesgo y el desarrollo de sistemas integrales de control interno.
• Informes de Auditoría que informan a la Dirección o gerencia de
departamentos concretos de la Organización del cumplimiento de
políticas y procedimientos. Estos informes deberán precisar si los
procesos operativos y los controles internos son eficaces, y describir
las deficiencias, así como las acciones correctivas sugeridas. El
director de auditoría puede considerar la implementación de un
sistema de clasificación de los resultados de las auditorías (por
ejemplo, satisfactorio, necesita mejora, insatisfactorio), aprobado por
el comité de auditoría. El sistema de clasificación facilita el transporte
a receptor de los informes una evaluación coherente y concisa de los
riesgos que afronta el área o función auditada. Todos los informes de
auditoría por escrito debe reflejar la calificación determinada para cada
una de las áreas auditadas.
• Requisitos para el tratamiento de toda la documentación de la
actividad de auditoría para asegurar un apoyo y seguimiento claro a
todos los resultados de la auditoría y el trabajo realizado, incluyendo
las políticas de retención de la información de trabajo
• Procesos de Seguimiento que requieren los auditores internos para
poder determinar la necesidad de cualquier acción correctiva acordada
para corregir las deficiencias significativas en el proceso de auditoría
(deficiencias en el proceso y también deficiencias de capacitación de
los recursos, o insuficiencia de recursos). En este sentido es de
especial utilidad si el programa de auditoría es capaz de incluir
métricas e indicadores que ayuden a la detección de puntos de
mejora. Este punto es importante y su existencia o no es un indicio
muy claro de la madurez del proceso de auditoría.
• Programas de desarrollo profesional para el personal de auditoría de
la organización para mantener sus competencias técnicas necesarias.
Estas acciones de capacitación pueden estar planificadas de
antemano (al estilo de las certificaciones que requieren que se
cumplan un número mínimo de horas de formación o similar) o bien
pueden surgir como resultado del proceso de seguimiento del
programa de auditoría.
Respecto a la estructura de organizativa del área auditora en la empresa

ejemplo, no hay un estructura más adecuada que otra, pero el alumno deberá
mostrar que ha reflexionado en cuanto a los objetivos que esa estructura
5
debe cumplir y como adecúa la estructura para conseguirlo. Es decir, si se

decide que el área debe cubrir todas las facetas de auditoría incluida la
ejecución, el equipo debe ser mucho más amplio, si en cambio se va a optar
por la contratación de servicios externos, incluso si se trata de auditorías de
1ª parte o de 2ª pero solicitadas por la empresa XXXXX.SA, entonces el
equipo será más reducido y únicamente contaría con perfiles de auditores jefe
que en gran parte de las ocasiones realizarán funciones de gestores de
proyecto, en este caso de auditorías ejecutadas por externos.
• Cuestión 3 – Planificación de auditoría y gobierno de las TIC

Tomad de nuevo la empresa ejemplo como escenario del ejercicio. Suponed
que sois el responsable de seguridad. Puesto que la empresa dispone de un
SGSI que supondremos certificado, deberá existir una función de Auditoría y
el SGSI tiene que mejorarse. Esta mejora continua está basada entre otras
cosas en los resultados de auditorías internas (ejecutadas o no por personal
interno pero en todo caso son lo que se entiende por auditorías de primera
parte), y por lo tanto es necesario que la organización planifique las auditorías
que realizará a lo largo del año y también a lo largo del periodo de 3 años que
tiene de validez el certificado del SGSI.
Esta cuestión os pide que os planteéis cual podría ser la planificación de
auditoría para un año, indicando si las acciones de auditoría son puntuales o
si son repetitivas durante el año, de año o cada más años (pensad que el
marco temporal que se tiene que tener en cuenta sería los 3 años del periodo
de validez de la certificación del SGSI).
Para cada acción de auditoría describir cual será el alcance sin extenderse
demasiado (un párrafo con 3 ó 4 frases debería de ser suficiente).
Punto 4 Programa de auditoría
Punto 6 Gobierno de las TIC
Este punto es totalmente práctico y sería la implementación de uno de los
aspectos a tener en cuenta en un programa de auditoría.
Para la evaluación de este punto se tendrá en consideración que el plan de
auditoría que el alumno debe presentar debería tratar los siguientes puntos:
• Situarse dentro del alcance del SGSI: las acciones propuestas deben
de estar alineadas con el del SGSI
• Para cubrir adecuadamente el alcance del SGSI y también el objetivo
de controlar el propio funcionamiento del SGSI, el plan de auditoría
global deberá contemplar tanto auditorías de tipo organizativo del
6
SGSI (comprobación de funcionamiento operativo del SGSI,

comprobación interna de la consecución de los objetivos, métricas,
indicadores y mejora continua del SGSI, verificación del nivel de
cumplimiento de los requerimientos de la norma ISO 27001), como
técnicas destinadas a verificar el funcionamiento de controles de la
norma ISO 27002 que se hayan aplicado.
Como para el alumno en este apartado puede no tener conocimiento
sobre los SGSI no será determinante este punto, pero si será
necesario que las acciones descritas serán coherentes, dentro del
alcance y con una amplitud suficiente para cubrir al menos la
verificación de la mayoría de aspectos de la ISO 27002.
• Las acciones de auditoría deberán estar distribuidas a lo largo del
tiempo, y algunas de las acciones se repetirán con una cierta
frecuencia mayor o menor a la anual según convenga. Por ejemplo,
las acciones de auditoría destinadas a comprobar el funcionamiento
del SGSI tendrán una frecuencia como mínimo anual, ya que
anualmente se realiza una auditoría de certificación, mientras que una
determinada área de controles de seguridad, puede tener una
frecuencia más baja como por ejemplo 1 vez cada 2 ó 3 años.
El alumno deberá reflejar y proponer unas frecuencias que sean
lógicas y “repetibles”, es decir, a acciones similares, una frecuencia
similar y si no es así explicarlo de manera razonada.
7
Auditoría de Certificación
ISO/IEC-27001
01 Presentación
02 Auditoría de certificación ISO

27001
03 Solución PEC 2
-1-
Universitat Oberta
de Catalunya
Aula
Módulo 2 - Auditoría de Certificación ISO/IEC-27001
Inicio: Fin:
07/03/22 27/03/22
00:00h 24:00h
europea (CET) europea (CET)
Materiales
Auditoría de certificación ISO 27001

Audiolibro
ePub
Mobipocket
html5
Pdf
Auditoría de
certificación ISO
27001
PID_00285947

© FUOC • PID_00285947 Auditoría de certificación ISO 27001

caciones por la Universidad Politéc-
nica de Valencia. Consultor en segu-


Producción: FUOC
© FUOC • PID_00285947 Auditoría de certificación ISO 27001
Índice
Introducción............................................................................................... 5
1. Sistemas de gestión de la seguridad de la información........... 7

1.1. Gestión de los riesgos de la información ................................... 7
1.2. Sistemas de gestión ..................................................................... 12
1.3. Procesos de mejora continuada .................................................. 13
1.4. Retorno sobre la inversión de un SGSI ....................................... 15
1.5. Beneficios generales de los SGSI ................................................. 16
1.6. Familia de estándares ISO/IEC 27000 ......................................... 18
2. Certificación de SGSI contra el estándar ISO/IEC 27001......... 23

2.1. Beneficios de la certificación ...................................................... 23
2.2. Reconocimiento de la certificación ............................................ 26
2.3. Reconocimiento de la entidad de acreditación .......................... 27
2.4. Requerimientos de una entidad de certificación ........................ 28
2.4.1. Requerimientos generales .............................................. 29
2.4.2. Requerimientos específicos sobre el proceso de
certificación .................................................................... 32
2.5. Tipos de auditoría en el proceso de certificación ....................... 33
2.6. Estructura del estándar ISO/IEC 27001 ....................................... 34
2.6.1. Definir el contexto de la organización .......................... 38
2.6.2. Soporte y liderazgo por parte de la alta dirección ......... 39
2.6.3. Planificación .................................................................. 40
2.6.4. Soporte ........................................................................... 41
2.6.5. Operación ....................................................................... 43
2.6.6. Evaluación del desempeño ............................................ 43
2.6.7. Mejora ............................................................................ 45
3. Proceso de certificación de SGSI contra la ISO 27001.............. 46

3.1. Objetivos del proceso de auditoría de certificación .................... 46
3.1.1. Revisión de la implantación del modelo mejora
continua ......................................................................... 46
3.1.2. Revisión de los controles ISO/IEC 27002 ...................... 48
3.2. Proceso de auditoría .................................................................... 49
3.2.1. Diagrama del proceso de auditoría ................................ 49
3.2.2. Fase de solicitud de la certificación ............................... 51
3.2.3. Planificación y dimensionamiento de la auditoría ........ 51
3.2.4. Stage 1. Auditoría documental ...................................... 58
3.2.5. Stage 2. Auditoría presencial o ''in situ'' ........................ 62
© FUOC • PID_00285947 5 Auditoría de certificación ISO 27001
Introducción
En el módulo anterior de introducción a la auditoría informática, se han pre-

sentado los principios generales del proceso de auditoría y las auditorías sobre
los sistemas de información, dentro del contexto del buen gobierno TIC. Para
garantizar el buen gobierno corporativo, cada vez más es necesario que tam-
bién se garantice el buen gobierno o gestión de los sistemas de información
o, de manera general, de la información.
El gobierno de las TIC es correcto cuando su gestión se encuentra ali-

neada con los objetivos de negocio, se conocen los riesgos que afectan
a los sistemas de información, y se gestionan adecuadamente.
Las auditorías internas son una herramienta para el gobierno de las TIC, y
sirven para que la propia dirección de una organización conozca el modo en
que se gestionan los riesgos, y para demostrar a otras organizaciones su postura
frente a los riesgos que afectan a la información. De este modo, en el módulo
anterior, se han presentado dos grandes tipos de auditorías relacionadas con la
protección de la información: auditorías técnicas de seguridad de los sistemas
de información, y auditorías de certificación de los sistemas de gestión de la
seguridad de la información.
Ambos tipos de auditorías tienen por objeto final el hecho de ofrecer al cliente
de la auditoría una visión del estado en que se está gestionando la seguridad de
la información. Sin embargo, esta visión se ofrece desde puntos de vistas dis-
tintos. Las auditorías técnicas de seguridad comprobarán aspectos concretos
de la implementación de los controles aplicados, mientras que las auditorías
de certificación de un sistema de gestión de la seguridad de la información
tienen un objetivo más genérico: comprobar si el proceso de gestión se está
realizando con arreglo a ciertos requerimientos. Estos requerimientos han sido
recogidos en la Norma ISO/IEC 27001 (la última versión de este material era
de 2013, con correcciones realizadas en 2014 y 2015. En un futuro, se puede
prever que será actualizada de nuevo para mantenerse alineada tanto con la
tecnología como con el entorno de riesgo tecnológico y las propias activida-
des de ISO, lo cual en parte fue la razón que impuso la modificación entre las
versiones de 2005 y 2013).
Por lo tanto, podemos observar que el primer tipo de auditoría se integra en el

propio esquema de gobierno de las TIC, y suele tratarse de auditorías de prime-
ra parte. También pueden existir como de segunda parte, en circunstancias en
las que el cliente de la auditoría desea comprobar el modo en que el auditado
gestiona su información. En este caso, el cliente de la auditoría técnica de se-
guridad tiene un interés legítimo en garantizar la seguridad de la información

gestionada por el auditado. Por ejemplo, el auditado puede estar tratando in-
formación perteneciente al cliente de la auditoría en el marco de un contrato.
Por otra parte, las auditorías de certificaciones son puramente de tercera par-
te, y además tienen un objeto más general. No se trata de comprobar la im-
plementación de controles concretos, sino que se centran en la verificación
del propio esquema de gestión con el que se estén controlando los riesgos. Es
decir, las auditorías de certificación incluyen la comprobación de los mecanis-
mos de gestión de los riesgos, y las auditorías internas son uno más de estos
mecanismos. Por tanto, en vista del resultado de una auditoría de certificación
(es decir, mediante el certificado emitido por la organización auditora), una
organización externa puede estar segura, en cierto modo, de que se están rea-
lizando auditorías internas y de que éstas son adecuadas de cara a gestionar
los riesgos sobre la información.
En este módulo, nos centraremos en los aspectos que hacen de la auditoría de

certificación una herramienta interesante para las organizaciones y, posterior-
mente, en el modo en que éstas se desarrollan.
1. Sistemas de gestión de la seguridad de la

información
En la actualidad, se reconoce que la forma más eficaz de controlar los riesgos

que amenazan la información, y por consiguiente el negocio, es mediante la
implantación de un sistema de controles internos en la organización para ges-
tionar el riesgo.
La gestión del riesgo ha estado tradicionalmente asociada a la gestión de ries-

gos financieros. Sin embargo, tal y como se ha dicho ya anteriormente, la im-
portancia que han ido adquiriendo los sistemas de información ha llegado
hasta el punto de que los riesgos que se gestionan en una organización ya no
son principalmente financieros, sino que se complementan con los riesgos a
los que está sometida la información. Esto es debido a la elevada integración
entre el estado financiero de una organización y los activos de información.
Los riesgos en la confidencialidad, integridad o disponibilidad de un determi-
nado activo de información pueden repercutir directamente en los aspectos
financieros. La primera causa de esto es la dependencia de los procesos orga-
nizativos en los sistemas de información, y la segunda es la aportación que
hace la información a la generación de valor en la organización.
Este nuevo escenario ha hecho que, actualmente, las organizaciones presten

una atención creciente a gestionar los riesgos que amenazan a su información
y a los sistemas TIC que la tratan. El modo en el que se tratan estos riesgos,
como veremos a continuación, también ha variado.
1.1. Gestión de los riesgos de la información
Una visión muy extendida del modo de gestionar los riesgos relacionados con
la información, y especialmente los sistemas de información, ha sido la visión
bottom-up. Según esta visión, las acciones sobre los controles a implantar se
deciden a un nivel táctico, teniendo en cuenta la tecnología disponible. Son
acciones de orden más preciso, ajustadas a una situación concreta y tomadas
sobre el terreno. En ocasiones, las decisiones se toman en base a la percepción
directa del riesgo y, en ciertos casos, incluso cuando el riesgo en sí ya se ha
materializado. Por ello, estas acciones no son tomadas en el ámbito de una
decisión estratégica de la dirección de la organización, sino siempre teniendo
en cuenta las circunstancias concretas de la realidad. De este modo, el resul-
tado tiende a ser un simple agregado de controles, al cual le falta una visión
de conjunto y coherencia.
De esta visión reactiva de la gestión de la seguridad se ha pasado a un enfoque

holístico de la seguridad de la información. Con este nuevo enfoque, la segu-
ridad de la información se gestiona no sólo cuando la información es tratada
por los sistemas TIC, sino que se gestiona durante todo su ciclo de vida: des-
de el momento en el que la información entra en la organización, hasta que
desaparece. Por tanto, los controles necesarios para gestionar el riesgo tendrán
que tener en cuenta no sólo los sistemas informáticos y las redes de comuni-
caciones, sino también las personas y los procesos que éstas ejecutan.
Por otra parte, para abordar este enfoque se necesitan unas herramientas para
comprender los riesgos, tomar decisiones y medir los resultados que se han
obtenido. Por tanto, es necesario que se realice un proceso de gestión de los
riesgos más metódico.
De esta manera, podemos representar el proceso de gestión del riesgo mediante

el siguiente diagrama:
Proceso de gestión continua del riesgo
Este proceso de gestión del riesgo emplea sus propias técnicas, metodologías y
herramientas, las cuales serían materia para otro curso como el presente. Sin
embargo, podemos resumir las tareas que conllevan los sistemas de gestión de
la seguridad de la información de la manera siguiente:
• Análisis del riesgo

– Establecer el contexto en el que se va a analizar el riesgo, tanto en
cuanto a los propios activos de información a analizar, como a las ame-
nazas que se van a considerar.
– Identificar amenazas potenciales y vulnerabilidades en los activos que

podrían ser explotadas.
– Evaluar el riesgo mediante la estimación de la probabilidad de ocu-

rrencia de la amenaza y del impacto.
Tratamiento del riesgo. En base a los distintos niveles de riesgo determi-

nados, se ofrecen tres alternativas:
– Mitigar el riesgo. Se aplican controles que pueden tener como objeti-

vo la reducción de la probabilidad de ocurrencia, la reducción del im-
pacto o, más directamente, la reducción de la importancia del activo
amenazado. A partir de estas medidas, el nivel de riesgo resulta menor
que si no existiera salvaguarda para controlarlo. El grado máximo de
reducción, difícilmente alcanzable, será el punto en el que el riesgo
pueda ser eliminado.
– Aceptar el riesgo. Ya bien sea porque el coste o la complejidad de im-

plementar el control lo hace inviable, o extremadamente costoso, la
organización decide aceptar un determinado nivel de riesgo.
Esta opción debe ser tomada con extremado cuidado, y sólo si antes
se han evaluado todos los posibles controles que mitiguen el riesgo
(aunque sólo sea parcialmente). Se dice entonces que existe un riesgo
residual que no puede ser controlado y se ha de aceptar.
– Transferir el riesgo. Con el objeto de tener absolutamente controlados

todos los riesgos, existe la posibilidad de transferir el riesgo financie-
ro que se deriva mediante una póliza de seguro. Esta opción suele ser
tenida en cuenta en escenarios maduros de gestión del riesgo, puesto
que las primas de estos seguros pueden ser muy elevadas si la organi-
zación no demuestra que todos los riesgos son gestionados hasta un
buen nivel.
• Evaluación del riesgo residual y replanteamiento del escenario de riesgo.

Una vez realizado el ejercicio anterior de análisis y tratamiento, el riesgo
tiene que ser continuamente gestionado, puesto que cambia la naturaleza
de los riesgos antiguos, y surgen nuevos riesgos: las tecnologías evolucio-
nan, la importancia de los activos de información cambia, nuevos activos
aparecen y otros desaparecen, etc. Esto implica la necesidad de revisar, pe-
riódicamente, el modo en que ha cambiado la exposición al riesgo y el
modo en que los controles existentes deben también cambiar. Este proceso
de revisión provoca a su vez que se reinicie el proceso de gestión del riesgo.
Es interesante destacar que, con el objetivo de aplicar las mejores prácticas que
haya en el sector, las organizaciones tienen a su disposición diferentes tipos de
catálogos de controles de seguridad. Los más extendidos actualmente, sobre
todo por su amplitud y cobertura de mayores tipos de riesgo, son el estándar
ISO/IEC 27001 y el catálogo COBIT de ISACA. En entornos gubernamentales
(tanto para las mismas entidades públicas como en ciertas circunstancias para
las privadas que trabajan para la Administración pública) existen otros esque-
mas de controles como NIST SP 800-53 Controles de seguridad y privacidad para
sistemas de información y organizaciones federales de los EE. UU. o el Esquema
Nacional de Seguridad (ENS) que “tiene por objeto establecer la política de
seguridad en la utilización de medios electrónicos […], y está constituido por
los principios básicos y requisitos mínimos que garanticen adecuadamente la
seguridad de la información tratada” por la Administración pública, ya sea di-

rectamente o por alguno de sus proveedores. Estos catálogos son ampliamente
empleados como referencia por las organizaciones a la hora de implementar
los controles de seguridad.
Es interesante en este punto, y para el resto de este módulo, introducir la fa-

milia de normas ISO/IEC 31000. Este conjunto de normas de bastante recien-
te creación (todas ellas publicadas como primera versión en 2009) se creó pa-
ra, de manera general, dar un marco genérico para la gestión del riesgo a las
organizaciones que estén preocupadas por gestionar un proceso en relación
con riesgos, con independencia de su sector. El estándar describe un proceso
completo de gestión del riesgo, basado en un ciclo de mejora continuada. Es
decir, lo afronta desde su definición, diseño, implementación, control y me-
jora. También introduce un cambio en el concepto de riesgo. Las principales
normas que se han publicado son:
a) ISO 31000:2018 - Risk management - Principles and guidelines, que básicamen-

te define:
• Principios de la gestión del riesgo:

– Debe aportar valor a la organización.
– Debe ser una parte integrada en los procesos organizativos.
– Tiene que incorporarse a los procesos de toma de decisiones.
– Debe tener en cuenta explícitamente las incertidumbres que puedan

existir en el entorno.
– Debe ser un proceso que ha de basar sus conclusiones en la mejor in-

formación disponible en el momento.
– Debe ejecutarse siguiendo métodos sistemáticos, estructurados y en un

marco temporal preciso, pero adecuado al contexto de la organización,
así como a factores humanos y culturales.
– El proceso debe ser dinámico, iterativo y capaz de adaptarse al cambio

para permitir que la organización pueda mejorar de manera continua-
da.
• Marco de referencia para un proceso de gestión del riesgo que, más que
encontrarse de manera autónoma en la organización, se integre en el pro-
ceso de gestión al que ha de aportar valor. Por lo tanto, el propio proce-
so de gestión del riesgo sigue un modelo de mejora continua PDCA (más
adelante en este módulo se profundiza sobre este concepto) que, a partir
de un mandato de la organización y una asignación de responsabilidades,
define un proceso iterativo con unas fases generales de:
– Diseño del marco de proceso de gestión de riesgos (delimitar el con-

texto, la política de gestión de riesgos, las responsabilidades, los recur-
sos, la integración con otros procesos organizativos, los mecanismos
para la comunicación y el reporte de los resultados).
– Implementación de la gestión del riesgo, fase en la que de manera efec-

tiva se realiza el ejercicio de percepción del riesgo (en inglés risk assess-
ment).
– Monitorización y mejora del marco del proceso de gestión del riesgo

para obtener mejores resultados en sucesivas iteraciones.
• Por último, definición de las fases que se deben seguir en el ejercicio de

percepción del riesgo y que son las siguientes:
– Establecer el contexto (viene de fases anteriores).
– Identificar riesgos: definir los escenarios de riesgo, es decir, qué puede

pasar, cuándo, dónde, de qué modo, por qué razones.
– Analizar los riesgos: determinar con qué probabilidad se puede dar un

determinado escenario, identificar qué controles existen ya y determi-
nar qué consecuencias pueden producirse, para poder dar un nivel a
ese riesgo.
– Evaluar los riesgos. Esta fase debe tomar del contexto los niveles de
riesgo que son apetecibles para la organización, los cuales pueden ir
variando a lo largo de la ejecución continuada del proceso de gestión
de riesgos, y que ayudarán a priorizar los riesgos en la fase de trata-
miento.
– Tratar los riesgos: seleccionar las distintas opciones de tratamiento del

riesgo (vistas anteriormente), y preparar e implementar los planes para
el tratamiento del riesgo.
Estas son las tres grandes partes de este marco.
b) ISO Guide 73:2009 - Risk management - Vocabulary. Este documento viene

a dar las definiciones y es interesante puesto que matiza y define conceptos
con precisión, como el del propio riesgo. El riesgo ya no se percibe como un
aspecto negativo en el sentido de "posibilidad de pérdida", sino simplemente
como el efecto de la incertidumbre en la consecución de los objetivos. Como
se puede observar, ya no se habla de pérdida, sino de incertidumbre, y esto se
puede considerar como una oportunidad, tanto en negativo como en positivo.
Pero de todos modos, se sigue viendo el riesgo como la combinación de las
consecuencias de un evento y su probabilidad de ocurrencia.
c) ISO/IEC 31010:2019 - Risk management - Risk assessment techniques. Este do-

cumento da más detalles sobre la fase concreta del ejercicio de percepción del
riesgo (risk assessment) introducido en la norma ISO 31000.
En sí mismas, ninguna de estas normas de la familia ISO/IEC 31000 es certi-

ficable, pero sí tienen un gran impacto sobre la certificación de sistemas de
gestión. Respecto a este nuevo marco, se están modificando los estándares que
definen los requerimientos de los sistemas de gestión normalizados por ISO/
IEC, así como los de calidad, gestión medioambiental y, también, el que más
nos ocupa en este curso de gestión, la seguridad de la información. Todos ellos
están basados en la gestión del riesgo y en el proceso de control por medio
del ciclo de mejora. Al tener varios puntos en común, más allá de su especifi-
cidad, ISO/IEC ha decidido definirlos todos de manera coherente e igual. Esto
se ha reflejado en un documento general, denominado Directivas - Parte 1,
que describe el modo de funcionamiento de ISO/IEC en su día a día para el
desarrollo de normas ISO. Aparte de describir el modo de funcionamiento de
todos sus comités, en los anexos se dan detalles concretos sobre la forma de
trabajar, las fases y, en su anexo SL, se dan las indicaciones sobre el modo que
se ha seguir para desarrollar nuevos estándares para sistemas de gestión. En
su apartado SL.9, se define claramente la estructura que todos los estándares
de sistemas de gestión deberán seguir y, en el apéndice 2, se dan los puntos
concretos que debe tener el texto de una norma de este tipo. La ISO/IEC27001,
en su versión de 2013, fue la primera en adoptar esa estructuración, en la que
se puede observar que la base de todos los sistemas de gestión debe estar en la
identificación de riesgos y oportunidades. Se basa en el modo de concebir el
riesgo descrito en la Guía 73, mencionada anteriormente, y por tanto, las or-
ganizaciones pueden tomar la norma ISO/IEC 31010 como el modo de apro-
ximación a la tarea de identificar y gestionar los riesgos.
1.2. Sistemas de gestión
El proceso descrito en el punto anterior puede ser institucionalizado. Es decir,

puede ser descrito, documentado y, finalmente, implementado a partir de los
siguientes elementos: primero, un conjunto coherente y organizado de con-
troles de seguridad; segundo, unos procesos para gestionar y revisar estos con-
troles; tercero, unas personas encargadas de realizar estos procesos; y cuarto,
unos recursos con una componente más o menos técnica que permiten im-
plementar los controles y gestionarlos. Lo más destacado de este proceso es
que será cíclico. El proceso contendrá mecanismos que permiten el análisis del
modo en que se está desarrollando y, en base a las conclusiones, se reajustará
el proceso. De esta manera, se irá mejorando de manera continua y paulatina
la eficacia de los controles de seguridad.
Cuando este tipo de procesos se establece en una organización, se dice que

existe un sistema de gestión. El sistema de gestión, en este caso, tiene por
objeto garantizar la seguridad (confidencialidad, disponibilidad e integridad)
de la información, y se denomina sistema de gestión de la seguridad de la
información (SGSI).
De manera general, se entiende por un sistema de gestión al conjunto de perso-

nas, procesos y tecnologías de una organización que trabajan, conjuntamente,
para gestionar y controlar unas determinadas actividades de la organización.
Cuando estas actividades son las necesarias para garantizar la seguridad (con-
fidencialidad, disponibilidad e integridad) de la información de una organi-
zación, nos encontramos ante un sistema de gestión de la seguridad de infor-
mación, SGSI. Dentro de este sistema, por tanto, se encontrará la gestión de
los sistemas de información, al ser los principales elementos que almacenan
y tratan la información.
Cada organización tiene sus propios objetivos, cultura y medios para imple-
mentar un SGSI. Sin embargo, con independencia de sus características pro-
pias, todos los sistemas de gestión (calidad, medioambiental, etc.) tienen cier-
tos puntos en común, ya que se basan en la implementación de un ciclo de
mejora para controlar y mejorar la actividad. Existen diversos modelos (como
los propuestos por Six-Sigma), pero el más conocido, el que ha inspirado otros,
y que es empleado en el contexto de los SGSI históricamente, es el llamado
ciclo de Deming, aunque tal y como se hizo en la revisión de la norma ISO/
IEC 27001 llevada a cabo en 2013, se flexibilizó la definición de requerimien-
tos y ya se define completamente alineado con este modelo PDCA, que, no
obstante, es válido para entender qué es un proceso de gestión continuada de
una actividad.
1.3. Procesos de mejora continuada
Existen varias formas de diseñar un sistema para la gestión de la seguridad

de la información y, en general, cualquier proceso que requiera un control y
ajuste continuados. Históricamente y en el contexto del control de calidad
de procesos industriales, surgió el modelo de Deming de mejora continuada,
conocido por sus iniciales en inglés PDCA (plan, do, check, act; en castellano,
‘planificar, implementar, verificar, actuar’), que se extendió a muchos otros
ámbitos.
El modelo PDCA fue popularizado por Edward Deming, aunque él mismo re-
Modelo de sistema PDCA
conocía que el modelo ya había sido planteado por Walter A. Shewhart, ambos
científicos americanos dedicados al estudio de las matemáticas estadísticas y
al control de procesos y calidad. El proceso puede ser aplicado a la resolución
de cualquier tipo de problema mediante un método de aproximación progre-
siva. En lo que nos atañe, el objetivo a alcanzar es una utopía, por ejemplo la
calidad total o la seguridad completa de la información de una organización.
El proceso pretende avanzar hacia ese objetivo inalcanzable en sí mismo. Sin

embargo, la mera ejecución del proceso va permitiendo ir mejorando de ma-
nera continua y contrastada la eficacia y eficiencia del proceso.
Este modelo de mejora se ha tomado, desde el inicio de la labor de estanda-

rización de ISO, como la referencia a la hora de estandarizar sistemas de ges-
tión tales como los de gestión de calidad (ISO9001), gestión medioambiental
(ISO14001) y, más recientemente, gestión de la seguridad de la información
(ISO/IEC 27001).
Un sistema de gestión de la seguridad de la información, por tanto, será un

proceso con las características siguientes:
• Basado en un modelo iterativo de mejora.

• Integrado tanto por personas como por procesos y tecnología.
• Con mecanismos para la toma de decisiones basados en la realización de
un análisis de riesgos metódico.
• Con mecanismos de control riesgos recogidos en un conjunto de buenas
prácticas y reconocidos por el entorno en que se encuentre la organización.
Existen varias formas de diseñar un sistema para la gestión de la seguridad. Sin

embargo, si nos atenemos a lo que actualmente está reconocido y estandari-
zado internacionalmente, la opción más extendida es la implementación de
un SGSI basado en la Norma ISO/IEC 27001, que toma sus controles de segu-
ridad de la Norma ISO/IEC 27002, pero otros modelos serían válidos (CoBIT,
por ejemplo).
Tal y como hemos comentado, el modelo PDCA es uno de los más extendidos
y conocidos y, hasta la revisión de la norma ISO/IEC 27001 realizada por ISO
en 2013, se requería que el modelo del SGSI estuviera totalmente alineado con
él. Pero a partir de la revisión de las directrices generales de ISO y la inclusión
del anexo SL, en el apéndice 2 de ese anexo se da una definición más flexible
de los requerimientos que debe seguir el modelo de gestión para todos los
sistemas de gestión estandarizados por ISO y, en la práctica, se eliminó esta
referencia directa al modelo PDCA. Esta nueva especificación es más genérica
y puede adaptarse a otras metodologías, algunas muy populares como SIX-
SIGMA, aunque no por ello se ha eliminado el concepto de mejora continuada
basada en la planificación, implementación y corrección, puesto que todos
los modelos de mejora están inspirados de alguna manera en ese modelo. Sin
embargo, según la norma ISO/IEC 27002:2007, los requerimientos para los
sistemas de gestión ya no imponen un determinado modelo, pero sí incluyen
todos unos requisitos determinados que pueden ser ajustados y alineados con
las fases del modelo PDCA.
1.4. Retorno sobre la inversión de un SGSI
Cuando una organización implanta un SGSI siguiendo las directrices de un

estándar (esté posteriormente certificado o no), obtiene una serie de ventajas
que deben ser los motivadores máximos para la dirección. La motivación más
importante serán los beneficios económicos.
La implantación de un SGSI no reporta unos beneficios económicos directos

(aumentos directos de la cifra de negocio). Cuando menos, es muy complejo y
discutible encontrar generación de recursos como consecuencia de la implan-
tación de controles de seguridad. Por lo tanto, es difícil calcular su retorno so-
bre la inversión (ROI: return over investment) o, más concretamente, su retorno
sobre la inversión en seguridad (ROSI: return over security investment). Esto vie-
ne motivado por la dificultad de encontrar unos beneficios que se puedan re-
lacionar con la inversión realizada.
(1)
Es más habitual expresar el ROI de seguridad en términos de los ahorros o Ved, por ejemplo, estas otras
propuestas:
recursos que se dejarían de perder en caso de suceder un incidente. Es obvio
https://www.cisecurity.org/blog/
que un gasto que se deja de realizar es un beneficio indirecto. El problema es the-one-equation-you-need-to-cal-
culate-risk-reduction-roi/
que este beneficio sólo se obtiene en caso de materialización de la amenaza, https://www.csoonline.com/
y esto es precisamente lo que se desea evitar. Por lo tanto, el modo en que article/3229887/how-to-cal-
culate-your-return-on-secu-
se calcula el ROI es puramente teórico1, puesto que el beneficio no se está rity-investments.html
https://www.csoonline.com/ar-
obteniendo realmente. A pesar de ello, es posible evaluar este beneficio a través ticle/3010007/how-to-calcula-
de un análisis de riesgos detallado y cuantitativo en términos monetarios. te-roi-and-justify-your-cybersecu-
rity-budget.html
Una de las maneras más habituales de calcular el ROI de un SGSI es suponer

que se materializan las amenazas, y evaluar los costes de recuperar la situación
de normalidad con y sin las salvaguardas.
• Csin_ctrl: coste de recuperar la situación de normalidad en caso de mate-

rializarse unas determinadas amenazas sin existir los controles que están
bajo estudio.
• Ccon_ctrl: coste de recuperar la situación de normalidad en caso de mate-

rializarse unas determinadas amenazas con los controles que se están eva-
luado.
La diferencia entre ambas es el beneficio de tener implementadas las salva-

guardas. Sin embargo, no es realista presuponer que ese es el beneficio real
que se tendrá, puesto que no se realizará siempre sino sólo si las amenazas
se materializan. Así, puesto que las amenazas se materializan con una cierta
probabilidad anual, es posible multiplicar el beneficio por esta probabilidad,
y tendremos la estimación del beneficio anual esperado.
B anualizado_esperado = (Csin_ctrl - Ccon_ctrl) * P escenario_incidentes

Por otro lado, tendremos el costo de implantar los controles y el SGSI en sí

mismo (Cctrl). La división del margen (beneficio anual esperado menos el cos-
to de los controles) entre el costo nos dará el ROI.
ROI = (B anualizado_esperado - Cctrl.) / Cctrl
El cálculo es teóricamente simple de realizar, pero en la práctica nos encontra-

mos con muchas dificultades: hay muchas variables a la hora de calcular los
costes; es difícil predecir todos los costes de recuperación, y es especialmente
complejo y arriesgado dar unas cifras de probabilidad de materialización. Es
posible plantear el cálculo para la toma de decisión sobre un control concreto
(o conjunto de ellos), pero es complejo plantearlo para la toma de decisión de
implantar todo un SGSI. Por tanto, la dirección deberá considerar otra serie de
beneficios menos tangibles y mesurables.
1.5. Beneficios generales de los SGSI
Aparte de estos beneficios económicos indiscutibles, pero de difícil cuantifi-

cación, la implantación de un SGSI conlleva también las siguientes ventajas.
Éstas son fácilmente transmisibles a la dirección de una organización, a la hora
de conseguir su compromiso y apoyo para abordar las tareas de implantar un
SGSI y, muy especialmente, operarlo de manera efectiva:
• El SGSI permite conocer y analizar los riesgos que afectan a la informa-

ción. Se identifican amenazas y vulnerabilidades, de manera que se puede
evaluar el impacto de las mismas en la actividad empresarial, al menos de
manera cualitativa y priorizada.
• De una manera priorizada, coherente y organizada, se puede prevenir, eli-

minar o reducir eficazmente el nivel de riesgo. Esto se consigue mediante
la implantación de los controles adecuados, preparando el negocio ante
posibles emergencias y garantizando la continuidad del mismo.
• El conocimiento de los riesgos asegura el compromiso de la organización

con el cumplimiento de la legislación vigente. Por lo tanto, asegura el cum-
plimiento de la normativa de protección de datos de carácter personal,
servicios de la sociedad de la información, comercio electrónico, propie-
dad intelectual y, en general, aquella relacionada con la seguridad de la
información. A su vez, asegura la consideración de los marcos normativos
de gestión del riesgo (por ejemplo, Sarbanes- Oxley) que le fueran de apli-
cación.
• La ejecución del ciclo de Deming permite planificar, organizar y estructu-

rar los recursos asignados a la seguridad de la información.
• El proceso de análisis de riesgos y de gestión de los mismos permite defi-

nir objetivos y metas con los que aumentar el grado de confianza en la
seguridad.
• El SGSI permite establecer procesos y actividades de revisión, mejora con-

tinua y auditoría de la gestión y tratamiento de la información. Todo ello
facilita la aproximación progresiva a un estado óptimo de uso de recursos
y nivel de seguridad.
• El SGSI definido en la Norma ISO/IEC 27001 está basado en un modelo

de gestión común a otros sistemas de gestión que, habitualmente, ya se
encuentran en la organización. Por lo tanto, existe la posibilidad de inte-
grar la gestión de la seguridad de la información con el resto de sistemas
de gestión implantados. Así, se pueden conseguir sinergias y ahorros de
costes en algunos aspectos, como pueden ser los procesos de certificacio-
nes y las auditorías de primera parte del sistema de gestión.
• Garantizar el tratamiento seguro y correcto de la información mediante

el control de un SGSI aporta un valor añadido de confianza en la protec-
ción de la información. De este modo, permite mejorar la imagen de la
organización de cara a otras empresas, y se convierte en un factor de dis-
tinción frente a la competencia. En ocasiones, esta demostración puede
llegar a ser una exigencia contractual. No será extraño que, en un futuro,
las organizaciones que externalicen algún tratamiento de su información
soliciten a sus contratistas la certificación de su SGSI, para demostrar la
gestión segura de la información.
• Hoy en día, por el auge del tratamiento de la información con tecnologías

TIC, la implantación de un SGSI afectará directamente a las áreas TIC de
la organización. Por tanto, su implantación asegurará que la gestión de las
TIC está correctamente alineada con los objetivos de negocio.
• Finalmente, la existencia de un SGSI asegura que se tiene garantizada la

continuidad de los sistemas de información en caso de graves incidentes,
al menos para los procesos que se encuentran bajo el alcance del SGSI. Esto
es especialmente importante, y puede ser tomado como elemento clave,
a la hora de determinar el alcance del SGSI. La organización debe deter-
minar y conocer qué procesos son los críticos para la supervivencia de la
organización, qué escenarios de desastre le pueden afectar negativamente,
cuáles se van a controlar, y de qué modo se actuará. Todo ello es uno de
los pilares más importantes del SGSI.
1.6. Familia de estándares ISO/IEC 27000
En una clara demostración de la importancia que la seguridad de la informa-

ción tiene para el éxito de las organizaciones, la ISO y la IEC (International
Electrotechnical Comisión, organización de ámbito mundial dedicada a la es-
tandarización en el mercado de la electrónica y tecnologías relacionadas) han
elaborado conjuntamente todo tipo de normas, estándares, guías y informes
técnicos relacionados con las TIC y, más particularmente, con las técnicas de
seguridad.
ISO/IEC ha reservado la familia de normas ISO 27000 para tratar distintos

aspectos de esta temática, del mismo modo que se ha realizado con la calidad y
la familia ISO 9000, o la gestión medioambiental con la ISO 14000. El trabajo
sobre la familia ISO 27000 es coordinado por un subcomité (el subcomité 27 –
SC27– dentro del JTC1: Joint Technical Committee 1) que se organiza en base
a grupos de trabajo dedicados a distintas temáticas: sistemas de gestión de la
seguridad de la información, criptografía y mecanismos de seguridad, criterios
de evaluación de la seguridad, servicios y controles de seguridad, gestión de
identidades y tecnologías relacionadas con la privacidad, etc.
El conjunto de normas ISO 27000 están creadas por expertos, bajo la coordi-
nación de la organización ISO e IEC. Hay que entender que las normas que
crea ISO se hacen bajo las siguientes características y principios:
• Consenso. Se tiene en cuenta el punto de vista de todas las partes involu-

cradas: proveedores, fabricantes, usuarios, grupos de consumidores, labo-
ratorios de ensayos y científicos, gobiernos, profesionales reconocidos del
sector y organizaciones investigadoras.
• Amplia aplicabilidad. Las soluciones, normas, estándares, o informes téc-

nicos emitidos deben ser de aplicabilidad global, en todo el mundo.
• Voluntariado. La creación de estándares es un esfuerzo autorregulado por

el mercado, por lo que todos los participantes son partes relevantes de este
mercado y actúan de manera voluntaria. Los voluntarios son aceptados en
base a unos criterios que demuestren la pertinencia de su aceptación y la
valía profesional.
Los estándares que se crean siguen un proceso de seis fases, que se inicia cuan-
do el subcomité conjunto JTC/SC27 vota una nueva propuesta. Este proceso
está reflejado en el ciclo de vida siguiente:
Ciclo de vida de un estándar internacional ISO/IEC
Es importante notar que cada cinco años los estándares pasan una fase de re-
visión y, en caso necesario, si se estima que los cambios van a ser muy profun-
dos, el subcomité inicia de nuevo el proceso.
Es interesante destacar que el esfuerzo de organizar las normas relacionadas

con la gestión de la seguridad de la información, bajo un mismo grupo de
normas, tiene como objeto tanto hacer más sencillo el conocimiento de las
mismas, como facilitar su promoción y poner fin al gran y variado número
de normas, guías e informes técnicos que existen sobre la materia. Además,
respecto al material ya existente, se está realizando una considerable labor de
actualización.
(2)
La familia de normas ISO/IEC 27000 es un conjunto en constante evolución y Se recomienda la consulta de la
norma ISO/IEC 27000 que se pue-
crecimiento, pero está organizada con una cierta idea de jerarquía. La norma
de obtener en el sitio web de ISO
inicial que establece los fundamentos es la ISO/IEC 27000, que es de acceso con las normas gratuitas: http://
standards.iso.org/ittf/Publicly Avai-
gratuito2 y, además de definir y unificar cierto vocabulario, presenta de manera lableStandards/
gráfica el conjunto y las relaciones existentes entre las distintas normas y se
representa a continuación:
Conjunto de normas ISO/IEC 27000. Fuente: ISO/IEC 27000:2018
Las normas más interesantes de comentar son las siguientes:
• La norma introductoria:
– ISO/IEC 27000 proporciona una introducción y visión de conjunto
de todo el marco ISO 27000 y facilita un glosario común. Esta norma
es de acceso público y gratuito, y es muy recomendable su consulta
para obtener una visión de conjunto de toda la familia de normas y de
ciertos conceptos y definiciones de términos comunes.
• Las normas que definen requerimientos:

– ISO/IEC 27001. Es la norma que recoge los requerimientos para la im-
plantación de un sistema de gestión de la seguridad de la información
(ha sido trasladada al marco español en el 2007). La implantación de
un SGSI según esta norma puede certificarse.
– ISO/IEC 27006. Es la norma que define los requerimientos específicos

(esta norma complementa a una más general, la ISO/IEC 17021) para
entidades de certificación que quieran acreditarse en el marco de la
ISO/IEC 27000 y deseen certificar SGSI contra la norma ISO/IEC 27001.
• Las normas que facilitan guías de buenas prácticas o de controles:

– ISO/IEC 27002:2005. Se trata del código de buenas prácticas para la
gestión de la seguridad de la información, y recoge un completo y am-
plio catálogo de controles y buenas prácticas en la materia. Es el con-
junto de controles que la Norma ISO/IEC 270001 toma como referen-
cia a la hora de seleccionar controles de seguridad y de hecho los mis-
mos controles aparecen listados en su anexo A.
– ISO/IEC 27005:2008 facilita una guía para la gestión de los riesgos de

seguridad de la información, y proporciona un marco para realizar
un análisis de riesgos. Está inspirada en el ISO/IEC Technical Report

13335-3.
– ISO/IEC 27003 facilita una guía para implementar un SGSI según la

norma ISO/IEC 270001.
– ISO/IEC 27004 provee de una guía y sugiere mecanismos para medir

la eficiencia de un SGSI.
– ISO/IEC 27007 es una guía para la auditoría de SGSI (ampliamente

basada en la ISO 19011).
– ISO/IEC TR 27008 es un informe técnico que da las guías para la audi-

toría de los controles de seguridad.
(3)
• Las normas de carácter sectorial: Los grandes proveedores de ser-
vicios de “Cloud Computing”, co-
– ISO/IEC 27010 ofrece guías para la gestión de la seguridad en las co-
mo Microsoft Azure, Amazon Web
municaciones entre diferentes sectores, con especial hincapié en in- Services o Google Cloud Platform,
suelen ofrecer en sus páginas web
fraestructuras críticas y sistemas industriales. información sobre la certificación
de sus servicios contra la ISO/IEC
27017 y la ISO/IEC 27018.
– ISO/IEC 27011 define las directrices para la gestión de la seguridad y
la información en el sector de las telecomunicaciones. Estará alineada
con una recomendación de la ITU (X.1051).
– ISO/IEC 27035 remplaza un informe técnico ya existente con modifi-

caciones menores y relacionado con la gestión de incidentes de segu-
ridad.
– ISO/IEC 27017 (Code of practice for information security controls based on

ISO/IEC 27002 for cloud services) e ISO/IEC 27018 (Code of practice for
protection of personally identifiable information (PII) in public clouds acting
as PII processors) son normas que recogen un catálogo de controles de
seguridad específicamente pensados para mejorar la seguridad de en-
tornos de servicios ofrecidos desde la “nube” y que complementan a
los recogidos en la norma ISO/IEC 27002 y el anexo A de la ISO/IEC
27001. No son normas certificables de manera independiente. Sin em-
bargo, las entidades de certificación ofrecen la posibilidad de certificar
contra la ISO/IEC 27001, y si se emplean estos catálogos de controles
entonces el certificado que se emite indica la conformidad contra al-
guna de estas dos normas pero siempre está ligado a la conformidad
previa del SGSI contra la ISO/IEC 27001. En cierto sentido, se emplea
como factor diferenciador de cara a los posibles clientes de estos ser-
vicios3.
(4)
El trabajo del subcomité JTC1/SC27 sobre técnicas de seguridad puede seguirse Sitio web de ISO del subcomité
4 JTC1/SC27:
en en el sitio web de ISO . https://www.iso.org/
committee/45306.html
Y listado de todas las normas en las
Todo este marco normativo está en continuo desarrollo y pone a disposición que trabaja:
https://www.iso.org/commit-
de las organizaciones las herramientas para que puedan implementar sus SGSI tee/45306/x/ catalogue/p/1/u/0/
con arreglo a las mejores prácticas reconocidas. Este marco normativo con- w/0/d/0
templa, además, todos los aspectos de los SGSI: implementación, revisión, au-
ditoría y certificación.
2. Certificación de SGSI contra el estándar ISO/IEC

27001
Hasta este momento, hemos estado hablando de los sistemas de gestión de

la seguridad de la información (SGSI) como una herramienta para mejorar el
buen gobierno de las TIC. Esta herramienta influye por tanto en el gobierno
corporativo, mediante la reducción de los riesgos de la información y, por
consiguiente, de los riesgos en el negocio.
También hemos visto que las organizaciones ISO e IEC han establecido un
marco de referencia para la gestión de la seguridad: la familia de normas ISO
27000. Destaca de este marco la Norma ISO/IEC 27001, que da los requeri-
mientos para la implantación de un SGSI. Por tanto, las organizaciones intere-
sadas en mejorar la gestión de la seguridad de la información tienen a su dis-
posición un marco de referencia que, además de recoger las mejores prácticas
de la industria en esta temática, puede ser certificado. Es decir, las organizacio-
nes tienen la oportunidad de certificar su SGSI (una vez implantado) y exponer
públicamente que una tercera parte confiable (la entidad de certificación) ha
auditado su SGSI y determinado que éste es conforme a la norma. Esto supone
el reconocimiento de que la información en la organización está gestionada
según un marco que asegura su seguridad.
En este apartado, repasaremos las ventajas que comporta una certificación y,

posteriormente, describiremos las principales características de la Norma ISO/
IEC 27001. Destacaremos aquellos aspectos de la norma que constituyen un
requerimiento y, por lo tanto, son comprobados durante una auditoría de cer-
tificación.
2.1. Beneficios de la certificación
Los beneficios de los SGSI que se han expuesto anteriormente repercuten di-
rectamente en el funcionamiento interno de las organizaciones. Sin embargo,
existe el problema de transmitir al mercado la mejora que supone esta nueva
forma de gestión de la seguridad. La necesidad de certificar la gestión de la
seguridad surge de la dificultad de transmitir confianza en la forma en que las
organizaciones protegen su información. Transmitir esta confianza a clientes,
proveedores y sociedad en general es especialmente crucial cuando el servicio
o bien que se intercambian las organizaciones no es material, sino que se trata
de simple y pura información.
La única forma de transmitir confianza en la gestión de la seguridad es su-

perando una revisión independiente de las medidas de seguridad de la orga-
nización. Mediante esta revisión independiente, las organizaciones certifican
que su gestión es buena, y que se hace de acuerdo a unas normas de recono-
cida eficacia.
La certificación de un SGSI no es un proceso muy distinto al de otros tipos

de certificaciones y, por lo tanto, goza de unas ventajas que son ampliamente
reconocidas; son las siguientes:
• Factor diferenciador frente a la competencia. La obtención de un certifi-

cado se puede publicitar. De hecho, las entidades de certificación dan toda
una serie de indicaciones del modo en que es posible utilizar el certifica-
do para autopromoción. Gracias a este certificado, la organización puede
aumentar su reputación, credibilidad y confianza entre los clientes y las
organizaciones colaboradoras. El certificado es, por tanto, un elemento di-
ferenciador ante la competencia.
• Reducir el número de auditorías de segundas partes. Con el aumento de

la externalización de actividades que no se consideran primordiales, las
organizaciones proveedoras y clientes se encuentran ante la necesidad de
intercambiar cada vez más información propietaria. Ante este escenario,
tradicionalmente, las organizaciones clientes se habían reservado el dere-
cho de realizar auditorías de segunda parte, para verificar la seguridad de
los procesos aplicados sobre su información en el proveedor. Sin embargo,
el certificado demuestra al resto de organizaciones (especialmente clien-
tes) la capacidad para gestionar correctamente la seguridad de la informa-
ción. Por lo tanto, no es necesario (o al menos está menos justificada) la
realización de auditorías de segundas partes. En cualquier caso, se podrá
asegurar que existe un proceso de auditoría interna y se podrán facilitar
informes al cliente. Por lo tanto, el certificado sirve como demostración
fehaciente del trato que se da a la información facilitada por el cliente o
por las organizaciones colaboradoras.
Es interesante comentar que las auditorías que siguen el estándar SAS70
del AICPA tienen por objeto cubrir este punto. Recordemos del módulo
1 que el SSAE 18 / ISAE 3402 da las directrices sobre la realización y el re-
porte de las auditorías en organizaciones de servicios, para que sus resul-
tados puedan ser comunicados y utilizados por las organizaciones que ex-
ternalizan el servicio. Sin embargo, este estándar está centrado en auditar
procesos, personas, tecnologías y sistemas que pueden tener impacto en el
estado de las cuentas financieras. Su alcance no es, por tanto, tan amplio
como el que da la certificación del SGSI.
• Cumplir con requerimientos del mercado (de clientes o regulatorios). Al

igual que se ha dicho en el punto anterior, algunos mercados se han regla-
mentado hasta el punto de que la existencia de un SGSI certificado es un
valor añadido del que ya dispone la práctica totalidad de los competidores
(similar a la situación a la que se ha llegado con los sistemas de gestión de

la calidad). Frente a este escenario, es cada vez más frecuente que la obten-
ción de certificados sea un requisito previo para que dos organizaciones
establezcan relaciones de negocio (siempre y cuando éstas impliquen in-
tercambiar información). Por lo tanto, la obtención de un certificado fa-
cilita el establecimiento de relaciones comerciales con compañías de gran
tamaño o instituciones gubernamentales y, en general, abre nuevas posi-
bilidades de negocio en entornos en que la certificación se ve como un
requerimiento.
Por otro lado, en ciertas ocasiones, el requisito no es exactamente disponer
de un SGSI certificado, sino cumplir con un determinado marco legal.
En el caso de la protección de la privacidad, el marco legal sería el de la LOPD en España

o la HIPAA (Health Insurance Portability and Accountability Act) en Estados Unidos.
Otro ejemplo de requisito podría ser la correcta gestión de la contabilidad y de los riesgos
operativos o financieros en sociedades cotizadas en bolsa. En este caso, el marco legal
sería la Sarbanes-Oxley Act en Estados Unidos, y los acuerdos de Basilea II en un ámbito
más internacional. De manera más o menos general, estos marcos legales exigen que los
riesgos a los que la información está sometida estén gestionados adecuadamente. En estas
situaciones, la organización puede acreditar, mediante la certificación de su SGSI, que los
riesgos son gestionados y que se cumple con el marco legal.
• Facilita o abarata las primas de riesgo de seguros. Las organizaciones recu-

rren, o incluso se encuentran a veces obligadas, a contratar seguros para
operar en un determinado mercado o con un determinado cliente. Entre
las organizaciones con mayor interés en que se les demuestre fehacien-
temente que los riesgos son gestionados correctamente, encontramos las
compañías aseguradoras. Las primas de estos seguros se pueden ver redu-
cidas en caso de existir un SGSI. En estos casos, la compañía aseguradora
exigirá que el SGSI se encuentre certificado. Por lo tanto, la reducción de
esta prima impacta positivamente en el ROI del SGSI, y esto es debido di-
rectamente a la certificación del SGSI, y no tan directamente a su propia
existencia.
• Aumenta la confianza interna en calidad de la gestión de la seguridad.

Desde el punto de vista interno, la revisión periódica del SGSI por parte de
un tercero independiente, la entidad de certificación, aporta a la dirección
mayor confianza en la correcta ejecución el proceso.
La operación de un SGSI es una tarea compleja que necesita adaptarse a
lo largo del tiempo. La necesidad de adaptación puede estar motivada por
una mala implementación de algún aspecto del SGSI, o bien por una varia-
ción del entorno o de los objetivos del negocio. Estas desviaciones hacen
necesaria la ejecución de auditorías internas de forma periódica. La con-
fianza plena de que el proceso de auditoría interna es correcto y será capaz
de detectar estas desviaciones la proporciona el proceso de certificación.
Como ya se dirá más adelante, el proceso de certificación no se produce
únicamente en el momento en que se evalúa el SGSI, sino que se revisa
con cierta periodicidad, habitualmente de forma anual. La auditoría de
certificación continua permitirá a la dirección de la organización certifi-

cada obtener una comprobación de que el SGSI es capaz de autocorregirse
y autoajustarse a cambios del entorno.
• Aumenta la concienciación en seguridad en todos los niveles de la orga-

nización, desde el nivel de usuario hasta la misma dirección. Finalmente,
otro beneficio pocas veces apreciado en la certificación es su capacidad
de concienciar a la organización. Por un lado, el SGSI da una gran impor-
tancia a la formación y capacitación del personal en materia de seguridad
de la información. Por otro lado, exige a la dirección un elevado grado
de compromiso con la seguridad. Por lo tanto, el esfuerzo de mantener
la certificación implica una constante renovación del compromiso de la
dirección y una formación continua del personal en materia de seguridad.
2.2. Reconocimiento de la certificación
Todos los beneficios de la certificación del SGSI que se han expuesto anterior-
mente están íntimamente ligados al grado de reconocimiento de la entidad
de certificación. Cuando una organización que ha implantado un SGSI decide
dar el paso de certificarlo, deberá plantearse el grado de reconocimiento que
desea que tenga su certificado, es decir, deberá plantearse a qué mercado quie-
re llegar y quién quiere que conozca su certificación. En base a la respuesta a
estas preguntas, se decidirá por una entidad de certificación u otra.
Esta decisión nos lleva a dos preguntas: ¿qué tipo de autoridad tiene
una entidad para poder determinar que el SGSI de una organización es
conforme a una norma? ¿Hasta qué punto el mercado puede confiar en
el trabajo de esta entidad?
De manera general, una entidad de certificación es una institución legal que,

a partir de una auditoría de tercera parte, certifica que el auditado realiza una
actividad con arreglo a un marco de referencia. La capacidad para poder cer-
tificar esto se basa en: el profesionalismo de los auditores, la independencia
entre el auditor y el auditado, el uso de procedimientos estandarizados y au-
ditados por una entidad superior. En el módulo anterior, ya se ha aludido a la
existencia de las entidades de acreditación, que son las encargadas de garanti-
zar la calidad del trabajo de las entidades de certificación.
2.3. Reconocimiento de la entidad de acreditación
Parte del reconocimiento del certificado emitido por una entidad de certifica-
ción vendrá dado por el nivel de reconocimiento de la entidad de acreditación
a la que ésta esté adscrita. La propia Unión Europea reconoce la importante
labor que la acreditación supone para cohesionar los distintos mercados euro-
peos ("Principios de la acreditación en Europa", certif. 9/94):
"La acreditación es fundamental para el correcto funcionamiento de un mercado trans-

parente y orientado a la calidad en Europa (Unión Europea y Espacio Económico Euro-
peo). Es fundamental para la industria, que para ser plenamente competitiva precisa de
un servicio adecuado en este ámbito. Es fundamental para las autoridades públicas, tan-
to nacionales como europeas, a fin de obtener un grado suficiente de confianza en los
certificados expedidos en cualquier lugar de Europa, y así, facilitar la libre circulación de
productos en todo el EEE. Es fundamental para los propios organismos de evaluación de
conformidad (que operen tanto en el sector regulado como en el no regulado), para que
puedan demostrar de modo independiente su competencia técnica y para garantizar una
competencia transparente y orientada a la calidad entre los mismos".
(5)
Las entidades de acreditación5 son las encargadas de controlar, periódicamen- No hay que confundir con las
entidades de acreditación del ám-
te, que las entidades de certificación realizan sus tareas de acuerdo con las bito de las infraestructuras de clave
normas que rijan su actividad. Además, las entidades de acreditación son la pública (PKI: public key infrastructu-
re), con las que no mantienen nin-
autoridad al respecto dentro de un área de aplicación. Por tanto, también exis- guna relación salvo el denominarse
del mismo modo.
te un cierto nivel de reconocimiento para las entidades de acreditación. Habi-
tualmente, son organizaciones nacionales públicas o semipúblicas sin afán de
lucro, y están gestionadas conjuntamente por diferentes organizaciones del
mercado. Por lo tanto, tienen un reconocimiento implícito dentro de su área
de actuación (habitualmente un país).
La acreditación en España
En España, esta labor recae en la ENAC (Entidad Nacional de Acreditación), una institu-
ción autónoma tutelada por el Estado y designada para mantener el sistema de acredita-
ción nacional de acuerdo con las normas internacionales y las directrices de la Unión
Europea. Por lo tanto, su reconocimiento interno en el mercado español está avalado
por el Estado.
Para que los certificados tengan un reconocimiento pleno fuera del ámbito
estatal, las entidades de acreditación firman acuerdos de reconocimiento mu-
tuo, o se agrupan en entidades supranacionales que tienen la misma finalidad.
El proceso de acreditación, muy similar a uno de certificación, tiene las si-

guientes características:
• La organización que solicita la acreditación debe ser una entidad legalmen-

te identificable, con personalidad jurídica. Antes de plantearse solicitar la
acreditación, deberá disponer del personal y la experiencia necesarias pa-
ra la realización de las actividades para las que desea acreditarse. Además,
tendrá que conocer y cumplir los criterios de acreditación.
• La evaluación de la capacidad técnica se lleva a cabo en dos fases:

– Estudio de los documentos que describen el modo en que la entidad

realiza las actividades (sistema de gestión, métodos y procedimientos
de trabajo, competencia del personal, etc.).
– Evaluación in situ de cómo trabaja la entidad.
• Los resultados de la evaluación se recogen en un informe que se envía al

solicitante, el cual debe responder indicando las acciones correctoras que
considere pertinentes.
• Con el informe de evaluación y la respuesta del solicitante, la comisión

de acreditación toma una decisión. En caso de ser positiva, se emite el
certificado de acreditación.
Las acreditaciones concedidas son vigiladas mediante evaluaciones periódicas,

para comprobar que las entidades acreditadas continúan cumpliendo los re-
quisitos de acreditación. Si en algún momento se constata que la entidad in-
cumple algunas de las obligaciones de la acreditación, se puede llegar a sus-
pender temporalmente o retirar la acreditación. Esto se hará hasta que se de-
muestre de nuevo el cumplimiento de los requisitos de acreditación.
2.4. Requerimientos de una entidad de certificación
Las entidades de acreditación vigilan que las entidades de certificación realicen

su trabajo con arreglo a distintos estándares y procedimientos. Esto es lo que
se denomina proceso de acreditación de la entidad de certificación.
En el marco de la seguridad de la información, la norma a la que se ha de

ceñir el trabajo del auditor es, en términos generales, la Norma ISO/IEC 17021
(Conformity assessment – Requirements for bodies providing audit and certification
of management systems). Esta norma está además complementada por la Nor-
ma ISO/IEC 27006 (Requirements for bodies providing audit and certification of
information security management systems), que ofrece ciertos detalles que han
de servir de guía para las entidades de certificación que deseen especializarse
en la certificación de SGSI.
Los requerimientos de la Norma ISO/IEC 17021 se exponen a continuación:
Primeramente, la norma parte de unos principios que son los que definen las
bases que dan validez a las auditorias de tercera parte. Estos principios tienen
que dirigir la actividad de la entidad de certificación, y su incumplimiento
es claramente una amenaza. La entidad de certificación debe obtener la con-
fianza del mercado con la práctica diaria, mediante el cumplimiento de estos
principios. Una prueba de incumplimiento malintencionado de estos princi-
pios puede suponer la pérdida de la acreditación.
Se entiende que estas auditorías están basadas en los siguientes principios:
• Imparcialidad. Debe mantenerse y transmitirse imparcialidad al mercado

para que el juicio que emite la entidad de certificación sea respetado. Sin
embargo, la entidad de certificación compite con otras entidades de certi-
ficación y, por tanto, el auditado es su cliente. Esto es una amenaza que
debe tratarse escrupulosamente.
• Competencia. La calidad del trabajo realizado es directamente proporcio-

nal al nivel de competencia que tenga el personal en la materia. Por lo
tanto, se deberá cuidar la capacitación continua del mismo.
• Responsabilidad. La entidad de certificación es responsable de ejecutar

las auditorías de tercera parte de acuerdo con los principios y normas es-
tablecidas.
• Transparencia. Se tiene que facilitar abierta y verazmente información

sobre el estatus de un certificado o el proceso de certificación, respetando
siempre la confidencialidad de la información concreta.
• Confidencialidad. Este principio limita el anterior a lo mínimo necesario

para informar adecuadamente al mercado sobre el estado de los certifica-
dos emitidos. En ningún caso se facilitarán detalles de implementaciones
en los auditados.
• Resolución� de� quejas. Es de suponer que todo proceso de certificación

acarreará ciertas quejas, conflictos o diferencias de parecer entre el audi-
tado y la entidad de certificación. Por lo tanto, se presupone que la enti-
dad de certificación hará todo lo posible para investigar y resolver estos
conflictos.
2.4.1. Requerimientos generales
Además de los principios que rigen las auditorías que realizan las entidades
de certificación, la Norma ISO/IEC 17021 tiene los siguientes requerimientos
generales:
• Responsabilidad�legal. La entidad de certificación ha de constituirse con

una forma legal que pueda asumir las consecuencias legales de las activi-
dades que realiza.
• Contrato�/�acuerdos�de�certificación. Toda auditoría de certificación tie-

ne que estar encuadrada en un acuerdo legal entre auditado y auditor.
• Control�sobre�las�decisiones�de�certificación. La entidad de certificación

debe mantener, en todo momento, el control sobre las decisiones que afec-
ten a un certificado o proceso de certificación, sin transferir nunca este
control a terceras organizaciones.
• Gestión�de�la�imparcialidad. Tal y como se ha dicho, la imparcialidad es

un principio que guía todas las auditorías de terceras partes y por tanto de
certificación. El estándar da los requerimientos sobre cómo deben gestio-
narse las actividades que garanticen esta imparcialidad.
Los requerimientos que se habrán de cumplir para asegurar la imparciali-
dad son:
– Ninguna unidad de la entidad legal que constituya la entidad de cer-
tificación puede estar directamente involucrada en tareas de consul-
toría.
– La entidad de certificación tiene el deber de vigilar situaciones de ries-

go para su imparcialidad, por ejemplo, controlando las relaciones de
las otras empresas del grupo empresarial.
– La entidad de certificación deberá abstenerse de participar en procesos

de certificación cuando otras entidades vinculadas a ella estén involu-
cradas en la consultoría del sistema de gestión bajo certificación. Se
considera que deben pasar al menos dos años desde el final de las la-
bores de consultoría.
– La entidad de certificación tendrá que analizar los riesgos contra la im-

parcialidad, y documentar qué medidas se toman para mitigarlos. Ade-
más, deberá estar en disposición de demostrar que se han eliminado.
Las relaciones típicas entre distintas entidades que pueden poner en peli-
gro la imparcialidad de la entidad de certificación son: mismos propieta-
rios o directiva, personal compartido, pago de comisiones por señalamien-
to de oportunidad de negocio, recursos financieros o materiales compar-
tidos, etc.
• Responsabilidades�y�financiamiento. Se exige a las entidades de certifi-
cación que hagan provisiones de fondos o contraten seguros de respon-
sabilidad para cubrir, adecuadamente, los riesgos de sus operaciones. Asi-
mismo, se les exige estar en disposición de demostrar que sus finanzas no
suponen un punto de presión que pudiera comprometer su imparcialidad.
• Estructura�organizativa�y�comité�para�la�imparcialidad. La estructura
organizativa de la entidad de certificación también debe cumplir ciertos
requerimientos relacionados con las funciones de la dirección. Tiene es-
pecial relevancia el hecho de que las entidades de certificación están obli-
gadas a disponer de un comité que vele por su imparcialidad. Se trata de
un comité en el que deben estar representadas las partes interesadas en el

proceso de certificación. La norma ISO/IEC 17021 sugiere que este comité
esté constituido por:
– Clientes del organismo de certificación: organizaciones certificadas
por el organismo de certificación, asociaciones empresariales o de otro
tipo que tengan interés en que sus asociados sean certificados.
– Clientes de las organizaciones cuyos sistemas de gestión se han certi-

ficado.
– Administración: ministerios con responsabilidades en la actividad de

que se trate, u organizaciones gubernamentales dedicadas a la promo-
ción del uso de sistemas de gestión.
– Asociaciones de consumidores.
– Entidades de certificación: personal que trabaje para la entidad de cer-

tificación (se incluirá en este grupo a todas las personas que hayan
mantenido o mantengan relación con la entidad de certificación).
El comité tiene la obligación de controlar la imparcialidad, y sus responsa-

bilidades están reflejadas en el estándar. Si la entidad de certificación des-
oyera las recomendaciones del comité, éste debe poder acudir libremente
a otras entidades para reportar la situación, siempre que se respete la con-
fidencialidad de la información manejada (información de las empresas
certificadas o en vías de ello).
• Estructura�y�gestión�de�los�RR.�HH.�involucrados. El estándar también
especifica requerimientos respecto al personal involucrado en las audito-
rías de certificación de sistemas de gestión. En general, se exige que el per-
sonal involucrado se encuentre en todo momento capacitado para realizar
las asignaciones que correspondan. Para ello, se exige que existan unos
procesos documentados y claros sobre la selección de RRHH, la gestión
de su formación, certificaciones profesionales que fueran necesarias, y ve-
rificación del desempeño de las funciones de auditoría. El estándar ISO/
IEC 27006 aporta detalles más concretos de los requerimientos que deben
cumplir los auditores. Estos requerimientos están alineados con los corres-
pondientes de la Norma ISO 19011, la cual se comentó en el módulo an-
terior.
Por otra parte, el estándar es flexible y permite el uso de auditores externos
y también la externalización de parte de la actividad. Esto puede hacerse
siempre que haya una firma previa de acuerdos de confidencialidad y de
adhesión a los mismos procedimientos y principios que rigen para el ente
de certificación. Respecto a la externalización, cabe destacar que, en nin-
gún caso, se puede externalizar la decisión respecto a un certificado. Esta
responsabilidad siempre ha de recaer en la entidad de certificación, que
podrá apoyarse en trabajos realizados por entidades externas. Además, es
interesante notar que el estándar da la posibilidad al auditado de recha-

zar algún miembro del equipo auditor, y la entidad de certificación estará
obliga a gestionar este conflicto.
• Gestión�de�la�información�relativa�a�la�certificación. Con el objeto de

facilitar la transparencia, la norma da ciertos requerimientos sobre qué
información debe ser ofrecida y de qué forma.
– La información que se haga pública debe ser siempre veraz y no ambi-
gua, incluyendo la información referente a publicidad de sus propios
servicios. Estos requerimientos afectan, en bastante medida, a la infor-
mación que las entidades de certificación ofrecen públicamente, sobre
todo a través de sus páginas web.
– Se debe ofrecer información sobre el estado de cada certificado, tanto

al propio auditado como a toda la comunidad. A esta última, debe
ofrecerse un directorio de certificados con el estado de cada uno de
ellos.
– La norma establece distintos requerimientos respecto a qué informa-

ción debe ser confidencial (todo lo relacionado con el detalle del pro-
ceso de certificación). También establece requerimientos alrededor de
los acuerdos de confidencialidad que han de existir entre los auditores
propios, externos y expertos.
2.4.2. Requerimientos específicos sobre el proceso de

certificación
El estándar da los requerimientos que debe cumplir el proceso de auditoría en

todas sus partes, desde aspectos generales hasta la definición de las fases que
se tienen que pasar y las tareas que se incluirán en cada una de estas fases.
Como requerimientos generales, establece:
• Debe existir un procedimiento para seleccionar el equipo auditor y comu-

nicar el perfil e historial profesional del mismo al auditado. De esta forma,
el auditado puede hacer comentarios y rechazar algún miembro si lo con-
sidera apropiado. Esto incluye también la obligación de los auditores de
informar sobre su imparcialidad.
• La auditoría debe ser planificada en tiempo y recursos. Ha de elaborarse

un plan de auditoría y documentarse el tiempo previsto y el finalmente
dedicado a la ejecución. El dimensionamiento de la auditoría tendrá en
cuenta el tamaño y la complejidad del sistema a auditar. La norma ISO/
IEC 27006 da unas tablas para ayudar en el cálculo del esfuerzo de una
auditoría en base a varios parámetros. En este aspecto, la ISO/IEC 17021 es
menos precisa. Además, la ISO/IEC 27006 proporciona más criterios para

cumplir los requerimientos de competencia de los auditores en función de
la complejidad del SGSI a auditar.
Este conjunto estricto de requerimientos que se aplica a las entidades de cer-

tificación es el que garantiza el reconocimiento y buen nombre de una deter-
minada certificación.
2.5. Tipos de auditoría en el proceso de certificación
Cabe notar que la auditoría certificará la situación del SGSI en un momento

dado, por lo que todas las entidades de certificaciones otorgan su sello de cer-
tificación con una validez definida en el tiempo (habitualmente, tres años).
Durante este periodo de validez, la organización certificada deberá pasar au-
ditorías de seguimiento y mantenimiento para demostrar que su SGSI sigue
cumpliendo con la norma de referencia y que se realiza un adecuado mante-
nimiento del mismo. Por lo tanto, la entidad que certifica su SGSI es auditada
una primera vez y luego todos los años en los que el certificado es válido. Por
lo tanto, en el momento de definir los requerimientos sobre el proceso de au-
ditoría de certificación, se tienen en cuenta diferentes subtipos de auditorías
que existen alrededor de este proceso trianual de certificación: auditorías ini-
ciales, auditorías de seguimiento o mantenimiento, las auditorías de recertifi-
cación, y finalmente podría ser que si en algún momento el proceso lo requi-
riese existieran también auditorías especiales.
Las auditorías iniciales de certificación son las que constituyen el cuerpo cen- Ved también
tral del contenido de este módulo. También son el tipo más desarrollado y
En el apartado "Proceso de cer-
formalizado por el estándar ISO/IEC 17021. Son las que pasa la organización tificación de SGSI contra la
por primera vez. ISO 27001", se detallará cómo
debe realizarse este proceso
conforme a la Norma ISO/IEC
27006.
Las auditorías de seguimiento y mantenimiento se realizan anualmente tras la
primera de certificación o tras las de recertificación (se explican más adelan-
te) y se utilizan para comprobar que el auditado continúa cumpliendo con el
marco de referencia. Pasado el tiempo de validez de la certificación, la organi-
zación se someterá a una auditoría de renovación o recertificación. El alcance
de las auditorías de seguimiento es mucho más reducido que el de la de certi-
ficación o renovación, mientras que la de certificación y de renovación tienen
un alcance idéntico o al menos muy similar, aunque de manera general, se
puede ver que en los tres años se revisa a fondo la totalidad de requerimientos
de la norma ISO/IEC 27001 y todos los controles de la norma ISO/IEC 27002
que son aplicables.
Finalmente, las auditorías de re-certificación se usan en los casos en que una

organización hubiese visto revocado o suspendido temporalmente su certifi-
cado, y las auditorías especiales se usan para resolución o investigación de
quejas.
2.6. Estructura del estándar ISO/IEC 27001
(6)
La norma ISO/IEC 27001 fue aprobada en octubre del 2005 y revisada en Desde su última versión de
6 2013, se han realizado pequeñas
2013 . Al tratarse de una norma que tiene un amplio seguimiento, sigue en correcciones (2 desde la fecha de
continua mejora, por lo que son de esperar revisiones futuras. Sin embargo, no última revisión de este material)
que no son significativas.
es la primera en su especialidad. La organización británica de estandarización
BSI (British Standard Institute) creó la Norma BS-7799 ya en 1995, que con-
tenía una primera versión del catálogo de buenas prácticas para la seguridad
de la información. Esta misma organización creó posteriormente, en 1999, la
Norma BS-7799-2, con los requerimientos para un sistema de gestión de la
seguridad de la información que escogiera sus controles de la BS-7799. Ambas
normas fueron la base para la creación de las Normas ISO/IEC 27002:2005 e
ISO/IEC 27001:2005, respectivamente. La Norma ISO/IEC 27002:2005 fue ini-
cialmente la ISO/IEC 17799:2000, que fue revisada en el 2005 y dio lugar a la
ISO/IEC 17799:2005. En el 2007, esta norma sufrió un cambio de denomina-
ción, dando lugar al nombre actual: ISO/IEC 27002:2005. Sin embargo, al tra-
tarse únicamente de un cambio de denominación, no se ha modificado el año
de aprobación (2005). La última gran revisión realizada fue en el año 2013,
cuando se modificó sustancialmente la orientación del modelo de referencia
para la mejora continuada sobre el que implementar los sistemas de gestión
de la seguridad de la información, lo que proporcionó más claridad y también
más flexibilidad.
Actualmente, el ISO/IEC 27001 es el único estándar aceptado internacional-

mente para la gestión de la seguridad de la información, y puede aplicarse en
todo tipo de organizaciones, sea cual sea su tamaño o actividad. Cabe notar,
sin embargo, que a pesar de ser un estándar sobre seguridad de la información
y estar muy ligado a los sistemas de información, no es un estándar sobre as-
pectos tecnológicos sino organizativos, muchos de ellos relacionados con la
gestión de las TIC, aunque no únicamente. También se encuentran tratados
aspectos relativos a la estructura organizativa, la continuidad de negocio y la
conformidad legal. Es por tanto un estándar que aborda la seguridad desde
un punto de vista holístico, combinando todos los aspectos que tienen una
influencia clara sobre ella.
Se tiene que entender que el SGSI planteado por la norma está basado en unos
principios:
• Apoyo de la dirección.
• Adaptabilidad del SGSI a la situación de la organización.
• Aproximación a la gestión basada en procesos de mejora continuada y el

análisis de riesgos y oportunidades.
La versión de 2005 planteaba muy firmemente que el modelo de gestión con-

tinuada de la seguridad de la información tenía que basarse en el conocido
modelo PDCA. Sin embargo, tal y como se ha comentado en apartados ante-
riores, en la revisión de 2013 esta visión tan rigurosa de implementar el mo-
delo PDCA fue eliminada con el fin de facilitar el alineamiento de todas las
normas de estandarización de sistemas de gestión hechas por ISO y descritas
en el anexo SL de la parte 1 de las directivas ISO/IEC. Esta flexibilización ha-
ce que, actualmente, un SGSI pueda inspirarse en otros modelos de mejora
continua también muy populares, como por ejemplo SIX-SIGMA, basado en
el modelo DMAIC (define, measure, analyze, improve, control), que por otro lado
está directamente inspirado en el clásico modelo de Deming PDCA. Así pues,
no existe mucha diferencia entre el planteamiento de la norma de 2005, ba-
sado en el modelo PDCA, y el actual de 2013, que no declara exactamente
qué modelo seguir, pero sí que organiza los requerimientos en un conjunto de
siete puntos de obligado cumplimiento.
La aplicación del modelo PDCA, tal y como se plantea en la versión de 2005, al

entorno de la seguridad de la información se muestra en el siguiente diagrama.
En este diagrama se indican, de manera genérica, las tareas asociadas a cada
una de las fases del ciclo PDCA.
Modelo PDCA para el SGSI según norma ISO/IEC 27001:2005
En comparación, la norma de 2013 eliminó toda referencia explícita a cual-

quier modelo de gestión, pero define siete capítulos principales que todo SGSI
debe cumplir (numerados según la norma):
4. Contexto de la organización.
5. Liderazgo.
6. Planificación.
7. Soporte.
8. Operación.
9. Evaluación del desempeño.
10. Mejora.
Estos puntos pueden asumirse como necesarios en cualquier modelo de mejo-

ra continuada. El siguiente diagrama indica en la fila superior las clásicas fases
del modelo PDCA y se puede observar cómo se ajusta a los distintos reque-
rimientos que deben cumplir los sistemas de gestión normalizados por ISO.
Además, en la práctica ha conllevado una clarificación de conceptos y simpli-
ficación a la hora de implantar estos sistemas de gestión.
Alineamiento entre el modelo PDCA y los requerimientos unificados por ISO para todos los sistemas de gestión
Tanto en la versión de 2005 como en la de 2013, se ve que el punto principal de

partida del modelo es la comprensión de los requerimientos de seguridad que
debe cumplir el SGSI. En la versión de 2005 se habla de expectativas y reque-
rimientos de las partes interesadas (en inglés, stakeholders), mientras que en la
de 2013 se habla de definir el "contexto de la organización". En cualquier caso,
lo que se quiere expresar es que el SGSI debe cumplir con las necesidades de la
organización y el entorno en el que se mueve, y debe producir unos resultados
que cumplan con estos requerimientos. Los resultados, obtenidos mediante
la ejecución del ciclo PDCA o cualquier otro modelo de gestión, y requiere
la implantación, operación y medición de unos controles de seguridad, los
cuales deben gestionar los riesgos identificados por un análisis de riesgos. El

análisis de riesgos constituye una de las piedras angulares del sistema y, por lo
tanto, es una parte obligatoria. Todas las decisiones deben estar basadas en este
análisis. En este aspecto, no ha habido cambio de parecer entre las versiones
de 2005 y 2013, aunque sí se han flexibilizado los requerimientos aplicables
al proceso que determinan las acciones necesarias para identificar, evaluar y
tratar los riesgos y las oportunidades. Asimismo, con el fin de facilitar la tarea
de alinear los distintos tipos de sistemas de gestión estandarizados por ISO/
IEC, para este proceso se han dado unas directrices en una norma separada y
común a todos estos sistemas de gestión, la ISO/IEC 31000, y así se menciona
expresamente en el texto de la norma ISO/IEC 27001:2013.
Por lo tanto, podemos concluir que la gestión de la seguridad, ya sea según

el clásico modelo PDCA o cualquier otro, constituye uno de los requerimien-
tos generales del estándar. La implementación de un proceso que no realiza-
ra alguna de las fases o que, de algún modo, no se pudiera relacionar con el
modelo, constituiría una no conformidad grave que impediría la certificación
del sistema de gestión.
Los requerimientos del estándar ISO/IEC 27001:2013 están organizados en sie-

te partes. El índice de la norma es el siguiente:
0 Introducción
1 Alcance
2 Referencias normativas
3 Plazos y definiciones
4 Contexto de la organización
4.1 Entender la organización y su contexto
4.2 Entender las necesidades y expectativas de las partes interesadas
4.3 Determinar el alcance del sistema de gestión de seguridad de la infor-
mación
4.4 Sistema de gestión de seguridad de la información
5 Liderazgo
5.1 Liderazgo y compromiso
5.2 Política
5.3 Funciones organizativas, responsabilidades y autoridades
6 Planificación
6.1 Acciones para hacer frente a los riesgos y oportunidades
6.2 Objetivos de seguridad de la información y planificación para conseguir-
los
7 Soporte
7.1 Recursos
7.2 Competencia
7.3 Concienciación
7.4 Comunicación
7.5 Información documentada
8 Operación
8.1 Planificación operativa y control

8.2 Evaluación del riesgo de seguridad de la información
8.3 Tratamiento del riesgo de seguridad de la información
9 Evaluación del rendimiento
9.1 Control, medición, análisis y evaluación
9.2 Auditoría interna
9.3 Revisión de la gestión
10 Mejora
10.1 No conformidad y acción correctiva
10.2 Mejora continua
En las siguientes secciones, repasaremos cada una de estas partes del estándar
(del apartado 4 al 10 que son los que contienen de manera efectiva los reque-
rimientos para un SGSI) y destacaremos aquellos requerimientos que se revi-
sarán especialmente en una auditoría de certificación. Hay que señalar que se
emplea la numeración de los apartados del estándar ya que en las auditorías
es habitual referenciar los apartados por su numeración en caso de no confor-
midad o de observación.
2.6.1. Definir el contexto de la organización
Se encuentra tratado en el punto 4 del estándar Contexto de la organización,

que incluye:
• 4.1.�Comprensión�de�la�organización�y�de�su�contexto. La organización Información documentada

debe conocer y también ser capaz de transmitir durante la auditoría (pro-
La norma no especifica qué
bablemente mediante algún tipo de información documentada) aquellas forma ha de tomar una "infor-
circunstancias de su entorno que llevan a la necesidad de controlar la se- mación documentada", pues-
to que en la actualidad puede
guridad de la información y que, al fin y al cabo, imponen al SGSI la im- tomar diversas formas y, por
lo tanto, ya no habla de docu-
plantación de ciertos requerimientos globales. Este concepto de contexto mentos concretos, sino que pi-
de que la información esté do-
deriva de la norma ISO/IEC 31000 de la que se toma como referencia para cumentada con arreglo a los
el tratamiento de los riesgos y oportunidades. El contexto se define como requerimientos que impone en
el punto 7.5.
el conjunto de parámetros o factores externos e internos a la organización
a tener en cuenta en la gestión del riesgo, y establece el alcance y los cri-
terios de riesgo a gestionar. Es habitual que las organizaciones realicen un
ejercicio de análisis denominado DAFO (debilidades, amenazas, fortalezas
y oportunidades) para documentar y mostrar al auditor cómo se ha reali-
zado este análisis del contexto.
• 4.2.�Comprensión�de�las�necesidades�y�expectativas�de�las�partes�in-
teresadas. Dentro del contexto, merece una parte específica el reconocer
que la organización puede tener otras partes interesadas que son tanto ex-
ternas (clientes, reguladores de mercado, otras empresas de su grupo em-
presarial, etc.) como internas (empleados, colaboradores, accionistas, etc.)
que también establecerán requerimientos al SGSI. Igualmente, en la audi-
toría, la organización debe poder mostrar que se ha identificado a todas es-
tas partes y los requerimientos que imponen así como la manera en la que
estos y la organización interaccionan tanto para recoger sus requerimien-

tos como sus comentarios (feedback) sobre la implementación del SGSI.
• 4.3.�Determinación�del�alcance�del�SGSI. Este apartado es el que especí-

ficamente exige a la organización documentar cuál es el alcance del SGSI,
sobre qué parte de la organización (áreas de negocio, procesos, personas,
infraestructuras físicas, infraestructuras de TIC) aplica el SGSI, y también
relacionarlo con los requerimientos de los puntos 4.1 y 4.2. Este es un
punto que el auditor verificará en lo que la norma define como "informa-
ción documentada".
2.6.2. Soporte y liderazgo por parte de la alta dirección
En el marco del SGSI, se exige un alto compromiso por parte de la dirección,

especialmente de la alta gerencia. Este compromiso debe quedar plasmado y
evidenciado por sus actos. Se encuentra tratado de manera general en el punto
5 del estándar Liderazgo, pero determina lo siguiente:
• 5.1.�Liderazgo�y�compromiso. Es crucial que el SGSI cuente con el apoyo

y liderazgo de la máxima autoridad de la organización puesto que, de otro
modo, no se puede garantizar que el SGSI pueda alcanzar sus objetivos,
ya que la alta dirección es tanto quien garantiza los recursos como quien
debe facilitar el alineamiento del SGSI con los objetivos de negocio de la
organización. El auditor comprueba habitualmente este punto mediante
una reunión con la alta dirección en la que se explican los objetivos de
negocio y los del SGSI y el modo en que la alta dirección interviene en la
gobernanza del SGSI.
• 5.2.�Política. Este punto recoge el compromiso de la dirección en forma

de una política de seguridad respaldada por ella (habitualmente un docu-
mento firmado y ampliamente comunicado y a disposición de las partes
interesadas internas y externas) como información documentada que el
auditor verificará.
• 5.3.�Roles,�responsabilidades�y�autoridades�en�la�organización. Dentro
de la faceta de liderazgo, está la cuestión de cómo se organizan las distintas
responsabilidades dentro de la gobernanza de la seguridad. No se requiere
una información documentada, pero el auditor necesitará conocer cómo
se reparten las funciones, y esto suele resultar más fácil cuando se encuen-
tran documentadas.
2.6.3. Planificación
En este punto el SGSI define sus objetivos de acuerdo con lo establecido ante-
riormente y con el análisis de riesgo. La planificación se desarrolla en el punto
6 del estándar, que incluye dos aspectos fundamentales:
• 6.1.�Acciones�para�tratar�los�riesgos�y�las�oportunidades. En este apar-

tado se imponen los requerimientos relativos al modo en que la organiza-
ción analiza el riesgo y lo gestiona. El estándar no impone aspectos muy
concretos sobre cómo realizar el tratamiento de riesgos desde el punto de
vista práctico, pero sí que pide lo siguiente:
a) Tomar en consideración el contexto.
b) Identificar los riesgos y las oportunidades para la consecución de los
objetivos del SGSI que resultan del análisis del contexto y de los requeri-
mientos de las partes.
c) Escribir y reflejar la metodología de todo el proceso, desde la aprecia-
ción, la evaluación y el tratamiento, por medio de alguna información
documentada. No se dan requerimientos concretos. Por tanto, existe fle-
xibilidad en las metodologías, pero sí se entiende que el proceso debe ser
formal, puesto que exige la generación de resultados consistentes, válidos
y comparables.
d) Definir bien en el proceso cuáles son los criterios para la apreciación
del riesgo (identificar los riesgos), para la evaluación (determinar el nivel
de riesgo según probabilidades de ocurrencia e impacto), así como los cri-
terios según los que se tratará el riesgo (no se indica en el estándar, pero
habitualmente son eliminar, reducir o transferir).
e) Cada riesgo debe tener identificado un dueño, que a priori no tiene por
qué ser directamente la alta dirección.
f) A la hora de tratar el riesgo, el estándar exige que exista:
– Declaración de aplicabilidad que debe indicar qué controles son selec-
cionados para tratar el riesgo. Estos controles deben escogerse de entre
los incluidos en el anexo A de la norma ISO/IEC 27001, que es una
traslación literal de todos los controles de la norma ISO/IEC 27002,
pero se da libertad a la organización para incluir otros diseñados por
ella misma. De cada control se debe indicar:
1) Si aplica o no junto con su justificación tanto para la inclusión como
para la exclusión.
2) Si está implementado.
3) Adicionalmente, y no es un requerimiento, se puede añadir cual-
quier otra información que sea útil para el mantenimiento del SGSI.
Por ejemplo, es recomendable dar una referencia a algún documento
de la normativa interna de la organización en la que se trate este con-
trol. Otro aspecto que también se puede detallar en cada control es el
riesgo (una referencia a los riesgos identificados en el análisis de ries-
gos vigente) que se trata con ese control.
Hay que señalar que pueden tomarse adicionalmente controles de
otros catálogos de buenas prácticas, como por ejemplo COBIT u otros.
En caso de tomarse los controles de la ISO/IEC 27017 o ISO/IEC 27018,

algunas entidades de certificación ofrecen la posibilidad de emitir el
certificado contra estas normas, además de por supuesto contra la ISO/
IEC 27001, que es totalmente imprescindible, ya que es el marco ge-
neral de definición de los requerimientos del SGSI.
– Plan de tratamiento del riesgo. Puede tratarse del conjunto de proyec-
tos o actividades que se deriven de las decisiones tomadas para tratar
los riesgos. Debe incluir claramente la referencia a los riesgos del aná-
lisis de riesgos vigente que se trata en cada acción del plan, un propie-
tario o responsable de desarrollar la acción del plan y una fecha obje-
tivo de realización.
g) Todo el resultado del proceso, incluidos los niveles finales de riesgo

residual, debe tener la aprobación por parte del dueño del riesgo.
• 6.2.�Objetivos�de�seguridad�de�la�información�y�planificación�para�su
consecución. Junto con el análisis de riesgos, este aspecto es el otro gran
eje para poder gestionar la seguridad al ser el modo de evaluar si el SGSI
está o no alcanzando sus objetivos.
El estándar pide que:
– Deben ser unos parámetros de seguridad objetivos. No es necesario que
exista una relación directa con los controles aplicados (en anteriores
versiones de la norma se entendía que debía ser así) y se deben adaptar
a la política de seguridad y al contexto del SGSI.
– Deben ser preferiblemente medibles, aunque la norma ya indica que

solo si es posible. En la práctica, es necesario que estos sean medibles
para cumplir el resto de requerimientos del apartado, puesto que deben
ser comunicados.
– Se debe definir una planificación y asignación de recursos para realizar

el seguimiento y la consecución de los objetivos.
2.6.4. Soporte
En este punto se definen los requerimientos sobre los recursos que deben dar
soporte al SGSI en todos sus aspectos. Se tratan en el apartado 7 del estándar
y se apoyan en cinco puntos:
• 7.1.�Recursos. Es necesario que existan recursos (en sentido amplio: dedi-

cación de personas, sistemas de información, instalaciones, etc.) suficien-
tes para conseguir los objetivos del SGSI.
• 7.2.�Competencia. Es necesario que las personas que operan los distintos

aspectos relacionados con la seguridad estén debidamente formadas y de
manera continuada. Debe existir soporte documentado de este plan de

formación.
• 7.3.�Concienciación. Todo el personal bajo el alcance del SGSI debe ser

consciente de la política de seguridad de la información y, en general, tener
concienciación sobre la seguridad en la medida que afecte a su actividad.
Tanto el apartado anterior de concienciación como el de “competencia”
suelen ser tratados por las organizaciones mediante la realización del plan
de formación y concienciación.
• 7.4.�Comunicación. Debe existir un proceso para comunicar todos los as-

pectos relacionados con la seguridad, tanto para realizarlos internamen-
te como externamente. Muy especialmente se debe comunicar la política
de seguridad aprobada por la dirección a las partes interesadas. Es habi-
tual que para las partes interesadas internas (fundamentalmente personal,
accionistas y quizá colaboradores) esta comunicación se realice mediante
formaciones, sesiones de concienciación o simplemente por publicación
en un medio de comunicación interno del documento firmado de la po-
lítica de seguridad. Pero para las partes interesadas es más habitual que se
haga una simple referencia en una página web.
• 7.5.�Información�documentada. Diversos aspectos del SGSI deben que-

dar documentados, por un lado todos aquellos necesarios según la norma
(explícitamente la norma indica que determinados aspectos deben quedar
en una información documentada) y, en general, todos aquellos que se
precisen para la operación del SGSI. La norma define los requerimientos
que aplican, aunque no indica de ningún modo en qué soporte o en qué
forma debe ser. Fundamentalmente, es necesario que la información esté
correctamente identificada, versionada, que siga un proceso de revisión y
aprobación y que esté disponible y protegida de acuerdo con su nivel de
necesidad de confidencialidad.
A continuación se detalla la información documentada que la norma exige
como mínimo:
– alcance,
– política de seguridad de la información,
– proceso de evaluación y tratamiento del riesgo,
– declaración de aplicabilidad,
– plan de tratamiento del riesgo,
– objetivos de seguridad de la información,
– evidencias de la capacitación o competencia,

– cualquier información documentada de origen externo a la organiza-

ción que sea relevante para el SGSI,
– cualquier información documentada referente al SGSI, como por ejem-

plo procedimientos operativos,
– evidencias de la monitorización y medida de los procesos del SGSI,
– programa de auditoría del SGSI e información sobre las no conformi-

dades,
– evidencias de la revisión del SGSI por parte de la dirección.

No es estrictamente necesario, pero sí recomendable, que estén docu-
mentados los siguientes aspectos:
– proceso de comunicación, así como las distintas comunicaciones rea-

lizadas,
– métodos para la monitorización y medida de los procesos del SGSI,
– roles, responsabilidades y autoridades.
2.6.5. Operación
En el punto 8 de la norma, se recoge la necesidad de que la organización opere

los distintos procesos que se derivan de la aplicación del plan de tratamiento
de riesgos y la operación de los controles seleccionados. Es por esto por lo
que si hay una no conformidad en la implantación u operación de un control
que es de aplicación según la declaración de aplicabilidad vigente, el auditor
indicará que la no conformidad es contra el apartado 8.1 de la norma ISO/
IEC 27001. Esto es así porque la norma ISO/IEC 27002 no es certificable, y el
listado de los controles que aparecen en la norma ISO/IEC 27001 son sólo un
anexo, no es parte del cuerpo de requerimientos.
Asimismo, en este punto se determina la necesidad de realizar revisiones de la

evaluación de los riesgos a intervalos planificados o bien cuando se produzcan
cambios importantes. Esto se realiza de acuerdo con cómo se haya fijado en el
proceso de apreciación del riesgo, definido al aplicar el punto 6.1 de la norma.
2.6.6. Evaluación del desempeño
Este apartado 9 de la norma recoge la fase de revisión de un modelo de mejora

continua. Se apoya en tres puntos:
• 9.1.� Seguimiento,� medición� del� análisis� y� evaluación. La eficacia del

SGSI y de la seguridad de la información debe ser evaluada. Debe existir
información documentada del resultado de esta monitorización, por lo

que la organización debe determinar sobre qué es necesario hacer segui-
miento, qué es necesario medir (procesos, controles), cómo se realiza el se-
guimiento y la medición, cada cuánto se realiza y quién es responsable de
realizarlo. Estos resultados son necesarios para la revisión global del SGSI
por parte de la dirección.
• 9.2.�Auditoría�interna. En ella se detallan los requerimientos que deben

cumplir las auditorías internas, que además han de ser coherentes con las
directrices dadas en la norma ISO/IEC 19011. Deberá existir un programa
de auditoría interna para que haya auditorías de primera parte que tengan
en cuenta:
– posibles marcos regulatorios,
– requerimientos de seguridad del SGSI,
– resultados de auditorías previas.
Las responsabilidades asignadas, los requerimientos a aplicar a los audi-

tores para garantizar su debida capacitación e independencia, los requeri-
mientos dados al programa de auditoría y a los resultados de las auditorías
internas deben estar definidos en el programa, y es necesario que exista
evidencia de su ejecución por medio de información documentada.
• 9.3.�Revisión�por�la�dirección. Se detallan los requerimientos de la direc-
ción de cara a revisar el SGSI. Se debe documentar la periodicidad de revi-
sión, la cual se sugiere que no sea superior a un año. Asimismo, es necesa-
rio que los resultados de la revisión realizada por la dirección se guarden
como parte de los registros del SGSI.
La revisión de la dirección debe tener en cuenta:
– Nuevas vulnerabilidades y/o amenazas que no se hubieran tenido en
cuenta en el último análisis de riesgos o en los resultados de las apre-
ciaciones del riesgo realizadas durante la operación del SGSI.
– Los resultados de auditorías del SGSI.
– Cualquier tipo de retorno que se reciba de las partes interesadas. Es por

esta razón que es necesario que la organización tenga bien identifica-
dos los mecanismos por los que establecerá la comunicación bidirec-
cional con las partes interesadas, tanto para informar como para reci-
bir requerimientos y comentarios sobre la operación de la seguridad
por parte de la organización.
– Técnicas, productos o procedimientos que podrían ser usados por la

organización para mejorar la eficiencia y eficacia del SGSI.
– El estatus de las acciones correctivas y preventivas tomadas en el pro-

ceso de revisión y mantenimiento del SGSI.
– Resultados sobre las mediciones de la efectividad de los controles.
– El seguimiento de las anteriores decisiones del proceso de revisión por

parte de la dirección.
Los resultados de la revisión realizada por la dirección deben quedar en

forma de información documentada e incluir las decisiones y acciones em-
prendidas para:
– mejorar la efectividad del SGSI,
– modificar los procedimientos o controles necesarios para responder a

cambios en las circunstancias que rodean al negocio (nuevos requeri-
mientos o contratos, rediseño de procesos de negocios, etc.),
– mejorar la gestión de los recursos asignados a la gestión del SGSI.
2.6.7. Mejora
Se determina en el punto 10, donde se detallan los requerimientos que deben

cumplir las acciones correctivas y el tratamiento de las no conformidades des-
tinadas a mejorar el SGSI de manera continua.
Las acciones correctivas tienen por objeto corregir y evitar la reaparición de no

conformidades en el SGSI. Debe existir un procedimiento documentado para
la detección y realización de las acciones correctivas, el cual debe incluir los
pasos que se han de seguir para:
• Identificar no conformidades y determinar su causa.
• Prever no conformidades potenciales mediante la identificación de cam-

bios o nuevos riesgos en una actualización del análisis de riesgos.
• Determinar e implementar las acciones preventivas (aunque este concepto

ha desaparecido en la versión de 2015 frente a la versión de 2005, es rele-
vante e indirectamente está recogido) que aseguren que no reaparezcan las
no conformidades ya detectadas y que no se materialicen las potenciales.
• Registrar los resultados de las acciones realizadas.
• Revisar las acciones realizadas.

3. Proceso de certificación de SGSI contra la ISO 27001
En los apartados anteriores, se han tratado temas como los sistemas de gestión
de la seguridad de la información, y la certificación de los SGSI contra la Norma
ISO/IEC 27001. Sin embargo, no se ha entrado en detalle en la descripción del
proceso ni en las tareas que un auditor realizará.
En este apartado, profundizaremos en el proceso que se sigue para realizar

una auditoría de certificación de un SGSI según la Norma ISO/IEC 27001. Este
proceso se encuentra regido por la Norma ISO/IEC 27006, la cual ya se ha
explicado en parte. Aquí se tratarán los aspectos más prácticos del proceso de
auditoría.
Es importante que quede claro que el certificador no pretenderá decir si una

organización es más o menos segura. Lo que pretende es verificar que la orga-
nización realiza una gestión de la seguridad de la información y que posee las
herramientas adecuadas para realizar esta gestión de forma correcta. En defi-
nitiva, el certificador verifica el SGSI.
3.1. Objetivos del proceso de auditoría de certificación
Como se ha dicho, el objetivo de estos procesos de certificación es verificar la

correcta implantación de la Norma ISO/IEC 27001, la cual hace referencia a la
gestión de la seguridad de la información.
Los SGSI implantados por cada organización no tienen que ser necesariamen-
te iguales. Las características de cada SGSI dependerán de las particularidades
de cada organización. La ISO/IEC 27001 no obliga a tener una determinada
configuración de los aspectos de seguridad. La norma sólo indica los requeri-
mientos del sistema de gestión y, a partir de estos requerimientos, cada orga-
nización determinará cómo tiene que implantar su sistema de gestión.
3.1.1. Revisión de la implantación del modelo mejora continua
Durante el proceso de certificación, el auditor tratará de verificar que la orga-

nización ha implantado el SGSI siguiendo un modelo de mejora continua, de
acuerdo con los requerimientos del estándar. Es importante destacar que el
proceso de auditoría no examina el nivel de seguridad de una organización,
sino que trata sólo de verificar que su gestión de la seguridad es acorde al es-
tándar.
Por tanto, el auditor no pretende encontrar incumplimientos en medidas con-

cretas de seguridad, sino garantizar y verificar que la organización:
• Tiene un sistema que permite realizar la gestión de la seguridad de la in-

formación.
• Posee las herramientas adecuadas para implementar este sistema de forma
correcta.
• Está capacitada para mejorar este sistema con el paso del tiempo.
Si esto es así, se entiende que la organización conoce sus riesgos y tiene los
medios necesarios para controlar los mismos e ir mejorando los controles que
aplica.
El auditor podría dictaminar si un determinado aspecto de la seguridad

de una organización es correcto o incorrecto. Sin embargo, lo que ve-
rificará realmente es que se han dispuesto las medidas necesarias para
cumplir con el modelo de gestión de mejora continua definido por el
estándar.
Conceptualmente y por simplicidad, tomaremos como referencia el modelo

de gestión clásico PDCA, aunque no sea explícitamente necesario que el SGSI
implementado por una organización esté planteado según esos términos con-
cretos.
El punto de partida de la revisión del auditor será la fase "PLAN". En esta fase
de la implantación del SGSI, se define el alcance del sistema de gestión, se
obtiene el compromiso y liderazgo de la dirección y se realiza el análisis de
riesgos. Toda auditoría deberá comprobar, mediante una reunión con la alta
dirección, su nivel de compromiso y alineamiento del SGSI con los objetivos
de la organización, así como su compromiso y revisión del SGSI. Por otro lado,
toda la revisión que realizará el auditor estará basada en el análisis de riesgos
de la organización. Recordemos que el análisis de riesgos permite identificar
qué controles de seguridad han de implantarse en una organización.
En la revisión del análisis de riesgos, el auditor no comprobará que éste está

realizado correctamente, sino que se ha llevado a cabo con la metodología
correcta. Además, el auditor comprobará que la dirección conoce este análisis,
que ha aprobado su enfoque y que asume los riesgos que se han detectado.
Partiendo de estos riesgos, el auditor tratará de verificar que se han implantado
las medidas de seguridad necesarias para mitigarlos.
El auditor puede dictaminar que el análisis de riesgos es incorrecto, en caso

de que se haya utilizado una metodología incorrecta, el análisis no se corres-
ponda con el alcance del SGSI, o no se fundamente en activos, amenazas y
vulnerabilidades. En circunstancias normales, sin embargo, el auditor asumirá
que los riesgos que la organización ha considerado son los que realmente la
afectan.
La organización tendrá que mostrar y defender, delante del auditor, la

implantación de unas determinadas medidas de seguridad en base a los
riesgos detectados.
Volviendo al modelo PDCA, otro de los aspectos más importantes que el au-
ditor verificará es cómo la organización mejora o actúa (fase "ACT") en base
a los indicadores que haya establecido su sistema de gestión de la seguridad
de la información.
Existen tres maneras de mejorar el SGSI, partiendo de:
1) Apreciación periódica del riesgo.
2) Evidencias de funcionamiento del SGSI.
3) Resultados de la auditoría interna.
Durante el proceso de auditoría, se tratará de verificar que existe un proceso

de revisión por parte de la dirección basado en esos puntos de información,
que son conocidos por la organización y que se utilizan para la realización de
los cambios en la seguridad.
3.1.2. Revisión de los controles ISO/IEC 27002
Cuando el auditor revisa la fase "DO" del modelo PDCA, tratará de determinar
si los controles se han implantado realmente, y si se ha hecho tal y como se
ha documentado.
Conviene recordar que la selección de controles es uno de los elementos más

importantes de lo exigido por el estándar. Estos controles, que son un elemen-
to más dentro del sistema de gestión, están recogidos en la Norma ISO/IEC
27002, aunque pueden utilizarse otros catálogos de controles, como el COBIT.
Si la organización estima útil emplear otros catálogos, el SGSI implantado se-
guiría siendo certificable.
Los catálogos de controles, como por ejemplo ISO/IEC 27002 o COBIT, son
otras normativas existentes en el ámbito de la seguridad de la información,
pero no son auditables en sí mismos. Al tratarse de catálogos de buenas prác-
ticas, contienen toda una serie de controles que pueden o no implantarse en
una organización concreta. Únicamente tras un proceso de análisis del ries-
go, la organización estará en disposición de realizar una selección coherente y
fundamentada de los controles aplicables. Por tanto, no es posible auditar la
implantación de catálogos de controles como la Norma ISO/IEC 27002. Son

un elemento más, aunque fundamental, de los sistemas de gestión de la segu-
ridad.
Por otra parte, existe la posibilidad de realizar un análisis del grado de implan-
tación del catálogo de controles de una norma. Se suele denominar gap analy-
si, y consiste en determinar, para cada uno de los controles, si se encuentra
implantado y en qué medida. Sin embargo, este análisis no permite sacar con-
clusiones sobre la calidad de la gestión de la seguridad, puesto que falta la eva-
luación de los riesgos que estos controles pretenden controlar.
3.2. Proceso de auditoría
Dentro de los distintos tipos de auditorías que distingue el estándar ISO/IEC

27006, el tipo descrito con más detalle es el de la auditoría inicial. De manera
general, el estándar obliga a las entidades de certificación a seguir un proceso
de, al menos, dos fases en la auditoría inicial. Las fases se suelen denominar
"stage 1" y "stage 2", aunque las entidades de certificación pueden denominar-
las de otros modos.
Denominación común de la fases
Una denominación común usada por las entidades de certificación sería "fase documen-
tal" y "fase in situ", ya que estos términos describen el objetivo de cada una de ellas.
Esta separación en dos fases podría no cumplirse si se justifica y se documenta

la razón por la que se opta por otro enfoque. Una razón para no cumplir esta
separación en dos fases podría ser, por ejemplo, que la organización auditada
fuera muy pequeña y se pudiera ejecutar todo el proceso en una única fase.
3.2.1. Diagrama del proceso de auditoría
La norma ISO 19011 define un proceso general para la auditoría de sistemas

de gestión, el cual ha sido adoptado por la Norma ISO/IEC 17021 y la ISO/
IEC 27006 para definir el proceso de auditoría de certificación de un SGSI. En
secciones anteriores, hemos visto de manera general el proceso de auditoría.
A continuación, se detallará este proceso para el caso que nos interesa.
En España, el proceso de auditoría que aplica cada entidad de certificación

puede variar en ciertas fases o en la duración o importancia que se dé a cada
una de ellas. Sin embargo, el proceso completo para realizar una auditoría de
certificación incluye las fases que se muestran en el diagrama siguiente:
Proceso de auditoría de certificación en España
Es interesante ver que, aunque en este diagrama la auditoría documental y la

primera visita documental se encuentran separadas, las entidades de certifica-
ción realizan estas dos actividades de manera simultánea en la mayoría de las
ocasiones. Es decir, en una misma visita preliminar, puede hacerse la toma de
contacto y también la auditoría documental, o se recoge la documentación
para realizar esta última en las instalaciones propias de la entidad de certifi-
cación.
3.2.2. Fase de solicitud de la certificación
Un representante autorizado de la entidad a auditar ha de formalizar una so-

licitud. En ésta, se facilitará alguna información básica para que la entidad de
certificación pueda determinar:
• El alcance de la certificación.
• Características básicas del solicitante (nombre, direcciones).
• Informaciones relevantes respecto a la actividad, recursos humanos y téc-

nicos, funciones y relaciones con otras partes de una organización mayor
(si es aplicable).
La solicitud es estudiada por la entidad de certificación. Se estudia especial-

mente todo aquello que pueda implicar un compromiso a su imparcialidad. Si
la entidad de certificación guarda alguna relación con alguna entidad de con-
sultoría, se determinará si esta última ha tenido alguna relación con la entidad
a auditar. Es importante entender que las entidades de certificación deberían
prestar mucha atención a este aspecto en aras de defender su buen nombre y
el prestigio de la certificación.
Si la asignación de auditoría se puede realizar, es necesario que se establezca

un acuerdo firme entre el solicitante y la entidad de certificación, el cual debe:
• Definir el alcance de la auditoría.

• Comprometer al solicitante a facilitar toda la información que se le requie-
ra en relación con la asignación.
• Comprometer al solicitante a cumplir con todos los requerimientos del
proceso de auditoría.
Una vez formalizado el acuerdo, se hacen los arreglos para iniciar la primera
fase de la auditoría.
3.2.3. Planificación y dimensionamiento de la auditoría
En el proceso de planificación y dimensionamiento de la auditoría, se deter-

minan el número de días que se dedicarán, y el número y tipo de recursos
que compondrán el equipo de auditoría. Esto es determinante tanto para el
éxito de la asignación de auditoría como para el éxito económico de la enti-
dad de certificación. No hay que olvidar que, en la gran mayoría de los países
industrializados de nuestro entorno (Europa, América Latina), existe compe-
tencia entre las diferentes entidades de certificación, aunque sean entidades
sin ánimo de lucro en algunos casos. Todas ellas deben de financiarse, en par-
te, con los recursos que la actividad de auditoría genera. Por lo tanto, ajustar
tanto como sea posible los costes de la auditoría va en relación directa con el
dimensionamiento de la misma.
La norma ISO/IEC 27006, que rige el proceso de auditoría de certificación de

los SGSI, no da requerimientos estrictos a este respecto. Esto es debido a que
se entiende que el correcto dimensionamiento de la auditoría está relaciona-
do con la imparcialidad y el buen nombre de la entidad de certificación. Sin
embargo, esta norma da ciertas guías en uno de sus anexos. En concreto, su
propuesta se basa en determinar inicialmente la complejidad de la organiza-
ción a auditar en base a unos cuantos criterios:
Complejidad Alta Media Baja
Número�de�empleados�y�per- >= 1.000 >= 200 <200

sonal�externo�desarrollando
labores�internas
Número�de�usuarios�clientes >= 1.000.000 >= 200.000 < 200.000
Número�de�localizaciones >= 5 >= 2 1
Número�de�sistemas�de�infor- >= 100 >= 10 <10

mación�(servidores)
Tamaño�del�parque�de�micro- >= 300 >= 50 < 50

informática�(equipos�sobre-
mesa�o�portátiles)
Número�de�personas�dedica- >= 100 >= 20 < 20

das�al�desarrollo�o�integración
de�aplicaciones
Uso�de�la�criptografía Conexiones externas de datos Conexiones externas de datos No tiene conexiones de datos ex-
cifradas, con uso de PKI, o con no cifradas, sin uso de PKI, y sin ternas
requerimientos criptográficos requerimientos criptográficos
Especificidad�del�marco�legal Incumplimientos pueden llevar Incumplimientos pueden pro- Incumplimientos conllevan pérdi-
que�le�aplique a cargos judiciales vocar sanciones, o pérdida de das insignificantes
imagen
Asimismo, la Norma ISO/IEC 27006 define una serie de sectores que se con-
sideran de especial riesgo. Para los casos en los que la organización candida-
ta opera en alguno de estos sectores, la norma proporciona unos criterios de
complejidad distintos para realizar el dimensionamiento de la auditoría.
En base a la complejidad resultante que se asigne a la organización, se deter-

minan tanto los conocimientos y experiencia de los miembros del equipo au-
ditor como el cálculo del número de días a dedicar a la auditoría.
Respecto a la capacitación del equipo auditor, si la complejidad es alta, se acon-

seja que el equipo auditor disponga de un conocimiento avanzado del sector
en que se mueve el auditado. En cambio, si la complejidad es media o baja,
bastaría con un nivel de conocimiento adecuado.
Respecto a la planificación, la norma da un método de cálculo que está extraí-

do de la experiencia propia de diversas entidades de certificación. Este método
está basado en tablas que relacionan el número de días necesarios para auditar
el SGSI con el número de empleados de la organización. Además, se reservan
ciertos días para tareas de revisión y elaboración de informes de la siguiente
manera:
• 2 días para revisar los controles ISO/IEC 27002.

• De 1 a 3 días para revisar la documentación.
• De 1 a 3 días para elaborar los informes.
• Un tiempo adicional por cada localización extra que se tenga que visitar.
De todos modos, ésta no es más que una recomendación o guía, que puede o
no ser tenida en cuenta por la entidad de certificación según sus necesidades.
Selección del equipo auditor
La selección del equipo auditor puede realizarse con anterioridad a la fase de

auditoría documental. Sin embargo, conceptualmente, y según el estándar ISO
19011, debería de realizarse después.
Respecto al tamaño del equipo auditor, éste dependerá en gran medida del
alcance de la auditoría. Habitualmente, en el caso de empresas de pequeño o
mediano tamaño, no suele ser habitual que el equipo auditor sea de más de
una persona (el auditor jefe) o dos. En el caso de grandes empresas, sí que es
posible que se creen equipos de auditoría más numerosos.
Cuando se crea un equipo de auditoría, el líder del equipo auditor debería asig-
nar a cada miembro del equipo la responsabilidad de auditar partes específi-
cas del sistema de gestión (procesos, funciones, áreas o actividades concretas).
Estas asignaciones deberían tener en cuenta la necesidad de independencia,
competencia y uso efectivo de recursos por parte de los auditores y expertos
técnicos. Se pueden hacer cambios en las asignaciones de trabajo a medida
que progresa la auditoría, para asegurar el logro de los objetivos de ésta.
Los requerimientos de conocimientos más específicos son los relacionados con

los capítulos de la Norma ISO/IEC 27002. Se pide un cierto nivel de conoci-
miento sobre las áreas tratadas en cada uno de los capítulos de la norma. A
continuación indicamos, para cada uno de los capítulos, el grado de conoci-
miento o experiencia que se suele exigir a los auditores:
• Políticas de seguridad. Conocimiento y experiencia en políticas, y en la

influencia de los requerimientos de negocio en la seguridad de la infor-
mación.
• Organización de la seguridad. Conocimiento general y experiencia en pro-

cesos de negocio y en estructuras organizativas.
• Gestión de activos. Conocimientos en valoración de activos, inventariado,

clasificación y políticas de uso aceptable de los activos.
• Gestión de recursos humanos. Conocimientos generales sobre los procesos

de un departamento de gestión de recursos humanos.
• Protección física y del entorno. Conocimiento de los riesgos y controles

habituales.
• Capítulos de orden técnico. Conocimiento actualizado y experiencia en

estándares, técnicas y procesos para la gestión de los aspectos técnicos, así
como un cierto nivel de conocimiento y experiencia técnica.
• Gestión de incidentes. Conocimiento actualizado y experiencia en los pro-

cesos para la gestión de incidentes de seguridad.
Por ejemplo, los aplicados por los equipos de respuesta ante incidentes tal y como los
describe el CERT-CC del SEI (Software Engineering Institute) de la Universidad Carnegie
Mellon.
• Continuidad de negocio. Conocimiento actualizado y experiencia en los

estándares (como el BS 25999), procesos, planes y pruebas de los mismos.
• Cumplimiento legal: conocimiento actualizado y experiencia de los tipos

de relaciones contractuales, y marcos legales más habituales (propiedad
intelectual, protección y retención de datos financieros, y protección de
datos de carácter personal) y si es aplicable más específicos: leyes antite-
rroristas, regulación del uso de controles criptográficos, comercio electró-
nico, investigación y vigilancia electrónica, intercepción de telecomuni-
caciones y monitorización del tráfico, etc.
Además de estos conocimientos, que pueden ser cubiertos mediante expertos

externos, los auditores sí deberán tener un conocimiento actualizado y expe-
riencia en:
• La norma ISO/IEC 27001 (muy especialmente).

• Planificación de auditorías.
• Tipos de auditorías y metodologías.
• Análisis de riesgos y metodologías.
• Ciclo de Deming para implementar un proceso de mejora continua.
Una vez designados los componentes del equipo auditor, sus miembros debe-
rían revisar la información pertinente relacionada con sus asignaciones de au-
ditoría, y preparar los documentos necesarios para dichas asignaciones.
La planificación de la auditoria
El líder del equipo auditor tendría que preparar un plan de auditoría para su-
ministrar la información necesaria al equipo auditor y al auditado. El plan de-
bería facilitar la programación y la coordinación de las actividades de audito-
ría. La cantidad de detalles suministrados en el plan de auditoría reflejan el
alcance y complejidad de la misma. El plan de auditoría debería ser suficien-
temente flexible para permitir cambios (por ejemplo, en el alcance de la au-
ditoría), los cuales pueden llegar a ser necesarios a medida que progresan las
actividades. Sin embargo, los cambios en el plan de auditoría suelen ser poco
frecuentes. Únicamente, se dan en el caso en que se detecten no conformida-
des mayores que lleven al auditor y auditado a replantear el alcance de la au-
ditoría y su planificación.
El plan de auditoría debería incluir o describir:
• El alcance y objetivo de la auditoría. El alcance debe plantear también las

unidades organizativas, funcionales y/o procesos auditados.
• Las fechas y lugares donde se van a realizar las actividades de auditoría
in situ.
• El tiempo y duración esperados de estas actividades, incluidas reuniones
con la gerencia del auditado y reuniones internas del equipo auditor.
• Los criterios de la auditoría y cualquier documento de referencia. En nues-
tro caso, se trata obviamente de la Norma ISO/IEC 27001.
• Equipo por parte de la entidad y del solicitante.
• Personal del solicitante con responsabilidad dentro del área afectada.
• Muestras de controles a auditar.
• Contenido y estructura de los informes.
• Aspectos relacionados con la confidencialidad que sean relevantes.
El plan de auditoría será presentado al solicitante con anterioridad al desarrollo

de la auditoría in situ. El auditado debería revisar y aceptar el plan de auditoría
al menos antes de comenzar las actividades de auditoría in situ.
Cualquier objeción presentada por el auditor debería resolverse entre el líder

del equipo auditor, el auditado y el cliente de la auditoría. El plan de auditoría
debe ser aceptado por todas las partes antes de continuar con la auditoría.
Consideraciones sobre el muestreo
El proceso de auditoría de los requerimientos de la norma ISO/IEC 27001 cubre

la totalidad de los requerimientos de la norma tanto en la auditoría inicial de
certificación como en las de renovación y seguimiento. Sin embargo, en lo
que respecta a la revisión de la implantación de los controles tomados de la

ISO/IEC 27002 puede no ser exhaustivo en cada una de las auditorías que se
realizan en el ciclo de certificación. Pero al finalizar el ciclo, todos los controles
son revisados. Esto significa que para una de las auditorías del ciclo, el auditor
selecciona unos cuantos controles a revisar, pero al cabo del ciclo se ha pasado
por todos. El equipo auditor, antes de iniciar la auditoría presencial, realiza
una selección de los controles que van a ser auditados y estos se indican en el
plan de auditoría. En este sentido, también se debe considerar que a la hora
de auditar un control, el auditor no auditará la totalidad de las actividades
de la organización y que también realizará un muestreo en ese sentido. Para
preparar la muestra de controles a verificar deberá considerar:
• Incluir todos los controles críticos.

• Seleccionar controles que afecten a las actividades más importantes de la
organización.
• Seleccionar controles de todas las secciones.
• Seleccionar los controles de forma que se auditen todos los departamentos
involucrados en el SGSI.
• Dar prioridad a las áreas de mayor riesgo.
• Si no se encuentran problemas serios, se auditará un 20% de los controles
aplicables.
El muestreo será también necesario cuando existan un gran número de loca-

lizaciones bajo el alcance del SGSI. En este caso, la entidad de certificación
deberá asegurarse de que el alcance de la auditoría se ajusta lo más posible al
alcance del SGSI. Para ello:
• Todas las localizaciones han de regirse por el mismo SGSI, el cual debe estar
gestionado de manera centralizada. Este punto central debe estar dentro
del alcance de la auditoría.
• Las razones para tener que optar por un muestreo deben estar justificadas
y documentadas.
• El muestreo debe hacerse teniendo en cuenta:

– Los resultados de las auditorías internas del SGSI.
– Las revisiones de la dirección.
– La variabilidad de tamaños, complejidad de los sistemas de informa-
ción y funciones de negocio de las distintas localizaciones.
– Aspectos legales que pudieran ser relevantes.
• Si una localización tiene unos riesgos específicos que sean relevantes, debe
estar incluida en el muestreo.
• La entidad de certificación ha de extender su alcance en las futuras audi-

torías de seguimiento, para ir englobando al resto de localizaciones.
Consideraciones sobre el análisis de hallazgos
De manera general, tanto para esta fase 1 documental como para la fase 2
presencial, al finalizar las pruebas, el auditor realiza un análisis de todos los
hallazgos que haya realizado y los clasifica en cuatro categorías:
• No conformidad mayor.
Se trata de un incumplimiento de alguno de los requerimientos de la nor-
ma ISO/IEC 27001 que muestra que el SGSI no es capaz de conseguir sus
objetivos. En este sentido, cuando el auditor lo documenta deja bien re-
flejado qué apartado concreto de la norma es el que no se está respetando
indicando el numeral y, si fuera un subapartado, indica en ese caso el texto
literal de lo que no se está cumpliendo.
• No conformidad menor.
Al igual que en el caso de no conformidad mayor, se trata de un incum-
plimiento de un requerimiento de la norma, pero en este caso no pone en
riesgo la consecución de los objetivos del SGSI. El error es relativamente
sencillo de subsanar y por esta razón no pone en jaque la consecución o
renovación del certificado.
Hay que destacar que, aunque los controles aparecen en el anexo A de la
norma ISO/IEC 27001, no son parte de los requerimientos del SGSI. Sin
embargo, en el apartado 8.1 es en el que se refleja la necesidad de que
la organización realice correctamente la implantación y operación de los
controles. Por esta razón, un error en un control es una no conformidad
contra el numeral 8.1 de la norma y no del control concreto. Con el fin de
facilitar al auditado la resolución, el auditor sí que documenta el control
del anexo A al que se refiere la no conformidad.
Como hemos comentado, un incumplimiento contra el 8.1 en la implan-
tación de controles suele ser una no conformidad menor siempre y cuando
no sea generalizado. Es decir, dependerá en cierta medida del número de
controles que el auditor haya detectado. Si este número es muy elevado, el
auditor podría considerar que la no conformidad contra el requerimiento
8.1 sería de tipo mayor y no menor. No hay un baremo de cuántos con-
troles fallados hacen cambiar esta apreciación.
• Observación.
En este caso, el auditor no observa un incumplimiento completo, sino
una desviación que podría conllevar un incumplimiento más adelante,
si no se corrige. Es por esta razón que las observaciones se documentan
referenciando el apartado de la norma a la que se refieren. Y también por
esta misma razón, las organizaciones deberían gestionar las observaciones
casi del mismo modo que las no conformidades menores, ya que en caso de
no resolverse, en la siguiente auditoría del ciclo de certificación, el auditor

revisará si se han gestionado y en caso negativo podría decidir convertirlas
en no conformidades menores.
• Puntos fuertes y oportunidades de mejora.

Finalmente, el auditor puede detectar aspectos sobre los que desee expresar
su opinión o valoración.
3.2.4. Stage 1. Auditoría documental
La primera fase de la auditoría –stage 1– tiene por objetivo la revisión de toda

la documentación que forma parte del SGSI. Esta revisión documental sirve
para verificar que se ha creado un SGSI, que se opera de acuerdo a la norma, y
que se han implantado los controles en base a los riesgos que la organización
ha detectado. Además, debe revisarse que estos controles estén de acuerdo con
lo que se indica en la norma ISO/IEC 27001.
Por otra parte, la auditoría documental tiene un objetivo secundario: obtener

un mejor entendimiento de la idiosincrasia del auditado, su negocio, el alcan-
ce del SGSI y las características del mismo. Este conocimiento tiene que ser
empleado en la fase siguiente, para agilizar y hacer más eficaces las pruebas de
auditoría y determinar la composición exacta del equipo auditor.
Al inicio de esta fase, se solicita al auditado que facilite la documentación.

Auditado y auditor acuerdan si la revisión de la documentación se hará en
una visita presencial o en las instalaciones de la entidad de certificación. Lo
habitual es que se realice la visita presencial, para así realizar también una
toma de contacto entre ambos equipos. Por supuesto, las consideraciones de
confidencialidad que el auditado tenga sobre esta documentación deben ser
tenidas en cuenta. Por lo tanto, podría darse el caso de que no sea posible que
la documentación salga de las instalaciones del auditado.
Los resultados de esta revisión son siempre documentados y comunicados al

auditado con anterioridad a proceder a la siguiente fase.
Documentación a revisar
La mínima documentación que se va a revisar en esta fase es la recogida en

el punto sobre el apartado Soporte de este material, al comentar el punto 7.5,
"Información documentada", y básicamente se trata de los siguientes:
• Política�de�seguridad�de�la�organización. La política podrá estar en un

documento independiente o no; tal cosa no es determinante. La política
debe ser una guía estratégica que proporcione indicaciones de orden ge-
neral a toda la organización de manera sencilla. Puede llegar a ser expre-
sada en una única hoja, y ésta ser expuesta de manera pública en las ins-
talaciones, puesto la política de seguridad debe estar distribuida a todos
los trabajadores.
El auditor verificará que la política hace mención a la existencia de otra
documentación relativa al SGSI, y que ésta se distribuye en base a la nece-
sidad de conocimiento de los trabajadores.
En pocas palabras, se revisarán los siguientes aspectos:
– Definición de la seguridad.
– Soporte de la dirección a la implantación del SGSI.
– Explicaciones breves sobre políticas, principios, prácticas y cumpli-
mientos de seguridad.
– Definición de responsabilidades.
– Referencias a otros documentos.
• Alcance�de�la�certificación. Este alcance condiciona la certificación y el

desarrollo de las auditorías. El auditor únicamente revisará lo referente a
este alcance, y todo lo que pueda estar fuera no será revisado.
Tal y como se ha apuntado, es posible que un SGSI no incluya la totalidad
de la organización, sino que podría definirse un alcance de un determina-
do proceso o un área concreta de la organización. En el caso de que se
realice un cambio en el alcance del SGSI, deberá rehacerse totalmente el
proceso de certificación. El alcance viene habitualmente descrito en una
“información documentada” que es el que revisará el auditor y que con-
trastará con la explicación y evidencias que obtenga del análisis del con-
texto y de las partes interesadas. Las tres cosas han de ser coherentes.
• Análisis�de�riesgos�de�la�organización. El auditor prestará especial aten-

ción al análisis de riesgos. Para empezar, tendrá que estar formalmente
aceptado por la dirección de la organización, y es obligatorio que esté do-
cumentado. La documentación deberá incluir tanto la metodología utili-
zada, que debe ser coherente con la complejidad de la organización, con
el alcance del contexto y de las partes interesadas, como los resultados de
dicho análisis de riesgos y el plan de tratamiento de los mismos.
El auditor ha de determinar si el análisis de riesgos cubre todo el alcance
definido por la organización, y si es aceptable en función de los activos y
la naturaleza de ésta. También tiene que revisar que el análisis de riesgos
y la gestión del mismo esté actualizada.
En este sentido, es interesante destacar que el comité conjunto JTC1 de
la ISO e IEC ha realizado informes técnicos detallando los principios para
el análisis y posterior gestión del riesgo. Estos informes técnicos han que-
dado recogidos en las Guidelines for the management of IT Security (GMITS
ISO/IEC TR 13335:1998). Esas guías han sido la base fundamental para la
realización de la Norma ISO/IEC 27005:2008. Asimismo, también tiene el
auditor a su disposición todas las normas de la familia ISO/IEC 31000 co-
mo guía sobre análisis de riesgos. El auditor empleará estas normas como
referencia para determinar la calidad del análisis de riesgos.
• La�selección�de�controles�de�acuerdo�con�la�declaración�de�aplicabi-
lidad. El auditor, en base a los riesgos analizados, determinará si se han
seleccionado los controles adecuados para mitigarlos. Asimismo, tendrá
que verificar que todos estos controles de seguridad quedan reflejados en
la declaración de la aplicabilidad, y que la dirección aprueba el riesgo re-
sidual resultante de implantar estos controles.
Es importante notar que, en la documentación, se deben justificar todos
los controles, tanto si son seleccionados como si son descartados, así como
el nivel de implantación de los mismos. En este sentido, se tendrá que
defender, ante el auditor muy especialmente, la no implementación de un
control, y los motivos pueden ser:
– No existe un riesgo que lo justifique.
– Presupuesto.
– No hay viabilidad tecnológica.
– No se puede implantar por falta de tiempo.
– No es aplicable.
Las razones para excluir controles deben ser sólidas y coherentes.
Tal y como se ha explicado en apartados anteriores, el documento de declara-

ción de aplicabilidad puede contener otros campos que son interesantes para
la organización a la hora de gestionar su SGSI. Aunque no son estrictamente
requeridos por la norma, sí que aportan solidez al modelo de operación del
SGSI y muestran al auditor un elevado nivel de madurez del sistema, por lo
que es recomendable que la organización tome este documento como un ele-
mento clave de su modelo de gestión del SGSI.
Ejemplo de extracto de una declaración de aplicabilidad
Control Implantación Sí/no Justificación
6.3.1. Comunicación de las incidencias de se- SÍ SÍ Es imprescindible para detectar las incidencias
guridad en un estado temprano, y es una de las bases
para el proceso de mejora continua
7.1.5. Áreas aisladas de carga y descarga No aplica NO No es aplicable, ya que la organización no dis-
pone de áreas de carga y descarga.
8.7.2. Seguridad de soportes en tránsito No aplica NO No es aplicable, ya que la organización no en-

vía soportes físicos con información sensible o
confidencial.
El documento de declaración de aplicabilidad relaciona el análisis de riesgos

con la situación de la seguridad, tanto para los auditores externos como in-
ternos.
Junto con el alcance y la política, constituye la base de la auditoría documen-

tal. El auditor comprobará la consistencia de los planteamientos referentes a la
seguridad entre los tres documentos. En especial, el auditor buscará evidencias
que demuestren que existe una relación entre la selección de los controles y
los riesgos detectados en el análisis. Por último, revisará el modo en que los
controles ayudan a gestionar el riesgo.
1)�Documentación�de�gestión�del�SGSI. La documentación del SGSI deberá

incluir una descripción sobre el modo en que se opera el sistema. Esta docu-
mentación es la que describirá cómo se ejecuta el proceso de mejora continua
PDCA. Habitualmente, estará organizada del siguiente modo:
• Estructura organizativa para soportar la función de seguridad.

• Procedimientos para medir la eficacia del SGSI y de los controles de segu-
ridad.
• Normativa para la gestión documental de toda la documentación.
Respecto a la documentación que da forma y soporte al SGSI, el auditor
tiene que comprobar que la documentación:
– Está fechada y disponible.
– Dispone de control de versiones.
– Se retira si es obsoleta.
En este aspecto, es importante que la documentación sea coherente y que esté

formalmente aprobada por quienes hayan sido designados. Además, deben
existir registros de funcionamiento de todos los aspectos del SGSI. Hay que
entender que, en gran medida, el SGSI está basado en decisiones y, por lo tanto,
parte de estos registros serán actas de reuniones, órdenes dadas por escrito,
etc. En cierto modo, el auditado estará en disposición de presentar un registro
o prueba del funcionamiento del SGSI, aunque este es uno de los objetivos de
la fase siguiente de la auditoría.
2)� Documentación� de� los� controles� seleccionados. Los controles deberán

estar descritos y esto, además, debe ser la base para su implantación posterior.
Informe de la auditoría documental
En base a la revisión de la documentación, el auditor ha de establecer un in-

forme de auditoría. La realización de este informe es una obligación de la parte
auditora.
Del análisis de las evidencias de auditoría de la fase 1, puede llegarse a tres

situaciones:
• El�auditor�detecta�no�conformidades�mayores. En este caso, el auditor

rechaza la certificación, y propone a la empresa auditada que rehaga la do-
cumentación del SGSI y que, pasado un tiempo, vuelva a requerir el pro-
ceso de auditoría. La realidad no es tan drástica, y se pospone la realización
de nuevo de la fase 1 a una fecha en la que el auditado haya subsanado
las no conformidades.
Hay que destacar, y esto es válido también para la fase 2, que el auditor
desarrollará su labor de auditoría mientras no encuentre no conformidades
mayores. En caso de hallar alguna, y dependiendo de su naturaleza, podrá
continuar su labor, pero acabará deteniendo el plan de auditoría si surgen
más no conformidades mayores. Es decir, en una auditoría de certificación,
el auditado no puede esperar que se detecten todas las no conformidades
(mayores y menores), con el objeto de disponer de un listado de acciones
a realizar.
• El�auditor�detecta�no�conformidades�menores. En estos casos, el auditor

propone a la organización auditada que exponga una serie de acciones co-
rrectoras. El auditado tendrá que proponer no sólo la solución, sino tam-
bién un tiempo en el que se resolverá dicha no conformidad. Será el audi-
tor el que se encargue de decidir si tales soluciones previstas solucionarían
estas no conformidades.
En caso de que el auditor decline estas soluciones, se indicará que tendrá
que volver a solicitar la auditoría. En caso de que las soluciones que plantea
la organización sean aceptadas por el auditor, procederá a requerir el paso
a la segunda fase de la auditoría.
• El�auditor�no�detecta�no�conformidades. En estos casos, el auditor pro-

pone a la organización que pase a la segunda fase de la auditoría.
El informe de auditoría de esta primera fase se enviará a la organización
para que actúe en consecuencia. Una vez llegados a la situación en que se
puede progresar a la fase 2, auditor y auditado acuerdan la realización de
la siguiente fase.
Habría una cuarta posibilidad que sería que el auditor detectara hallazgos que
no llegara a catalogar como no conformidades, serían simples observaciones.
Estas se detallan en el informe de fase 1 pero no afectan al desarrollo del pro-
ceso de auditoría y no condicionan el paso a la fase 2 de la auditoría. Sin em-
bargo, aparece en el informe y la organización deberá tenerlas en considera-
ción en su proceso de tratamiento de los resultados de la auditoría.
3.2.5. Stage 2. Auditoría presencial o ''in situ''
La segunda fase de la auditoría es presencial, y se realiza en las instalaciones

de la organización auditada. En esta fase, el auditor realizará entrevistas para
verificar que lo que se indica en la documentación revisada realmente refleja
la situación real de la organización.
Entre la revisión documental y esta segunda fase in situ deben pasar entre tres
y seis semanas obligatoriamente. Deberá además existir un plan de auditoría
comunicado al auditado, el cual servirá para acordar aspectos logísticos como,
por ejemplo, fechas exactas, sitios a visitar, pausas, reuniones, etc.
El objetivo de la auditoría presencial es:
• Confirmar que la organización cumple con sus políticas y procedimientos.

• Comprobar que el SGSI desarrollado es conforme con las especificaciones
de la Norma ISO/IEC 27001.
• Verificar que el SGSI está logrando los objetivos que la organización se ha
marcado.
Para conseguir estos objetivos, el equipo auditor deberá centrar su atención

en cómo la organización auditada:
• Apoya la política de seguridad desde la dirección.
• Analiza los riesgos a los que está sometida su información.
• Selecciona los controles basándose en el análisis de riesgos.
• Relaciona el análisis de riesgos, la declaración de aplicabilidad, el plan de

tratamiento de los riesgos y la política de seguridad.
• Implementa los controles teniendo en cuenta los mecanismos de medida

de la efectividad de los mismos, y la consecución de los objetivos de con-
trol.
• Revisa la efectividad de su SGSI y de los controles.
• Realiza las auditorías internas y la revisión interna por parte de la direc-

ción.
Relaciones de la auditoría
Una vez el solicitante aprueba el plan de auditoría, se concretan las fechas

exactas para la visita del equipo auditor a las instalaciones de la organización.
En estas revisiones, el equipo auditor deberá centrarse en los siguientes aspec-
tos:
• El análisis de riesgos.
• La declaración de aplicabilidad.
• Los objetivos que persigue la organización.
• Cómo se monitoriza, mide, informa y mejora.
• Las revisiones del SGSI y de la seguridad.

• El grado de implicación de la dirección.
• La coherencia entre políticas, análisis de riesgos, objetivos, responsabili-

dades, normas, procedimientos, datos de rendimiento y revisiones de se-
guridad.
Durante esta segunda fase de la auditoría, deberá realizarse una visita a las ins-
talaciones de la organización (por lo menos, a aquellas instalaciones dentro
del alcance a certificar). Deberá comprobarse también que los controles que se
han seleccionado en la muestra cumplen con lo exigido en el estándar. Esto
significa que se buscarán evidencias objetivas sobre la implantación y el fun-
cionamiento de los controles que conforman el SGSI. Estas evidencias pueden
ser, por ejemplo, registros de actividad (logs). En cualquier caso, las evidencias
han de basarse en medidas, en pruebas o en la observación, y han de poder
ser verificadas. Es importante notar que el auditor puede solicitar al personal
de la organización que le muestre cómo se han generado las evidencias.
Durante la realización de esta segunda fase de la auditoría, algunas pruebas

tendrán un carácter más técnico, lo cual requerirá consultar los sistemas de
información. Sin embargo, los miembros del equipo auditor no podrán tocar
ninguna máquina. Sólo podrán solicitar a los empleados de la organización
que realicen las actividades que quieren evaluar, para buscar evidencias que
permitan decidir si un control está correctamente implantado o no.
Para la ejecución de las pruebas de auditoría, el equipo auditor convocará

reuniones con miembros seleccionados de la organización. En estas reuniones,
el equipo auditor obtendrá la información necesaria para verificar la correcta
o incorrecta implantación de los controles de seguridad. Asimismo, el equipo
auditor también elaborará informes sobre lo observado durante las entrevis-
tas, y redactará documentos de recomendaciones (si procede). Al finalizar, el
equipo auditor convocará una reunión final con la dirección de la organiza-
ción, para explicar lo observado durante esta segunda fase, y comunicar los
resultados de la auditoría.
Entrevistas
Una de las técnicas de auditoría que más emplearán los auditores será la rea-
lización de entrevistas. Éstas podrán estar o no complementadas con alguna
prueba técnica pero, tal y como hemos dicho, será ejecutada por el entrevis-
tado.
La calidad de la entrevista de auditoría dependerá de la habilidad del auditor

para realizar preguntas. A la hora de realizar preguntas, el auditor debe conse-
guir que el auditado se sienta cómodo, que no se sienta interrogado. El tipo de
preguntas que realizará el auditor deben ser abiertas, de forma que el auditado
no pueda contestar sí o no, sino que tenga que proporcionar explicaciones
amplias.
Modelos de preguntas
• ¿Quién lo hace? • ¿Cada cuánto se hace?
• ¿Cuándo se hace? • ¿Me lo podrías mostrar?
• ¿Dónde se hace? • ¿Cómo se hace?
Otros tipos de preguntas que se pueden hacer son:
• Preguntas de opinión.
• Preguntas de investigación.
• Preguntas no verbales (lenguaje corporal).
• Preguntas repetidas.
• Preguntas sobre situaciones hipotéticas.
El objetivo de estas entrevistas es extraer todas las evidencias necesarias para

verificar que la organización actúa tal y como refleja la documentación entre-
gada al auditor.
Cierre de la auditoría
Al final de la auditoría, el equipo auditor debe reunirse con el solicitante del

resultado de la misma, indicando lo siguiente:
• Agradecer la colaboración.
• Recordar nuevamente el objetivo y alcance de la auditoria.
• Dar un resumen del resultado de la misma.
• Informar de las recomendaciones del equipo de auditoría.
• Preguntar si el solicitante tiene alguna cuestión que quiera aclarar.
• Recoger la conformidad del solicitante.
• Cierre de la reunión.
Las conclusiones y el informe de auditoría deberán basarse en:
• Las dos etapas de la auditoría conjuntamente.

• Las no conformidades encontradas.
• La documentación, implantación y efectividad del SGSI.
• Fortalezas y debilidades del SGSI.
• El compromiso de la dirección con la mejora continua.
En este punto, al igual que al final de la primera fase de la auditoría, se pueden

producir tres decisiones:
• El�auditor�detecta�no�conformidades�mayores. En este caso, el auditor

rechaza la certificación e informa de las no conformidades graves. Además,
propone a la empresa auditada que mejore la implantación del SGSI y que,
pasado un tiempo, vuelva a requerir el proceso de auditoría.
• El�auditor�detecta�no�conformidades�menores. Al igual que en las con-

clusiones de la fase 1, la organización auditada tiene que proporcionar una
serie de propuestas de acciones correctoras (con designación de responsa-
bles y el compromiso temporal de resolución), y llegar a un acuerdo con
el auditor para poder progresar en el proceso de certificación.
En estos casos, el auditor propone a la organización auditada que exponga
una serie de soluciones para estas no conformidades. Luego, será el auditor
el que se encargue de decidir si tales soluciones previstas solucionarían
estas no conformidades.
El auditado tendrá que proponer no sólo la solución, sino también un
tiempo en el que se resolverá dicha no conformidad.
En el caso de que el auditor decline estas soluciones, se indicará que tendrá
que volver a solicitar la auditoría. En el caso de que las soluciones que
plantea la organización sean aceptadas por el auditor, procederá a requerir
el paso a la segunda fase de la auditoría.
• El�auditor�no�detecta�no�conformidades. En estos casos, el auditor pro-

pone la concesión de la certificación a la organización.
En función de lo anterior, el equipo auditor debe emitir la recomendación:
• Se recomienda el registro, si se considera que el SGSI es conforme con la

norma.
• Se recomienda la revisión en caso de que se hayan encontrado no confor-
midades, a la espera de recibir un plan aceptable de acciones correctoras.
• Se recomienda volver a auditar parcialmente el SGSI, si se han encontrado
no conformidades mayores en un área concreta.
• Se recomienda volver a auditar, si se han encontrado no conformidades
mayores en más de un área.
Concesión de la certificación
La decisión final de conceder o no la certificación no la toma el auditor jefe,

sino el comité de certificación. Éste está formado por miembros de la orga-
nización auditora que no formen parte del equipo auditor. La decisión final
se basará en la información recogida durante el proceso de auditoría (las dos
etapas).
En caso de que la recomendación realizada por el equipo de auditoría sea un

no, el comité de certificación no deberá cambiar el criterio. En el caso contra-
rio, si la recomendación es un sí, el comité de certificación puede cambiar esta
decisión y no entregar el certificado.
En caso de que se emita el certificado, la entidad remitirá al solicitante una

carta o diploma indicando como mínimo:
• Nombre y dirección de la organización.

• El alcance de la certificación.
• La fecha de emisión del certificado y su periodo de validez.
• La versión de la declaración de aplicabilidad.
Una vez se ha obtenido la certificación, se procederá a entregar el certificado

y se entrará en un ciclo de revisión de la certificación. Este ciclo consiste en
la realización de una auditoría parcial de forma anual. La certificación estará
vigente durante, habitualmente, tres años.
En caso de que, durante una de las revisiones, el auditor detecte que existen
grandes problemas de seguridad o no conformidades, podría llegarse a retirar
el certificado.
M1.810 · Auditoría Técnica · PAC-2 ·Abril 2022
Auditoría de certificación ISO 27001

• Cuestión 1 – Familia de normas y trabajos ISO 2700
Realizad una investigación sobre las normas del conjunto ISO 27000 que con
fecha Enero 2020 están en estado aprobada por ISO. Relacionadlas,
explicando cuál es la temática que abordan. Indicad cuál o cuáles son
certificables.
Nota: recomendable acudir al sitio web del publicador de normas ISO y
consultar todas las normas realizadas por el subcomité 27 del comité técnico
1 (ISO/IEC JTC 1/SC 27). También aconsejamos que se repase la norma
ISO/IEC 27000:208 que es pública y disponible en la web de ISO.
Nota: Se sugiere presentar el resultado en formato de una tabla
Módulo 2 – Auditoría de certificación ISO 27001
Punto 1.6 Familia de estándares SO/IEC 27000
La mejor fuente de información para resolver esta pregunta es el propio sitio

web de ISO y consultar las normas publicadas relacionadas con los sistemas
de gestión de la seguridad de la información. Para ello se puede recurrir al
buscador:
http://www.iso.org/iso/home/search
O su búsqueda avanzada o al catálogo de normas organizadas por comités
donde buscaríamos las generadas por el subcomité técnico 27:
https://www.iso.org/committee/45306/x/catalogue/p/1/u/0/w/0/d/0
1
En este listado buscaremos a priori las numeradas comenzando por 27xxx y

las que se encuentran en los estados 60.60 y 90.x
Se debe observar que existe una norma básica que es la primera de la en la
numeración de las normas publicadas al respecto, la ISO/IEC 27000:2016 (es
su tercera edición). En esta norma está disponible de forma pública:
http://standards.iso.org/ittf/PubliclyAvailableStandards
En ella se muestran en el punto 0.2 el listado de las normas que forman parte
de la familia de normas dedicadas a los Sistemas de Gestión de la Seguridad
de la Información y además en el punto 4 se desarrolla más y se muestra un
diagrama que las relaciona.
El listado sería:
A continuación, en este apartado se detallan las normas más relevantes que

conforman la familia ISO 27000 (no las detallamos aquí, aunque el alumno sí
deberá hacerlo), y es importante detectar que indica cuales son susceptibles
de ser certificadas.
Dentro de ese grupo que es el que más nos interesa, hay que destacar que
sólo hay 2 normas susceptibles de ser empleadas en un esquema de
certificación y son las ISO/IEC 27001 y la ISO/IEC 27006. Se puede observar
en el diagrama del punto 4 de la norma ISO27000 que aparecen en la parte
más alta y señaladas como “Normative (requirements) Standards”, es decir
una estándar que determina una normativa de funcionamiento, y por lo tanto
susceptible de ser certificado su correcta aplicación. Aunque en el mercado
sólo se habla de certificación contra la norma ISO27001. Realmente la
ISO/IEC 27006 no es directamente certificable pero si es una norma que
contienen requerimientos, estos aplicables a las entidades de certificación
que vayan a certificar SGSI, y que complementa a los requerimientos
genéricos de la ISO/IEC 17021. Como a estas entidades les aplican muchas
2
normas, no se habla de que estén certificadas contra una u otra, sino que se
dice en general que “están acreditadas para certificar” algún tipo de actividad.
También se tiene que comentar que actualmente hay controversia sobre si las
normas ISO/IEC 27017 y ISO/IEC 27018 pueden ser o no certificables. En
realidad estas normas sólo son una ampliación del catálogo de controles de la
norma ISO/IEC 27002 pero, aunque no está muy extendido, algunos
proveedores muy conocidos de cloud computing como Microsoft (Azure),
Google (Google Cloud) o Amazon (AWS) han obtenido certificados contra
estas normas pero siempre de manera conjunta con la certificación contra
ISO/IEC 27001, no de manera independiente. Con esta misma interpretación
se puede incluir la norma ISO/IEC 27701 que es una extensión de la ISO/IEC
27001 específica para implementar sistemas orientados a gestionar la
seguridad de la privacidad de los datos de carácter personal.
A parte de este listado de normas específicas para la temática de los
sistemas de gestión de seguridad de la información, también existen dentro
del grupo de normas ISO27000 otras normas no relacionadas con SGSI sino
con otros aspectos de la seguridad de la información, como (publicadas, en
preparación hay aún más):
• ISO/IEC 27031:2011, Information technology -- Security techniques --
Guidelines for information and communication technology readiness for
business continuity ISO/IEC 27032:2012, Information technology -- Security
techniques -- Guidelines for cybersecurity
• ISO/IEC 27033-1:2009, Information technology -- Security techniques --
Network security -- Part 1: Overview and concepts
Network security -- Part 2: Guidelines for the design and implementation of
network security
Network security -- Part 3: Reference networking scenarios -- Threats, design
techniques and control issues
Application security -- Part 1: Overview and concepts
Information security incident management
Guidelines for identification, collection, acquisition and preservation of digital
evidence
• Etc.
Y muchas otras normas dentro del apartado “Information technology –
Security techniques” que son las normas que realiza el subcomité JTC 1/SC
27 - IT Security techniques (se puede consultar el catálogo completo de
normas de este subcomité aquí:
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_tc_browse.htm?co
mmid=45306&published=on)
3
Aquí podremos ver exactamente todo el trabajo de este grupo incluyendo

todos los estándares aún no publicados.
• Cuestión 2 – Valor de una certificación

La obtención de una certificación para un sistema de gestión ya sea de
calidad, medioambiental, de seguridad de la información o cualquier otro
sistema, tiene un valor en el Mercado. La organización transmite al Mercado
que realiza ciertas tareas de una manera de acuerdo con un estándar. Pero
¿por qué el Mercado confía en ese certificado? ¿Cuál es la base que sustenta
la confianza que el Mercado otorga al certificado?
La cuestión no está dirigida a explicar el valor aporta el certificado a la
organización que lo obtiene sino que expliquéis las bases sobre las que se
sustenta el valor, prestigio y reconocimiento de la obtención de la certificación
oficial de un SGSI. Se podrá tomar como ejemplo la empresa ejemplo descrita
en el anexo, si se desea explicar o describir situaciones más concretas.
Punto 2.2 Reconocimiento de la certificación
Punto 2.3 Reconocimiento de la entidad de acreditación
Punto 2.4 Requerimientos de una entidad de certificación
El alumno debe explicar que al tratarse de auditorías de 3ªparte, el cliente de
la auditoría no está explícitamente definido y es el mercado en general. Para
que este mercado tenga en consideración los resultados de la auditoría, en
este caso la obtención después del proceso de auditoría de un certificado,
este proceso debe ser realizado por organizaciones en las que el mercado
confíe. Estas organizaciones son las entidades de certificación que deben
cumplir un gran número de requerimientos que están recogidos en normas
que les son de aplicación, en nuestro caso de interés serían como mínimo las
normas ISO/IEC 17021 y la ISO/IEC 27006. La correcta aplicación de estas
normas y el correcto desarrollo de los procesos de certificación que realiza la
entidad de certificación son comprobadas por otras entidades conocidas
como entidades de acreditación, que en España es ENAC. En general, las
entidades de certificación son organizaciones de todo tipo, privadas, públicas
o semi-públicas, pero en la mayoría de las ocasiones, las entidades de
acreditación o bien son públicas o bien están promovidas por un gran número
de organizaciones que haga que sean consideradas entidades realmente
independientes.
4
Respuesta de un alumno (2016):

“
El prestigio y reconocimiento de la obtención de la certificación oficial de un
SGSI se sustenta en:
1. El prestigio de la norma de referencia, en este caso la norma ISO 27001
2. El prestigio y reconocimiento de la entidad certificadora (la institución legal
que a partir de una auditoria de tercera parte certifica que el auditado realiza
las actividades de acuerdo con una norma de referencia)
3. El prestigio y reconocimiento de la entidad de acreditación (organismo
encargado de controlar periódicamente que las entidades de certificación
desempeñan su trabajo de acuerdo con las normas que rigen su actividad) a
la que se encuentra adscrita la entidad certificadora
El prestigio de las normas de la serie ISO 27000 proviene de que:
• Están creadas por expertos bajo la coordinación de las organizaciones
ISO e IEC (ambas organizaciones cuentan con un reconocido prestigio
y solvencia).
• Han sido consensuadas por todos los actores: Proveedores,
fabricantes, usuarios, grupos de consumidores, laboratorios de
ensayos y científicos, profesionales reconocidos del sector y
organizaciones de investigadores.
• Cuentan con una amplia aplicabilidad, tanto por sectores, como por
ámbito geográfico (son de carácter mundial)
• Todos los participantes son voluntarios aceptados de acuerdo con
unos criterios que demuestran su aceptación y su valía profesional.
La capacidad, el prestigio y el reconocimiento de la entidad certificadora para
realizar la auditoria y emitir el certificado se basa en:
• La profesionalidad de los auditores.
• La independencia entre el auditor y el auditado
• El uso de procedimientos estandarizados y auditados por una entidad
superior (entidad de acreditación)
• Los requisitos de la norma ISO/IEC 17021 que las entidades deben
cumplir, entre los que se encuentran los siguientes: Imparcialidad,
competencia, responsabilidad, transparencia, confidencialidad y
capacidad para la resolución de conflictos
• Las acreditaciones obtenidas por parte de los organismos de
acreditación (ENAC, UKAS,…)
El prestigio de las entidades de acreditación proviene de que:
• Suelen ser un organismo oficial nacional
5
• Suelen tener carácter público o semipúblico y sin afán de lucro (lo cual
garantiza su independencia)
• Son la máxima autoridad en la materia de aplicación
• Son independientes“
• Cuestión 3 – Modelo PDCA del SGSI y auditoria de certificación del

mismo
El Sistema de Gestión de la Seguridad de la Información se basa en un
modelo de mejora continua. El modelo PDCA es uno de los más conocidos
pero ya no es requerido por ISO 27001:2013 como referencia para
implementar el modelo de mejora. Sin embargo, sigue siendo una buena
referencia y se puede tomar como un modelo para implantar un SGSI.
Durante la auditoría de certificación buscamos comprobar este proceso de
mejora continua. Y, por lo tanto, se revisará que, entre otras cosas, se están
realizando tareas referentes a la P-Planificación. En esta pregunta se debe
explicar los aspectos que revisa el auditor para asegurarse de que esta etapa
se ejecuta correctamente.
Punto 1.3 Ciclo de Deming – ciclo PDCA
Punto 2.6.1 Ejecución del SGSI implantado según el modelo PDCA
Punto 3.1.1 Revisión de la implantación del modelo PDCA
Punto 3.2.4 Stage 1. Auditoría documental
Punto 3.2.5 Stage 2. Auditoría presencial o “in situ”
El alumno deberá mostrar la comprensión de las distintas partes que

componen un SGSI y las acciones de auditoría que realizaría un auditor. La
norma ISO/IEC 27001 viene a definir que el SGSI debe estar basado en un
PDCA e incluye los requerimientos que se le pide.
Los puntos que como mínimo comprobará el auditor para verificar que el
SGSI está correctamente implementado y en concreto los elementos que son
el soporte de la fase de Planificación sería:
• Definición del propio SGSI
o Descripción del Alcance
6
o Compromiso de la dirección, principalmente a través de una

definición y aprobación formal y explicita de la política de
seguridad
• Definición de manera continuada de los controles necesarios en el
SGSI basado en un Análisis de Riesgos según los requerimientos
definidos por la norma. Por tanto:
o Deberá existir una metodología para la realización de Análisis
de Riesgos basada en activos, amenazas y vulnerabilidades
que determinen posibles impactos en materia de
confidencialidad, integridad y disponibilidad. Tiene que existir
además una definición de cuál es el nivel o umbral de riesgo
aceptable para la organización y éste debe ser aprobado por la
dirección.
o El análisis de riesgos debe existir y de acuerdo a la
metodología descrita.
o El análisis de riesgos debe tener asociado un plan de
tratamiento del riesgo
o Todo lo referente al Análisis de Riesgos debe contar con el
visto bueno y aprobación por parte de la dirección
• Declaración de aplicabilidad: este es otro punto fundamental que el
auditor revisará ya que es el resumen de los controles que la
organización decide implantar y también debería de recoger el modo
en que implantarlos mejoraría los niveles de riesgos (esto a veces no
se realiza en las primeras iteraciones del SGSI y si la certificación se
busca sin estar suficientemente maduro el SGSI podría darse la
situación en que no se hubiera realizado. En estos casos, el auditor no
suele determinarlo como no conformidad grave, sino como máximo
leve e incluso en ocasiones como observación para que en futuras
auditorias de seguimiento se mejore este punto)
• Plan de tratamiento del riesgo: este es otro elemento exigido por la
noma y que el auditor deberá identificarlo, evaluarlo y comprobar que
efectivamente está relacionado con el análisis de riesgos, la
declaración de aplicabilidad, y que ha sido revisado y aprobado por la
dirección.
7
• Cuestión 4 – Nueva versión del estándar ISO/IEC 27001:2013

Uno de los puntos más novedosos de esta nueva versión respecto a la
versión de 2005 es la nueva estructuración que tiene para adecuarse a la
estructura definida en el Anexo SL.9 de las directivas de ISO para la
definición de los estándares de Sistemas de Gestión. Razonad que ventajas
conlleva (probablemente a largo plazo puesto que a día de hoy sólo ISO/IEC
27001 se ha adecuado a esta estructura del Anexo SL) para una organización
que disponga de varios Sistemas de Gestión.
Wiki de la asignatura “Comentario sobre la nueva versión de 2013 de la
norma ISO/IEC 27001:2013”
El alumno deberá mostrar la comprensión del artículo de la wiki, observar que

el objetivo de la unificación de los sistemas de gestión es simplificar,
uniformizar i facilitar tanto la labor de los implantadores de sistemas de
gestión, las organizaciones que los operen y la labor de auditoría de
certificación de los mismos, redundando además en reducciones de costes en
todas esas actividades, al permitir la creación de sistemas de gestión mucho
más integrados al favorecer que existan procesos de gestión que sean
transversales a todos los sistemas de gestión que la organización decida
implantar.
• Cuestión 5 – No conformidades de auditoria

Tomad como escenario la empresa ejemplo descrita en el anexo. Imaginemos
que ha solicitado la certificación de su SGSI y ha presentado la solicitud a una
entidad de certificación. Suponed que se ha realizado la auditoría por un
equipo de la entidad de certificación del que vosotros sois el auditor jefe y
ahora estáis evaluando los informes internos de la auditoria y debéis
determinar las no conformidades.
En este ejercicio se pide dar ejemplos de No Conformidades, 2 de tipo Grave,
y 2 de tipo Leve. En total se deben dar 4 ejemplos. Los ejemplos deben
tomarse en áreas o aspectos bien diferenciados del SGSI, una de cada una
de estas áreas:
• Compromiso de la alta dirección
• Análisis de Riesgos
• Revisión y mejora del SGSI por parte de la dirección
8
• Implementaciones de controles de seguridad

El nivel de no conformidad del ejemplo escogido por el alumno en cada una
de estas áreas debe ser razonado adecuadamente.
Nota: En este punto NO se pide redactar ningún tipo de documento que
pudiera ser asimilable a un informe de auditoría. Se pide una explicación
razonada de los ejemplos de no conformidades que el alumno decida.
Punto 2.6.1 Ejecución del SGSI implantado según el modelo PDCA
Punto 3.1.1 Revisión de la implantación del modelo PDCA
Punto 3.2.4 Stage 1. Auditoría documental
Punto 3.2.5 Stage 2. Auditoría presencial o “in situ”
Este punto es totalmente práctico y se podría dar diversos ejemplos. Es

esencial que el razonamiento para determinar si es o no una no conformidad
se sustenten en que aspecto de incumplimiento del modelo PDCA, de error
de implantación de control o de algún otro requerimiento de la norma ISO/IEC
27001.
9
Auditoría Técnica de
Seguridad TIC
01 Presentación
Auditoría técnica de seguridad

02 de sistemas de información y
comunicaciones
03 Solución PEC 3
-1-
Universitat Oberta
de Catalunya
Aula
Módulo 3 - Auditoría Técnica de Seguridad TIC
Inicio: Fin:
28/03/22 10/04/22
00:00h 24:00h
europea de europea de
verano (CEST) verano (CEST)
Materiales
Auditoría técnica de seguridad de sistemas de información y comunicaciones

Audiolibro
ePub
Mobipocket
html5
Pdf
Auditoría técnica
de seguridad
de sistemas de
información y
comunicaciones
PID_00285945

© FUOC • PID_00285945 Auditoría técnica de seguridad de sistemas de información y...



Producción: FUOC
© FUOC • PID_00285945 Auditoría técnica de seguridad de sistemas de información y...
Índice
Introducción............................................................................................... 5
1. Factores de éxito de una auditoría técnica................................. 9
2. Alcance de la auditoría técnica..................................................... 12

2.1. Características del alcance de una auditoría ............................... 12
2.2. Determinación del alcance ......................................................... 13
2.3. Técnicas para determinar el alcance ........................................... 17
3. Enfoque del alcance de la auditoría técnica TIC....................... 21

3.1. Aspectos técnicos del alcance ..................................................... 21
3.1.1. Revisión del compromiso de la gobernanza de la
seguridad de la información .......................................... 23
3.1.2. Revisión de la seguridad física ....................................... 23
3.1.3. Revisión de la seguridad perimetral de las redes de
comunicaciones ............................................................. 27
3.1.4. Revisión de los mecanismos de control de seguridad
en sistemas operativos y aplicaciones ........................... 28
3.1.5. Revisión de la gestión del ciclo de vida de los
sistemas .......................................................................... 29
3.1.6. Revisión de los planes de continuidad de negocio ........ 33
3.1.7. Revisión de la capacidad de respuesta ante
incidentes ....................................................................... 34
3.2. Impacto del conocimiento previo en el alcance de la
auditoría ...................................................................................... 34
3.3. Impacto del esfuerzo en el alcance ............................................. 39
4. Planificación de una auditoría técnica de seguridad.............. 43

4.1. Definición del plan de auditoría ................................................ 44
4.2. Ejecución de la auditoría ............................................................ 50
4.2.1. Recolección de información previa ............................... 51
4.2.2. Ejecución de las pruebas de auditoría ........................... 51
4.2.3. Análisis de la información ............................................. 52
4.3. Reporting de la auditoría .............................................................. 55
4.4. Seguimiento de la auditoría ........................................................ 57
© FUOC • PID_00285945 5 Auditoría técnica de seguridad de sistemas de información y...
Introducción
Ya hemos comentado en el módulo 1 de introducción a la auditoría de sistemas

de información que el proceso de auditoría, de manera general, es la aplicación
de una revisión sistemática del cumplimiento de unos criterios de auditoria.
También vimos que la tendencia actual en la gestión más eficiente y alineada
con el negocio (Gobierno TIC) es incluir las actividades de auditoría.
Auditorías�técnicas�de�seguridad�frente�a�auditorías�de�certificación
En el módulo 2, se trató el aspecto más formal de las auditorías que toman la

forma de auditorías de tercera parte o de certificación. Las auditorías de certi-
ficación son procesos muy formales y cumplen un objetivo muy particular: se
desea que una entidad externa al auditado que, a priori no está determinada,
pueda disponer de la opinión de un tercero sobre el modo en que se gestiona
la seguridad de la información tomando como referencia un marco regulado y
reconocido. Sin embargo, por su necesidad de estar muy formalizada y regu-
larizada, no es aplicable cuando se buscan unos objetivos de auditoría mucho
más concretos y profundos que simplemente declarar si el modo en que se
gestiona la seguridad de la información es acorde a un determinado estándar.
Esta visión puede ser suficiente si nos planteamos una auditoria de tercera par-
te, pero cuando se trata de auditorías de primera o segunda parte, el cliente de
la auditoría necesita una respuesta más concreta a preguntas más específicas,
pues desea tener una visión detallada sobre el modo en que se está realizando
un aspecto concreto de la gestión de la seguridad de la información.
Es por tanto en este contexto en que los sistemas de para la gestión de la

seguridad se encuentran sometidos a un tipo de auditoría más específica que
la de certificación. En este tipo de auditoria, que nosotros denominaremos
auditorías técnicas de seguridad –aunque podríamos también llamarlas más
sencillamente auditorías de sistemas de información–, se evaluarán controles
específicos contra unos criterios de auditoria más precisos:
• Las políticas propias de la entidad auditada que describan el control.
• Los catálogos de controles ampliamente reconocidos en el ambiente en

que se encuentre la entidad.
• Las técnicas y mejores prácticas (organizativas y también tecnológicas)

más actuales para la implementación de cada tipo concreto de control.
Por lo tanto, cuando nos referimos a una auditoría técnica de seguridad esta-
remos hablando de un proceso sistemático, y técnicamente mesurable, de có-
mo una determinada política de seguridad de una organización es aplicada en
un ámbito concreto, y los problemas que pueden existir en la implementación
de los controles.
Auditorías�técnicas�de�seguridad�y�sistemas�de�gestión�de�la�seguridad�de
la�información
Las políticas de seguridad de una organización en que exista un sistema de

gestión de la seguridad maduro deberían constituir la piedra angular sobre la
que realizar las auditorías técnicas de seguridad.
Estos documentos han de tratarse como documentos vivos y reflejar, con mu-
cha precisión, cómo la organización protege sus activos de información me-
diante la implantación de mecanismos (procesos organizativos y también tec-
nología que los apoye) que se han de poner en marcha. Sin embargo, el en-
torno y las necesidades de la organización son cambiantes y, por lo tanto, tam-
bién el modo en que se trata la información; por consiguiente, las políticas de
seguridad tienen que adaptarse a estos cambios.
Como conclusión de un proceso de auditoría, se darán indicaciones y reco-

mendaciones no sólo del nivel de alineamiento de las prácticas con las políti-
cas, sino que también podrán concluir sobre la corrección de estas políticas y
el modo en que estas están implementadas desde los puntos de vista técnico,
procedimental u organizativo.
En este sentido, hay que destacar que este tipo de auditorías forman parte in- Nota
tegrante del ciclo de gestión de la seguridad de la información. La integración
Desde 2013, ISO eliminó de la
de las auditorías en el SGSI es obvia participando en la fase "verificar" (check) norma ISO/IEC 27001 la refe-
del modelo PDCA (ved el módulo 2, en el que se describen las características rencia explícita al modelo PD-
CA para el modelo de referen-
de un SGSI según norma ISO/IEC 27001) y no como un simple ejercicio ar- cia de mejora continua que
debe seguir todo SGSI certifi-
bitrario o académico de una organización. Involucra a todo el personal que cado según esta norma, pero
en el resto del curso lo conti-
emplee un recurso de los sistemas de información de la organización. Su re- nuaremos empleando por ser
sultado resultará de interés no sólo a la dirección de sistemas de información sencillo, ampliamente cono-
cido y explicado, y porque es
para conocer y medir, objetivamente, el nivel de seguridad conseguido, sino válido a la hora de implemen-
tar un SGSI conforme a la nor-
que también a la dirección de la parte usuaria de los sistemas, pues le dará una ma.
imagen del grado de confiabilidad que se les puede otorgar. Esto es aún más
claro y necesario si el SGSI está certificado contra la ISO/IEC 27001, ya que la
cláusula 9.2 “Auditoría interna” así lo requiere. En este caso es requerido que
la organización implemente la función de auditoría y que ponga en marcha
un programa de auditoría (ver módulo 1) cuyo objetivo sea la verificación.
Como se comentó en el módulo 1, en las auditorías existen dos tipos de prue-

bas, las pruebas de cumplimiento y las sustantivas. Cuando una organización
decide realizar una auditoría interna de seguridad en su entorno, se puede rea-
lizar de dos maneras.
Una opción es realizar una auditoría puramente de cumplimiento en la que

las pruebas son fundamentalmente de cumplimiento. Por lo tanto, las pruebas
van destinadas a verificar simplemente si existen procesos y controles de segu-
ridad. Esta sería una auditoría muy similar a las de certificación y tienen todo
el sentido en una organización, tanto para saber si se obtendría la certificación
(o la mantendría, si ya la tiene), como para verificar que los controles están
presentes y funcionando. Pero no obtendría información de si estos controles
son los mejores posibles o si pueden existir problemas en ellos más intrínsecos
que pongan en riesgo la seguridad.
La otra opción es verificar si el proceso de control existe y alcanza plenamente

su objetivo. Para ello la auditoría se realiza en base a pruebas sustantivas que
examinarán todo el ciclo del proceso que se pretende controlar y verificaría
si los controles aplicados consiguen su objetivo. Por supuesto que este tipo
de auditorías tienen una naturaleza completamente distinta a las comentadas
antes. Estas son las que habitualmente se manejan en las áreas de seguridad de
una organización para comprobar y descubrir si hay problemas de seguridad
en sus sistemas de información, y suelen ser el tipo al que se refieren cuando
se habla de “auditoría de seguridad”. Es interesante notar que, en estas audito-
rías, los hallazgos suelen ser denominados vulnerabilidades, ya que estos pro-
blemas ponen en evidencia problemas que podrían poner en riesgo alguna de
las dimensiones de la seguridad de la información (confidencialidad, integri-
dad o disponibilidad, u otras facetas como la autenticidad o la trazabilidad).
Ambos tipos de auditoría no son excluyentes y, muy al contrario, las organi-

zaciones maduras emplean ambos tipos en sus programas de auditoría para
abarcar tanto la verificación del proceso general de control de la seguridad de
la información, como para descubrir vulnerabilidades en sus procesos de con-
trol de seguridad.
En adelante, en este material, nos vamos a centrar en auditorías técnicas de

seguridad con pruebas sustantivas, ya que las otras son fundamentalmente
muy similares a una auditoría de certificación que hemos tratado ya.
Como se ha indicado, la auditoría técnica de seguridad (la que incluye prue-

bas sustantivas) es esencialmente un examen de cuán eficientemente se ha
implantado la política de seguridad de una organización. Por supuesto, esto
presupone la existencia previa de este tipo de políticas. Estos documentos pre-
tenden estandarizar en la organización las prácticas de seguridad, y describir
los controles de seguridad que se han de implantar para asegurar que, en to-
dos los niveles de la organización, se entienda cómo se ha de proteger los acti-
vos de información. Sin embargo, en las organizaciones actuales es habitual la
inexistencia de documentos que describan los controles de seguridad implan-

tados o bien los describen a un nivel alto sin entrar en muchos detalles técni-
cos sobre el modo en que concretamente se deben implantar ciertas medidas
técnicas con el fin de obtener el objetivo de control que se pretende.
Cuando los controles de seguridad no se encuentran descritos, están incomple-

tos, o su implantación ha sido realizada de manera informal y no planificada
(por ejemplo, porque no se encuentran enmarcados en un sistema de gestión
de la seguridad de la información), puede que se estén aplicando controles de
manera incorrecta tanto por su alcance como por su modo de implantación.
En estos casos, una auditoría técnica de seguridad también resulta apropiada,
dado que permite comprobar el modo en que se encuentran implantados los
controles, tanto en el alcance del control (podría ser que el control no esté
aplicado en todo el proceso a control) como en el detalle técnico de funcio-
namiento (puede que el control tenga algún problema en su implementación
que haga que no funcione en determinadas circunstancias). El l resultado pue-
de ser empleado para la planificación de subsiguientes acciones orientadas a
la implantación, en la organización, de un sistema de gestión de la seguridad.
Por tanto, es habitual que las auditorías de seguridad formen parte del proceso
de análisis de riesgos que se suele desarrollar en la fase "planificar" (plan) del
modelo PDCA.
Establecidos los objetivos de una auditoría técnica de seguridad, es habitual

que el equipo auditor trabaje con un gran conocimiento de los activos e infra-
estructuras a auditar, aunque no es completamente necesario, como veremos
más adelante. Dependiendo del objetivo concreto que persiga una auditoría
técnica, el equipo auditor contará con más o menos conocimiento previo del
entorno auditado. El proceso de auditoría de seguridad incluirá tareas como
entrevistas con el personal de operación y mantenimiento de aplicaciones y
sistemas, análisis de vulnerabilidades de redes, sistemas y aplicaciones, com-
probaciones detalladas de la parametrización de sistemas, etc.
1. Factores de éxito de una auditoría técnica
Toda auditoria tendrá un cliente de auditoría con quien el equipo auditor de-
berá pactar los objetivos de la misma. Estos objetivos serán contra los que se
evaluará el resultado de la auditoría para determinar su éxito o fracaso. Por
tanto, el éxito de una auditoría dependerá, en gran medida, de la impresión
general que tenga el auditado de los resultados obtenidos. Otro elemento que
determinará el éxito o fracaso de una auditoría es el punto de vista del auditor
en el sentido del esfuerzo que realiza frente al que se había planificado. Esto
es así tanto si el equipo auditor es interno como externo.
Entre los distintos factores que van a afectar al éxito de una auditoría, podemos
encontrar:
• Correcta� determinación� del� alcance� de� la� auditoría. Este es el punto

crítico que determina el éxito o el fracaso de una auditoría y en general es
el que condiciona el resto de factores que se detallarán a continuación. De
hecho, suele ser el mayor problema con el que se encontrará el equipo au-
ditor durante la ejecución de la auditoria. Como en cualquier otro tipo de
proyecto, el alcance determina el esfuerzo, los recursos técnicos, logísticos
y humanos necesarios, y las fases o tareas a realizar para ejecutar la audi-
toría. Un alcance mal definido, o en cambio, constante y no gestionado,
puede hacer fracasar la auditoria y que los resultados que se obtengan no
cumplan con los objetivos esperados por el cliente. La existencia de este
riesgo no implica que el alcance no evolucione a lo largo del desarrollo de
la auditoría. Todo lo contrario; es habitual que se vaya ajustando en base a
la progresión de la auditoría. Ciertos hallazgos, o la falta de ellos, pueden
redirigir la auditoría hacia otro lado. El riesgo se materializa, realmente,
cuando la modificación no está gestionada o se hace de manera incorrecta.
Más adelante, en este mismo módulo, ahondaremos en la determinación
del alcance de la auditoría.
• Correcta�planificación�del�esfuerzo�y�los�recursos�destinados. Como en
cualquier otro tipo de proyecto, es esencial una correcta planificación de
las tareas a realizar y del uso de los recursos, tanto humanos como mate-
riales si fueran necesarios. Este aspecto incidirá más en el éxito económico
de la auditoría, y no tan determinantemente en su éxito técnico.
• Correcta�selección�del�equipo�auditor. Es importante que el equipo au-

ditor esté compuesto por miembros que dispongan de la suficiente pericia
o habilidad técnica en las áreas que resulten de interés por el alcance que
se haya determinado, o bien que se pueda disponer de las personas con el
perfil adecuado en las fases del proyecto que corresponda.
La composición del equipo de auditoría sería similar a la determinada ante-

riormente en el módulo 1. Mientras que para la composición de un equipo
auditor en una auditoría de certificación sí que existen requerimientos, no
existen requerimientos específicos para componer un equipo para una audi-
toría técnica. En todo caso, sí podemos afirmar que el equipo debe combinar
capacidades suficientes. Resulta recomendable que exista algún componente
del equipo que tenga conocimientos sobre los procesos de auditoría (al estilo
que se exige en la norma ISO 19011) y, además, que haya tantos expertos téc-
nicos como aspectos distintos queden bajo el alcance.
(1)
Por otra parte, los requerimientos pueden haber sido impuestos por el cliente Information Systems Audit and
Control Association www.isaca.org
de la auditoría. Aunque no existen requerimientos para la composición de es-
te equipo, el cliente de auditoría podría exigir alguna determinada formación (2)
International Information Sys-
o experiencia para algunos componentes del equipo. Hay que destacar que, tems Security Certification Consor-
en la actualidad, en el mercado de la auditoría de seguridad se suelen exigir tium
las certificaciones de la ISACA1 (CISA: certified information systems auditor) y (3)

El programa "Global Infor-
de (ISC2)2 (CISSP: certified information systems security professional) para perfiles mation Assurance Certification"
www.giac.org
más versátiles; cuando se requiere conocimientos más específicos, se recurre
a certificaciones sobre seguridad emitidas por organizaciones especializadas o
por fabricantes, por ejemplo: de Offensive Defense la certificación Offensive Se-
curity Certified Professional - OSCP, Check Point Certified Security Expert – CCSE,
Red Hat Certified Security Specialist – RHCSS, del SANS Institute3 GIAC Systems
and Network Auditor – GSNA, Cisco Certified Security Professional – CCSP, Micro-
soft Certified Systems Engineer – MCSE, etc.
• Colaboración�con�el�auditado. Es necesaria la colaboración del auditado Ved también

tanto antes de afrontar la auditoría como mientras se ejecuta.
La composición del equipo se-
– Colaboración antes de realizar la auditoría. Antes de ejecutar la audi- rá la determinada en el módu-
toría es necesaria la complicidad con el auditado para poder llegar a lo 2.
un acuerdo en cuanto a qué se espera de la auditoría. Este punto está

íntimamente relacionado con el primer factor de éxito que hemos ex-
plicado. Muchas auditorías fracasan una vez realizadas en el momento
de presentar resultados a la dirección que "patrocinó" o inició el pro-
yecto. La dirección no esperaba el resultado que se obtuvo no porque
fuera técnicamente incorrecto o contrario a la realidad de la organi-
zación, sino simplemente o bien porque el trabajo realizado no se co-
rrespondía con la idea que tenía en mente o bien porque las conclu-
siones obtenidas no le resultaban relevantes o suficientes para tomar
las debidas decisiones.
– Colaboración durante la realización de la auditoría. Del mismo modo,

también es necesario contar con la colaboración del auditado durante
la ejecución de la auditoría. En gran número de ocasiones las auditorías
son percibidas negativamente por parte del personal del auditado. De-
pendiendo del tipo de auditoría que se esté realizando, esta percepción
negativa de la auditoría provocará una falta de colaboración con el
equipo auditor y con toda probabilidad conllevará la necesidad de un
esfuerzo mayor para la ejecución de las distintas fases de la auditoría.
Auditorías basadas en entrevistas
La colaboración durante la realización de la auditoría es especialmente importante cuan-

do gran parte de las actividades de la auditoría se basan en entrevistas. Si el entrevistado
no facilita la información demandada o bien da respuestas que no son confiables, serán
necesarias más entrevistas con otro personal similar en funciones para contrastar versio-
nes. Igualmente, en ocasiones es necesaria la colaboración del auditado para conocer el
entorno o infraestructuras auditadas. En caso de carecer de ella, el equipo auditor nece-
sitará dedicar parte de sus esfuerzos a adquirir un conocimiento sobre el entorno que el
propio auditado podría facilitar.
Por lo tanto, para estar en disposición de realizar una auditoría con suficientes
garantías de éxito, el auditor jefe (o jefe del proyecto) deberá evaluar correc-
tamente cada uno de estos factores antes de afrontar fases más específicas de
la auditoría. Esta evaluación se puede considerar como la realización de un
análisis de riesgos del proyecto. El jefe de proyecto tendrá que identificar to-
das las posibles amenazas a su proyecto, establecer la probabilidad de que ocu-
rran, determinar cuál sería el impacto y las posibles salvaguardas que podría
emplear el equipo auditor. De este modo tendrá que hacerse una idea clara de
todos los factores que pueden incidir en el correcto desarrollo de su proyecto
y debe tener previsto planes para afrontar las contingencias que prevea.
2. Alcance de la auditoría técnica
Para garantizar que una auditoría de seguridad sea exitosa, ante todo
se ha de determinar y consensuar su alcance con el cliente; es necesa-
rio que sea establecido antes de afrontar cualquier otra actividad de la
auditoría.
De manera general, en cualquier proyecto, para poder estimar los medios ne-
cesarios y el nivel de esfuerzo requerido por el equipo auditor y por el auditado,
es esencial determinar de manera detallada y realista el alcance del trabajo que
se ha de realizar. En el ámbito de la auditoría de seguridad, la determinación
del alcance también es esencial, puesto que mostrará la satisfacción del audi-
tado y del equipo auditor mientras está realizando su asignación de auditoría.
2.1. Características del alcance de una auditoría
El alcance de la auditoría tiene que ser visto como el acuerdo mutuo

entre auditor y auditado sobre qué se va a realizar en la auditoría.
Para determinar correctamente el alcance, deben identificarse correctamente

los siguientes aspectos relevantes acerca de la auditoría que se ha de realizar:
• Las áreas de la organización auditada que serán examinadas. La audito-

ría debe abarcar no sólo las áreas físicas de la organización auditada, sino
también las funcionales (grupos o áreas organizativas), sistemas de infor-
mación y comunicaciones, procesos de negocio, etc..
• Los límites a los esfuerzos que se han de realizar en la auditoría, tanto

lógicos como físicos, con el fin de poder ajustar el esfuerzo de auditoría
desde el punto de vista económico para alcanzar los objetivos de auditoría.
• Las fechas y el esfuerzo del trabajo que se ha de desarrollar por parte del
equipo auditor para poder planificar las tareas tanto del auditor como del
auditado y afectar lo menos posible a sus actividades habituales.
• La lista de todas las acciones que se deberán llevar a cabo durante la audi-
toría. No se trata tanto de detallar exactamente, sino de conocer desde un
punto de vista de alto nivel qué tipo de pruebas se deberán ejecutar.
• Las expectativas que se derivan del proyecto, en especial qué tipo de entre-
gables se realizarán. Es crucial conocer bien el objetivo que tiene el cliente
de la auditoría para poder cumplir con sus expectativas y que su resultado
aporte valor al cliente de la auditoría.
En el caso de un auditor externo, habitualmente estos aspectos se pactan en-

tre auditado y auditor en un contrato; mientras que en el caso de un auditor
interno se establece en una asignación o instrucción de trabajo.
2.2. Determinación del alcance
Como se ha comentado al inicio del módulo, cualquier actividad involucrada

en la gestión de la información es susceptible de ser auditada, o bien para com-
probar cómo se aplican las políticas y normas de seguridad de la organización,
o bien para comparar la práctica que se realiza con los códigos de buenas prác-
ticas existentes. Por tanto, cualquier aspecto que se encuentra tratado dentro
de los catálogos estándares de controles de seguridad (por ejemplo, ISO/IEC
27002 o COBIT) es susceptible de ser auditado.
De manera general, desarrollar el alcance de un proyecto de auditoría es la

tarea inicial donde se deciden los límites que se aplicarán al trabajo que se
debe realizar por el equipo auditor, así como los requisitos técnicos necesarios
y las técnicas. En una auditoría de seguridad, definir estas "fronteras" incluiría
determinar:
• ¿Qué procesos de negocio de la organización están afectados por la audi-

toría y qué partes de estos procesos se revisarán? ¿Todo el proceso? ¿úni-
camente la parte exclusivamente soportada por los sistemas de informa-
ción? ¿Nos centraremos en una auditoría de carácter técnico o también
revisará procesos? Es necesario, por lo tanto, que el cliente de la auditoría
y el auditor acuerden los procesos que serán objeto de la auditoría.
• ¿Qué área o tipo de controles de seguridad son los que se van a auditar?
¿Están claramente definidos estos controles o deben emplearse como refe-
rencia guías de buenas prácticas o incluso directamente la opinión técnica
del auditor? El auditor debe tener clara cual es la referencia contra la que
debe auditar y determinar si hay o no hallazgos. Si la organización tiene
descritos en una política de seguridad los controles puede que sea esta la
referencia. Si por el contrario no existe o es demasiado generalista, será
necesario incluir códigos de buenas prácticas.
• En el caso de que se vayan a auditar infraestructuras técnicas de tratamien-

to de información, ¿qué sistemas físicos, segmentos de redes o aplicacio-
nes están bajo el alcance? Deben concretarse claramente ubicaciones, di-
reccionamientos IP, dominios y, en general, cualquier aspecto técnico para
determinar si un determinado activo está o no bajo el alcance.
• En el caso de que se vayan a auditar procesos que tratan la información

y que son ejecutados por diversas estructuras organizativas del auditado,
¿qué personal de la organización se encuentra afectado por la auditoría
y con cuál nos entrevistaremos? Aunque desde un inicio no es necesario
identificar concretamente personas, sí que es necesario que en el alcance
quede bien determinado qué equipos de personas se ven afectados por la
auditoría y si se requerirá su colaboración o no.
Determinar estos aspectos condiciona totalmente el trabajo a realizar poste-

riormente.
Caso práctico: seguridad de un banco
Planteémonos la revisión del sistema de identificación y autenticación de un banco me-

diante la "tarjeta de coordenadas".
La organización auditada ha mejorado recientemente los controles de identificación y

autenticación en su plataforma de banca electrónica y ha sustituido el antiguo esquema
de usuario/contraseña al inicio de la aplicación por un sistema con dos fases de auten-
ticación: una al inicio mediante usuario/contraseña y una segunda autenticación en de-
terminadas operaciones clave mediante el uso de una tarjeta de códigos distribuida a los
clientes. La dirección está preocupada por la seguridad del sistema puesto en marcha y
desea que una organización externa dé una estimación sobre la seguridad del nuevo sis-
tema de identificación y autenticación.
A la hora de plantear cuál es el alcance real de la auditoría propuesta, el equipo auditor

puede plantearse dos opciones extremas:
• Nos podemos fijar únicamente en el proceso técnico propio de la identificación y

autenticación, y delimitar nuestro trabajo de auditoría a la revisión de la plataforma
(servidores web) donde corre la aplicación en búsqueda de problemas/vulnerabilida-
des. El alcance del proyecto sería por consiguiente la plataforma tecnológica emplea-
da y la aplicación que se haya diseñado sobre ella. Nos encontraríamos ante una au-
ditoría de seguridad puramente técnica.
• Otra opción sería determinar un alcance mucho más amplio y revisar todos los pro-
cesos que intervienen en el ciclo completo de vida de la tarjeta de coordenadas, desde
su creación, pasando por la distribución, su uso y su destrucción. Por lo tanto inclui-
ría tareas como las siguientes:
– Verificación de la seguridad de los algoritmos que se emplean para generar las
tarjetas.
– Revisión de la seguridad en el proceso informático de creación.
– Comprobación de la seguridad durante la impresión física de las tarjetas especial-
mente si se realiza por empresas subcontratadas.
– Verificación de la confidencialidad durante el proceso de distribución de las tar-

jetas.
– Revisión de las cláusulas de confidencialidad en los contratos con empresas sub-
contratadas que manejan estas tarjetas.
– Identificación del nivel de formación necesaria dado a los usuarios,
– Revisión de la implementación técnica de la plataforma web donde se emplea
la tarjeta.
Como se ve, esta auditoría tendrá un alcance mucho más amplio que la anterior y ne-
cesariamente el equipo auditor deberá dedicar muchos más recursos y esfuerzos para su
realización.
Respecto a la pregunta de cuál de los dos enfoques es más adecuado, la respuesta es que
cualquiera de las dos opciones es válida, siempre que el cliente de la auditoría conozca el
alcance y esté de acuerdo con él. Por lo tanto, antes de iniciar siquiera la planificación de
tareas de la auditoría, es esencial llegar a un acuerdo con la dirección de la organización
auditada que recibirá el informe de auditoría para determinar cuáles son sus expectativas
y necesidades. En base a esta recogida de información, el equipo auditor podrá determinar
qué punto intermedio entre nuestras dos opciones es el que realmente desea el auditado.
Gran parte de los proyectos de auditoría de seguridad fallidos lo son debido

a algún tipo de problema a la hora de definir su alcance. Se debe entender
como auditoría fallida tanto aquella que claramente no satisface al cliente de la
auditoría porque no le aporta valor, como aquella en la que el equipo auditor
ha invertido mucho más esfuerzo del que estaba previsto. Es muy habitual
que el alcance sea inicialmente mal definido o ambiguo provocando, durante
el desarrollo de la auditoría, que se desvíen los esfuerzos y que se incurra en
sobrecostes o en entregas fuera de plazo o incluso que produzcan un resultado
que no cumpla con las expectativas de los patrocinadores de la auditoría -
usualmente la dirección ejecutiva de una entidad.
Las razones por las que el alcance del proyecto se encuentra mal definido son
muy diversas y dependen de cada escenario. A pesar de ello se pueden dar
ciertas indicaciones para evitar los fallos más comunes. De manera general,
es necesario que los siguientes puntos estén bien claros para el auditor, ya
sea explícitamente descritos en el alcance o bien que al menos tenga clara la
respuesta:
• Identificar�las�razones�que�mueven�al�auditado�a�realizar�la�auditoría.
Generalmente el auditado realiza la auditoría por una razón bien precisa
y conocerla nos permitirá delimitar las áreas de interés. Conocerlo de an-
temano permitirá al auditor tener bien clara la razón que mueve al cliente
de la auditoría y así garantizar que el resultado del trabajo aportará valor
al cliente. Algunas de estas razones pueden ser:
– Requisitos legales o regulatorios en su sector de actividad.
– Requisitos impuestos por un cliente o por una entidad aseguradora.
– Necesidad de garantizar la protección de una infraestructura crítica
(por ejemplo: instalaciones de distribución de agua, electricidad, cen-
trales eléctricas, etc.).
– Proporcionar a un tercero una garantía o nivel de confianza acerca de
la seguridad de los procesos analizados por el auditor. Las auditorías
exigibles en el marco de un SGSI se encontrarían situadas en este apar-
tado, puesto que el objeto de implantar un SGSI en la mayoría de los
casos es ofrecer a un tercero garantías sobre la seguridad en el trata-

miento de la información en la organización donde se encuentra im-
plantado el SGSI.
– Respuesta a incidentes de seguridad acaecidos en el pasado.
– Validación externa de una auditoría realizada internamente.
• Identificar�las�limitaciones�aplicables�al�propio�auditado. Todas las or-

ganizaciones tienen ciertas limitaciones que le son impuestas a la hora de
afrontar una auditoría. Si el auditor las conoce previamente a iniciar el
trabajo podrá diseñar la acción de auditoría de acuerdo a ellas y evitar en-
contrar problemas durante la ejecución, algunas de ellas pueden ser:
– Marco temporal en el que se debe disponer de una auditoría realizada
por un tercero.
– Limitaciones financieras a la hora de dotar de recursos al proyecto de
auditoría.
– Limitaciones en cuanto a la dedicación de su propio personal a la rea-
lización de la auditoría.
– Limitaciones lógicas o físicas en la infraestructura que da soporte al
tratamiento de la información.
• Comprender�el�entorno�en�el�que�se�realizará�la�auditoría. Cuanto me-

jor sea la información relativa al entorno en el que se realizará la auditoría
mejor se podrá delimitar el alcance. Entre los aspectos del entorno que se
deben determinar se incluye:
– Ubicación en la que se realizará la auditoría.
– Número y ubicación de otros centros que deben ser visitados durante
la auditoría. De este aspecto derivará los requisitos de viajes y despla-
zamientos necesarios.
– Disponibilidad de documentación previa del auditado, como por
ejemplo diversas políticas de seguridad, diagramas de red, documentos
de diseño de aplicaciones, descripción de los distintos entornos ope-
rativos, inventarios de infraestructuras, etc.
– Disponibilidad del personal de la organización auditada.
Para que el equipo de auditoría evite errores en la determinación o manteni-

miento del alcance de la auditoría, es necesaria una buena comunicación en-
tre el equipo auditor y el auditado, por un lado, y también con el cliente de la
auditoría, que puede ser el mismo. Este intercambio tiene que darse tanto al
inicio como durante la ejecución. Mediante informaciones o informes preli-
minares, el auditor debe mantener informado tanto al auditado como al clien-
te de la auditoría de los progresos, y dar pie a que se renegocie el alcance. Por
supuesto, esta renegociación tendrá que tener en cuenta los recursos previstos
inicialmente para la auditoría, y ajustarse a ellos o bien dotar a la auditoría
de recursos adicionales.
2.3. Técnicas para determinar el alcance
La forma más sencilla de determinar el alcance de una auditoría es recurrir al

cliente de la auditoría y, en caso necesario, al propio auditado como fuente
de información más precisa. El proceso de determinación del alcance necesita
la interacción entre el auditor y el cliente de la auditoría principalmente. El
diagrama del proceso queda reflejado en la figura siguiente:
Proceso de determinación del alcance de una auditoría
Es recomendable que la entidad que vaya a ser la cliente de la auditoría (el

mismo auditado en caso de auditorías de primera parte) dé indicaciones ini-
ciales al equipo auditor de cuál ha de ser el alcance.
En los casos que se solicita una auditoría realizada por una entidad externa
más independiente y en que el auditado tiene el conocimiento y la concien-
ciación suficiente, en materia de gestión de la seguridad de la información, o
bien simplemente debido a la necesidad de cumplir con los procedimientos
internos para la contratación (a veces, impuesto por la implantación de un
sistema de gestión de la calidad), el auditado suele emitir un documento en
el que especifican las características del servicio que se desea contratar, en es-
te caso, una auditoría. Habitualmente, estos documentos suelen denominarse
"solicitud de servicio" (o en el ámbito anglosajón, request for proposal –RFP– o

también statement of work" –SOW–), o, por ejemplo, en el campo de la contra-
tación con las administraciones públicas en España, "pliego técnico".
Según quién haya redactado la RFP, el documento puede incluir un abanico

muy amplio de información acerca de las necesidades del auditado; el tipo y
alcance de la auditoría solicitada dependerá, en gran medida, de los conoci-
mientos técnicos y de la comprensión de los aspectos que involucran una au-
ditoría, o simplemente de la voluntad de detallar las intenciones del auditado.
En cualquier caso, si existe este documento, será la mejor fuente de informa-
ción para empezar a trabajar y determinar el alcance de la auditoría.
En el caso de que la auditoría se haga internamente, también será recomenda-

ble realizar la preparación de un documento aprobado por la dirección de la
entidad auditada y que refleje el alcance de la auditoría a realizar.
El siguiente paso podría valer en caso de no disponer de toda la información en

la RFP. También sería necesario, y constituiría directamente el primero en los
casos en que el cliente de la auditoría ni siquiera hubiera facilitado una RFP o
similar y, simplemente, hubiese transmitido al auditor su deseo de realizar una
auditoría sin dar muchas más indicaciones. De hecho, esta es una situación
muy corriente. En esta fase, se trataría de aclarar con el cliente de la auditoría
las dudas que existieran. El método más adecuado sería una entrevista con el
cliente de la auditoría o la/s persona/s asignada/s para la gestión del proyecto
con el objetivo de aclarar los siguientes puntos:
• Obtención por parte del auditado de información acerca del alcance. Si

la información está clasificada, será necesaria, previamente incluso a las
conversaciones para determinar el alcance, la firma de un documento en-
tre auditor y auditado de acuerdo de no divulgación de información con-
fidencial (en inglés non disclosure agreement - NDA, y en español habitual-
mente “acuerdo de confidencialidad”). Esta información puede incluir:
– Políticas de seguridad que afecten a las áreas que el auditado desea
revisar.
– Documentos técnicos que muestren a alto nivel el alcance de las in-

fraestructuras a revisar (diagramas de red, inventarios de sistemas, ar-
quitecturas de sistemas).
• Determinar las áreas de especial interés para el cliente de la auditoría.
• Averiguar motivaciones del cliente que llevan a la necesidad de realizar

una auditoría.
• Pactar el formato o tipo de auditoría a realizar: fases, técnicas a emplear,

y en especial los tipos de entregables que esperará recibir el cliente de la
auditoría.
• Determinar el modo en que se relacionará el equipo auditor con el audita-

do y el cliente de la auditoría para informar sobre el avance, los resultados
preliminares y la gestión del cambio del alcance durante la ejecución de
la auditoría.
Es importante el intercambio de ideas entre el auditado y el auditor para con-

sensuar la visión que ambos tengan sobre el trabajo a realizar. Para este obje-
tivo, suele ser práctico emplear cuestionarios de recogida de información. Sin
embargo, no se ha de dejar de tener en cuenta que una entrevista no debe
constituir un interrogatorio del auditado o un adelanto de cuestiones que son
objeto de la auditoría. Aunque se disponga de un cuestionario, el auditor debe
tener la suficiente experiencia para conversar con su interlocutor, obtener la
información prevista y, por medio de la conversación, aclarar cualquier duda
que pudiera plantearle la información obtenida.
Caso práctico
La infraestructura de una organización ha sufrido una fuerte evolución, y el anterior

responsable de los sistemas de información ha decidido abandonar la organización.
El nuevo director de sistemas de información ha planteado a la dirección la necesidad
de realizar una auditoría de seguridad, para conocer el punto en que se encuentran
las infraestructuras y en qué medida su operación puede impactar a la seguridad de
la información tratada por la organización. No se ha publicado ningún documento
a la hora de solicitar ofertas para realizar el servicio.
De unas primeras entrevistas no oficiales entre el director de sistemas y el jefe del

equipo auditor se determinó que, a priori, el alcance afectaría únicamente a la revi-
sión de las infraestructuras en una modalidad en la que el equipo auditor dispondría
de información previa sobre las mismas.
Sin embargo, el equipo auditor, de cara a planificar el esfuerzo y los recursos necesa-
rios para la asignación, necesita determinar mejor su conocimiento previo. De este
modo, se ha decidido solicitar una entrevista con el director de sistema, y se ha pre-
parado un documento cuestionario que deberá guiar la entrevista. La información
que se ha considerado relevante para poder determinar el alcance de la auditoría que
la organización necesita es:
• Quién o quiénes será/n la/s persona/s de contacto en el proyecto.
• Cuántas ubicaciones físicas de la organización contienen sistemas que se consi-

deren bajo el alcance de la auditoría.
• Dónde se encuentran ubicadas.
• Cuántos empleados se hallan en esas ubicaciones y cuántos realizan labores rela-

cionadas con la gestión de la infraestructura de los sistemas de información.
• Facilitar un esquema de la arquitectura de los sistemas de información y facilitar,

si es posible, un diagrama que lo muestre. Cuáles son los distintos protocolos
de comunicaciones empleados para interconectar los sistemas (únicamente hasta
capa 4).
• Cuántas estaciones de trabajo se estima que existen en cada ubicación. De qué

tipo de sistemas operativos disponen.
• Cuántos servidores se encuentran en cada ubicación. Qué tipo de sistema opera-

tivo tienen y qué tipo de servicios corren cada uno de ellos.
• Qué tipo de sistemas de seguridad perimetral lógica tienen (firewalls, proxys, IDS,
IPS, etc.).
• Qué tipo de servicios se ofrecen al exterior de la red corporativa. Desde qué sis-
temas se ofrece.
• Qué tipo de sistemas de comunicación existen para la interconexión de la red

corporativa con otras redes: concretamente, VPN, IPSec o SSL, accesos telefónicos,
conexiones punto o punto con terceras partes, etc.
• Qué mecanismos se emplean para la identificación, autenticación y autorización

de los accesos a la información realizados mediante infraestructuras.
• Qué infraestructuras de redes inalámbricas existen.
Por otra parte, el equipo auditor también deberá obtener como resultado de esta en-
trevista información sobre aspectos operativos que se realizarán durante la ejecución
de la auditoría, como por ejemplo:
• Fases en que se quiere desarrollar el estudio. El equipo auditor propondrá su me-

todología, que deberá ser aprobada por el cliente de la auditoría.
• Resultados parciales y/o preliminares que el cliente desea obtener.
• Forma y número de entregables.
• Forma de proceder, en caso de detectar graves problemas que el auditor considere

que afectan gravemente a la seguridad de la información.
Una vez realizada adecuadamente la recogida de información y analizada con-

juntamente con la RFP (si existe), el equipo auditor estará en disposición de
redactar el contrato de auditoría, si es una auditoría externa, o de establecer
los términos de asignación de auditoría, si es interna.
3. Enfoque del alcance de la auditoría técnica TIC
Ya hemos visto, en el punto anterior, que el factor más crítico para el éxito
de una auditoría será determinar su alcance y gestionar sus modificaciones
durante su ejecución. Será esta la característica que marca el tipo de auditoría
que se realizará. Por lo tanto, incluso para poder determinar correctamente
cuál es el alcance de la auditoría, es importante clarificar cómo se enfoca y
orienta dicha auditoría.
En el apartado anterior se trató de manera concreta las fases o los pasos que se
habían de seguir para pactar con el cliente de la auditoría. En este, se precisará
más concretamente qué aspectos es esencial definir en el alcance de una au-
ditoría dentro del contexto del ámbito de la gestión de seguridad de la infor-
mación en sistemas TIC. En este sentido, es importante pactar con el cliente
de la auditoría:
• Los aspectos técnicos dentro de la gestión de seguridad de la información

que se tratarán en la auditoría.
• El nivel de información previa de que dispondrá el equipo auditor antes

de realizar la auditoría, el cual veremos cómo afecta a la hora de enfocar
el trabajo de auditoría.
• El esfuerzo que el equipo auditor tendrá que planificar y cuantificar y el

modo en que igualmente impacta al final al determinar el alcance.
3.1. Aspectos técnicos del alcance
Como se ha comentado, una auditoría de seguridad de la información en TIC

tiene por objetivo la verificación de la correcta implantación de controles de
seguridad que una organización puede haber decidido implantar y por tanto
pueden existir en un gran abanico de áreas relacionadas con la gestión de los
sistemas de información. Las normas que definen catálogos de buenas prác-
ticas recogen todas las áreas relevantes para la seguridad de la información,
por lo que en este ámbito el alcance de una auditoría técnica de seguridad
puede dirigirse sobre cualquiera de las bases de los objetivos de control que
se puedes haber llegado a seleccionar. De este modo, desde un punto de vista
puramente técnico, el alcance de una auditoría de seguridad TIC podría reali-
zarse sobre cualquier conjunto de controles que tenga un sentido. Se podría
tomar como criterio de selección los distintos capítulos o áreas de interés de
cualquiera de los catálogos de controles existentes en el mercado, como por
ejemplo la norma ISO/IEC 27002, que tiene una orientación suficientemente

amplia para incluir todos los aspectos que son relevantes en la gestión de la
seguridad de la información TIC.
Norma ISO/IEC 27002
En el siguiente diagrama representamos los distintos capítulos de la Norma ISO/IEC

27002, que se pueden emplear como referencia a la hora de identificar desde el punto de
vista puramente técnico los aspectos del alcance que se pueden incluir.
Estructuración de los capítulos de la ISO/IEC 27002
En la actualidad existen diversas normas y códigos de buenas prácticas que Gestión de la continuidad
dan un marco sobre las mejores prácticas de la industria en relación con los
Desde la revisión de 2013, la
servicios de tecnologías de la información, como por ejemplo: ITIL, conjunto continuidad de negocio com-
de normas BS-15000 y su equivalente internacional ISO-20000, o el COBIT. pleta ya no está incluida co-
mo un control de seguridad de
Cualquiera de las distintas áreas descritas será susceptible de poder ser audi- la información, sino que solo
se tiene en cuenta la garantía
tadas, aunque algunas tendrán más implicación sobre la calidad del servicio de la seguridad de la informa-
ción durante la gestión de la
de TI ofrecido en la organización, otras sobre el valor que las TI aportan al continuidad de negocio. Existe
negocio y otras sobre la seguridad de la información. una norma propia para conti-
nuidad de negocio, la ISO/IEC
25999.
A continuación, presentamos distintas áreas de controles que podrían ser ob-
jeto de auditoría y estarían descritas en el alcance (solo se comentan el pun-
to de vista técnico específico de los controles que se van a auditar, ya hemos
comentado que para definir el alcance se deben tener en cuenta más elemen-
tos) que se pueden dar en un ambiente TIC y centrados en la seguridad de la
información. Como hemos mencionado, al ser un entorno muy amplio, este
listado no pretende ser exhaustivo ni excluyente entre ellos, pero sí al menos

relevante y acorde a lo que en la actualidad se viene realizando en el sector
de la seguridad informática.
3.1.1. Revisión del compromiso de la gobernanza de la seguridad

de la información
El objetivo de este tipo de auditoría sería comprobar el compromiso y la di-

rección o gobernanza de la dirección sobre la seguridad de la información me-
diante la revisión formal de todos los documentos que dan soporte a la segu-
ridad de la información en la organización en los distintos aspectos que son
de su responsabilidad, y el modo en que se realiza el gobierno, el control y la
mejora de la seguridad de la información. Se trataría de comprobar, por tanto,
cómo se encuentran implementadas las cláusulas de los apartados 4, 5, 6 y 9
de la norma ISO/IEC 27001 y el modo en que se implementan los controles de
los capítulos 4, 5, 6, 7 y 15 de la norma ISO/IEC 27002 (ved diagrama anterior
de capítulos de la norma), lo cual estaría muy alineado con lo que sería una
auditoría interna de verificación del SGSI (ved módulo 2 de este curso). Los
objetivos de dicha auditoría serían los siguientes:
• Revisión del mantenimiento del documento de política de seguridad y sus

posteriores revisiones y del resto de documentación que se derive de ella.
• Revisión de los análisis de riesgos realizados por la organización.
• Revisión de las reuniones periódicas de los comités, grupos de trabajo o
similares creados para dar soporte directivo a la seguridad.
• Revisión de la política de clasificación y tratamiento de la información, y
de su aplicación.
• Revisión de la política de gestión de los recursos humanos en sus aspectos
relacionados con la seguridad.
• Revisión de la gestión realizada con la subcontratación de servicios de TI,
incluido su control posterior a la contratación.
3.1.2. Revisión de la seguridad física
Esta auditoría tendría un carácter más técnico pero limitado a la revisión de Áreas de interés
los controles de seguridad física aplicados a las distintas áreas de interés en la
Hay diversas áreas de interés
gestión de la seguridad de la información. en la gestión de la seguridad
de la información: data cen-
ters, salas de comunicaciones,
Los aspectos que se han de examinar tienen que incluir revisiones de tipo téc- salas de operación, oficinas de
usuarios, etc.
nico acerca de cómo se han implementado los controles técnicos y revisiones
de los procedimientos aplicados para gestionar dichos controles y las políticas
que se hayan dictado para guiar la implantación. Estas revisiones enlazarían
con el resto de políticas y normas de la organización con el objetivo de cons-
tituir un sistema de gestión de la seguridad de la información coherente. Por
lo tanto los objetivos de una auditoría de este tipo serían:
• Revisión de la ubicación y las condiciones de construcción de las diversas

áreas seguras, desde la evaluación de la elección de la ubicación, a la de sus
características de construcción: existencia de vallas de seguridad, ventanas,
identificaciones externas, disposición y medidas de seguridad en las zonas
de carga y descarga, ubicación y medidas de seguridad en las salidas de
emergencia, etc.
• Revisión de los mecanismos de control de acceso físico y de los procedi-

mientos que los operan: cómo se entregan las credenciales de acceso, cómo
se emplean, cómo se gestionan la pérdida u olvido de las credenciales, etc.
• Revisión de las características de diseño de las distintas salas técnicas de-

pendiendo de su propósito: salas de comunicaciones, salas de servidores,
almacenes de soportes de backup, etc.
– Elección de materiales.
– Distribución del cableado por suelo técnico o por la parte alta de la

sala.
– Características de los "cabinets" de equipos (materiales, controles de

acceso físico a este nivel, conexión a tierra, etc.).
– Ubicación y medidas de seguridad de las entradas "oficiales" y de emer-

gencia.
• Revisión de la instalación eléctrica y de cableado para garantizar la com-

patibilidad electromagnética.
• Revisión de los controles de seguridad de las condiciones de entorno: su-

ministro eléctrico, control de temperatura y humedad, y mecanismos de
detección y extinción de incendios.
• Revisión de los procedimientos operativos aplicables a este tipo de insta-

laciones: normas de entrada/salida de equipos, normas de trabajo, proce-
dimientos de instalación/retirada de equipos, procedimientos de acceso a
las salas, etc.
Es muy interesante conocer que, al respecto de la seguridad física, existe una

tendencia actual a externalizar la gestión física de los equipos informáticos
servidores en grandes centros de procesado de datos (CPD o datacenters) para,
de este modo, ahorrar costes y conseguir niveles de protección que de modo
particular tendrían un costo muy elevado.
En este contexto, cada vez más, las grandes entidades que recurren a este ti-
po de servicio exigen la realización de auditorías de segunda parte contra la
seguridad física de los datacenters donde han externalizado servicios informá-
ticos críticos para el negocio. Como en cualquier otra auditoría, el auditor se

encuentra ante la necesidad de disponer de unos criterios de auditoría con-
tra los que contrastar las evidencias que recoja. El cliente de auditoría podría
haber elaborado unas normas físicas o bien haberlas establecido contractual-
mente en el contrato de externalización, pero no es lo más habitual en este
tipo de externalización. Sin embargo, el auditor dispone de una norma que es
interesante que conozca, la TIA-942 (telecommunications infrastructure standard
for data centres, www.tia-942.org). Existen otras normas referentes a este tema,
como por ejemplo la EN-50600. Esta norma es la primera norma internacional
aplicable especialmente en Europa que da especificaciones completas para el
diseño, construcción y operación de un centro de datos con un enfoque que
integra todos los aspectos. Define los requisitos tanto de criterios de construc-
ción, alimentación eléctrica, aire acondicionado, cableado, sistemas de segu-
ridad y especifica también los criterios para el funcionamiento de los centros
de datos. La EN-50600, creada por la organización europea de normalización
CENELEC (European Committee for Electrotechnical Standardization), está basada
fundamentalmente en la anteriormente comentada TIA-942, en la que nos
centraremos más adelante.
Esta norma realizada por la TIA (Teleccomunications Industry Association),

facilita estándares para el diseño de centros de procesado de datos en todos sus
aspectos o subsistemas funcionales (que también se encuentran enumerados
y estandarizados):
• Sistema arquitectural. Condiciones constructivas y de ubicación del propio

edificio, así como de distribución y acceso a sus distintas estancias.
• Sistemas de telecomunicaciones. Incluye cableado estructurado interno de

datos y el acceso de proveedores de telecomunicaciones.
• Sistema eléctrico. Desde la llegada del proveedor hasta la distribución final

en los racks.
• Sistema mecánico. Aspectos relacionados con el mantenimiento de las

condiciones medioambientales y, en general, de suministros diferentes a
los eléctricos: agua, gas, gasóleo, etc.
• No hay un punto específico sobre seguridad porque en realidad toda la

norma en sí está orientada a dar seguridad a los datacenter.
Lo más interesante para el auditor de seguridad es que esta norma es certifica-

ble y, aunque él no vaya a realizar una auditoría de certificación, sí que le faci-
lita un marco para evaluar los centros actuales contra las especificaciones que
se dan la norma y el nivel de disponibilidad que ofrecen. El estándar define
una clasificación para los centros de datos (desde Tier-1 hasta Tier-4 para los
que dan la mayor seguridad). Cada uno de ellos se corresponde con un nivel
distinto de disponibilidad que ofrece por sus características:
Nivel Disponibilidad Características
Tier�1 99,671% Datacenter�básico

(28,8 h/año de indisponibilidad) • Susceptible a interrupciones tanto planificadas como no.
• Los sistemas de suministro y comunicaciones no disponen de ningún tipo de
redundancia y/o existen varios puntos únicos de fallo.
• Las operaciones de mantenimiento o errores requieren la puesta en fuera de
servicio de la instalación.
Tier�2 99,741% Datacenter�con�componentes�redundados

(22 h/año de indisponibilidad) • Menos susceptibles a interrupciones que un Tier 1, tanto planificadas como no.
• Los sistemas de suministro y comunicaciones disponen de elementos de res-
paldo (por ejemplo, redundancia o sistemas de respaldo alternativos), pero es-
tán conectados a una sola línea de distribución activa.
• Existe redundancia N+1 (los necesarios más uno) para los componentes de la
infraestructura.
• Las operaciones de mantenimiento o errores requieren la puesta en fuera de
servicio de la instalación.
Tier�3 99,982% Datacenter�con�mantenimiento�concurrente

(1,6 h/año de indisponibilidad) • Permiten realizar cualquier actividad planeada sobre cualquier componente de
la infraestructura sin interrupciones en la operación.
• Doble línea de distribución de los componentes, aunque sólo una activa en un
momento determinado.
• Capacidad suficiente de forma tal que sea posible realizar mantenimiento o
pruebas en una línea, aunque eventos no planificados (errores o fallos espon-
táneos) pueden provocar interrupciones del servicio por falta de capacidad.
Tier�4 99,995% Datacenter�con�tolerancia�a�fallos

(0,4 h/año de indisponibilidad) • Permiten realizar cualquier actividad planeada sobre cualquier componente de
la infraestructura, o sufrir eventos no planificados (errores o fallos) sin interrup-
ciones de ningún tipo.
• Múltiples líneas de distribución para los componentes de la infraestructura ac-
tiva, todas ellas.
Redundancia completa 2(N+1) (todo duplicado y con elementos de reserva adi-
cionales).
Niveles de disponibilidad según TIA/EIA 942
Esta clasificación es aplicable a los distintos subsistemas de un CPD que el es-

tándar define; se recogen en uno de sus anexos (anexo G) todos los requeri-
mientos que cada subsistema debe cumplir para cada uno de los niveles. Cabe
destacar que también se dan indicaciones que inciden sobre la clasificación de
un CPD pero que no están estrictamente ligadas al concepto de disponibilidad,
como por ejemplo los controles de acceso y de monitorización. El estándar
establece los distintos requerimientos en esta área para los distintos niveles,
aunque no inciden directamente sobre la disponibilidad (limitan la posibili-
dad de que un atacante externo puede provocar un incidente que afecte a la
disponibilidad). El auditor determinará el nivel (tier) resultante de un deter-
minado CPD, realizando el análisis del nivel de disponibilidad de cada uno de
los componentes y tomando el menor de todos ellos.
El auditor puede, por tanto, realizar una auditoría para comprobar el nivel
que le corresponde a la instalación y confrontarlo, después, con el cliente de
auditoría, quien tendrá que determinar si es adecuado para sus intereses.
3.1.3. Revisión de la seguridad perimetral de las redes de

comunicaciones
En muchos entornos, cuando se habla de auditorías de seguridad se piensa sólo

en auditorías que revisen la eficacia de los controles de seguridad implantados
en las redes de comunicaciones. Es cierto que son uno de los tipos de audito-
rías más solicitados en el mercado –y destacan por ello–, pero como estamos
viendo a lo largo de todo este curso, la auditoría de seguridad de las TIC puede
comportar más cosas.
Este tipo de auditorías se centrarán en evaluar la seguridad perimetral de las

distintas subredes corporativas, con un especial interés en el perímetro exte-
rior. Se tratará de una manera más general de la revisión de la seguridad ofre-
cida a la información cuando se transmite por las redes de comunicaciones de
la organización, tanto en su perímetro (conexiones a Internet, interconexio-
nes con redes de otras organizaciones, etc.) como en su organización interna
(segmentación de la red, interconexiones de LAN corporativas, etc.). Por tan-
to, esta auditoría tendrá una orientación muy técnica, aunque puede incluir
aspectos de gestión de algún tema muy concreto que afecte a la seguridad de
las comunicaciones, por ejemplo, la revisión de los procedimientos que invo-
lucren la gestión de accesos remotos (autorización, concesión, auditoría de ac-
cesos remotos, etc.). Los objetivos específicos de este tipo de auditoría serían
(sin ser exhaustivos):
• Determinar la correcta implantación de controles de filtrado de tráfico me-

diante enumeraciones de redes y comprobación de la capacidad de filtrado
implementada en los cortafuegos corporativos.
• Revisar la seguridad en los accesos remotos a las redes corporativas según

las diferentes tecnologías existentes.
• Identificar el nivel de vulnerabilidad de los sistemas de comunicaciones

y demás servicios presentes en las redes corporativas para comprobar la
eficacia de la política de mantenimiento y su puesta en práctica por la
organización.
• Evaluar la implantación de las redes inalámbricas para el acceso a la red

corporativa.
• Evaluar la seguridad de aplicaciones expuestas en Internet o bien en redes

de terceros con el fin de detectar vulnerabilidades, problemas o errores de
configuración.
Habitualmente, dentro de este tipo de auditorías se incluirán las conocidas au-

ditorías de análisis de vulnerabilidades, o pruebas de intrusiones o cualquiera
de sus variaciones que veremos más adelante.
3.1.4. Revisión de los mecanismos de control de seguridad en

sistemas operativos y aplicaciones
Este tipo de auditorías también ha estado tradicionalmente ligado a la idea

general que se tiene sobre qué es un auditoría técnica de seguridad. Estas au-
ditorías de seguridad para la verificación de los controles de acceso a la infor-
mación tratarán, principalmente, de verificar la seguridad en el nivel de apli-
cación, aunque también revisarán su implementación en otros puntos de la
arquitectura de sistemas como, por ejemplo, en el acceso al sistema operativo
o en el acceso a recursos de información en la red.
Desde el punto de vista técnico, los mecanismos de control de acceso lógico

a la información se pueden aplicar tanto en el acceso del usuario a recursos
de red como al sistema operativo del dispositivo que emplea el usuario, así
como en las propias aplicaciones de tratamiento de la información; por lo
que, si se trata de verificar qué controles se aplican para limitar el acceso a
la información, la auditoría ha de identificar todos los puntos de acceso a la
misma y todos los elementos que se encuentren interviniendo a la hora de
limitar su uso.
Asimismo, en la propia lógica de las aplicaciones de tratamiento también se

aplican controles de acceso que implementan la política de la organización
en cuanto a los derechos de acceso concedidos a los usuarios ya autenticados
(como por ejemplo la aplicación de roles de usuarios que otorgan distintos
niveles de privilegios tanto de visibilidad de información como de capacidad
de tratarla). Por lo tanto, este tipo de auditorías también comprobarán si las
aplicaciones implementan correctamente la lógica de negocio y los controles
de aplicación que se hayan determinado para evitar el uso fraudulento de las
mismas. Esto es especialmente relevante en entornos de negocio sensibles co-
mo podría ser el bancario.
Por otra parte, junto con la parte técnica de los controles también se encuen-
tran involucrados los procedimientos que son necesarios para gestionar estos
procesos. Por lo que el auditor deberá comprobar las características de los pro-
cedimientos de gestión de los derechos de acceso (solicitud, autorización, con-
cesión, revocación, auditoría/monitorización, etc.) y cómo son ejecutados por
la organización.
Por lo tanto, este tipo de auditoría podrá incluir tanto aspectos técnicos co-
mo organizativos, pero suele ser más habitual concentrarse en las revisiones
de las características técnicas de estos controles en el marco de una auditoría
técnica de seguridad que tendría un alcance superior al que estamos comen-
tando ahora mismo. Este tipo de auditoría, eminentemente técnica, incluirá
una revisión de la seguridad perimetral de las redes de comunicaciones como
hemos visto en el apartado anterior, y también de los controles de seguridad
aplicados en las aplicaciones de tratamiento.
Por último, es interesante notar que existen dos posibles visiones para el di-
seño de auditorías técnicas de este tipo. El auditor puede realizar una evalua-
ción de los controles técnicos desde el punto de vista de un usuario, inten-
tando evadir los controles existentes; o bien puede tomarse el punto de vista
del administrador del sistema y verificar la configuración para comprobar si
todos los controles que permite el sistema están debidamente configurados.
El primer caso está indicado para identificar problemas que no deriven de una
mala configuración, sino de un error intrínseco en el sistema (ya sea una vul-
nerabilidad de sistema operativo o de aplicación). El segundo enfoque se suele
realizar debido a que en muchas ocasiones las vulnerabilidades son introdu-
cidas por errores de configuración o pueden ser mitigadas mediante la aplica-
ción de una determinada configuración. Esto es especialmente relevante en
entornos de computación o de aplicaciones en la nube en cualquiera de las
modalidades conocidas como IaaS (Infrastructure as a Service), PaaS (Platform
as a Service) o SaaS (Software as a Service). En el segundo tipo de enfoque, se
requiere por parte del auditor un conocimiento previo sobre el cual debe ser
la configuración correcta. Esto puede venir ya sea por criterios preestablecidos
por la organización en normas propias de configuración segura de sistemas, o
bien se pueden tomar como referencias guías públicas o particulares del mis-
mo auditor. En ocasiones, este tipo de auditorías son conocidas como audito-
rías de cumplimiento.
3.1.5. Revisión de la gestión del ciclo de vida de los sistemas
Cuando una organización afronta el desarrollo o adquisición de un sistema

de información, en seguida surge la tentación de obviar las diversas fases que
componen el ciclo de vida del desarrollo de sistema (en inglés system develop-
ment life cycle, SDLC).
Existen diversas representaciones o denominaciones de las fases que compo-

nen este SDLC, pero de manera general podemos reflejar el SDLC completo
de la siguiente manera:
Ciclo de vida de un sistema de información
Hay varias razones que llevan a una organización a no cumplir con este mo-
delo. Habitualmente se trata de razones económicas junto con planificaciones
temporales muy ajustadas. Sin embargo, la omisión de alguna de estas fases
puede suponer un riesgo tanto para la información que estos sistemas vayan a
tratar, como sobre el supuesto valor que aportarían a la organización. En este
contexto, es posible que se pida al equipo auditor la revisión de la ejecución
del ciclo de vida del desarrollo de algún tipo de sistema.
Por otra parte, el auditor también puede estar involucrado en el propio ciclo
de vida. Debemos recordar que, en las fases de definición de requerimientos,
tanto de negocio como de usuario, se deben recoger las necesidades de seguri-
dad que vaya a tener el sistema. Los diseños e implementaciones han de con-
siderar estos requerimientos, e implementar internamente los controles que
sean necesarios y especificar los que, en el momento del despliegue, tengan
que proveer otras infraestructuras TIC del entorno en que se integre el nuevo
sistema. El auditor puede participar en todo este proceso de incrustar la seguri-
dad en el propio proceso de desarrollo en lugar de proporcionarlo a posteriori.
Se puede requerir a un auditor que ejecute pruebas para comprobar la imple-
mentación de los diseños que cumplen con los requerimientos de seguridad.
En estos casos, participará en las funciones de pruebas a partir de la fase de
pruebas de integración de sistemas y podrá llegar hasta la fase final de pruebas
de aceptación.
Por otro lado, es conveniente reconocer que, en los últimos tiempos, el proce-
so de desarrollo de software ha evolucionado y ya no siempre se aplica el tra-
dicional modelo SDLC en cascada visto anteriormente. Sin embargo, existen
otros modelos conocidos como "metodologías ágiles de desarrollo" que funda-

mentalmente buscan reducir las iteraciones entre recogida de requerimientos
y entrega de producto, con el fin de conseguir una colaboración más estrecha
y flexible entre los equipos de desarrollo y los clientes o usuarios del produc-
to final. Existen múltiples metodologías, como SCRUMM, XP - Extreme Pro-
gramming, Kanban y otras. En algunas organizaciones complementan el uso
de estas técnicas de gestión de proyectos con estrategias de despliegue de soft-
ware también más ágiles conocidas como CI/CD (Continuous Integration /
Continous Delivery o Deployment) que permiten automatizar los procesos de
pruebas, integración y finalmente puesta en producción. La combinación de
ambas lleva a la aplicación de técnicas conocidas como “DevOps” en las que
las actividades de desarrollo y de operación de IT están íntimamente ligadas,
de manera que los desarrolladores pueden entregar su código, realizarse de
manera automática determinados controles sobre el mismo y en caso satisfac-
torio también de modo automatizado realizarse el despliegue en la infraestruc-
tura. Este tipo de prácticas permiten a los equipos realizar puestas en produc-
ción de manera muy ágil y rápida sin por ello perder calidad. Por supuesto,
para alcanzar los máximos niveles de automatización y garantía de calidad, es
necesario que la organización que implementa el DevOps tenga una cultura
adecuada, emplee técnicas de gestión de proyectos ágiles, y que la arquitectura
de sus sistemas y de su software esté debidamente adaptado para ello.
Todas estas técnicas de gestión ágil, CI/CD o DevOps han estado orientadas,
principalmente, a la satisfacción del usuario y poco o no prioritariamente a
garantizar la seguridad (tanto de la información como del proceso), por lo que
no se utilizan ampliamente en entornos muy regulados donde la seguridad fí-
sica (en inglés, safety) o la confianza en el resultado es crucial, como por ejem-
plo en sectores críticos como el industrial, nuclear, financiero, instrumental
médico, etc. Sin embargo, día a día, se van introduciendo, con el riesgo que
ello conlleva, en gran número de organizaciones especialmente aquellas que
orientan sus servicios hacia Internet (portales de contenido, servicios ofreci-
dos “en la nube”, marketplaces en Internet, etc.).
Debido a este dinamismo y esta rapidez en la entrega, el software es propenso a

la introducción de errores, pero también permite detectarlos y aplicar correc-
ciones antes. Respecto a la seguridad de la información que tratan, esta situa-
ción es problemática. Cuando se emplea este tipo de metodologías, es esencial
insertar la seguridad en el propio proceso. Para ello se debería tener en cuenta
aspectos como los siguientes:
• En esta situación es importante que exista un análisis de riesgos del pro-

ceso que la aplicación implemente y que además vaya evolucionando a
medida que el propio producto lo haga. De este modo, se podrá valorar
tanto la necesidad de una determinada frecuencia de auditoría como la
priorización de la resolución de los problemas detectados frente a la con-
tinua incorporación de nuevas funcionalidades.
• De un modo u otro, en algún momento se debe planear una revisión de

seguridad o auditoría técnica que identifique problemas en el control de
la información tratada. Aunque estas metodologías se basen en ciclos de
desarrollo muy cortos, puede existir una planificación de más alto nivel
que contemple entregas más generales. Estas auditorías de seguridad de-
ben alinearse lo máximo posible tanto con los ciclos cortos como con las
entregas de alto nivel. Por tanto, las implicaciones más determinantes res-
pecto a las tradicionales auditorías de seguridad radican en que tendrán un
alcance más reducido y una frecuencia de las mismas mayor cuanto más
alineadas estén con los ciclos cortos de entrega. Esta alineación con los ci-
clos de entrega puede llevarse al extremo y hacerse algún tipo de chequeo
o prueba de auditoría en cada una de las puestas en producción. Esto es
especialmente relevante en entornos que hayan implantado prácticas de
CI/CD en las que se pueden automatizar pruebas que busquen problemas
potenciales de seguridad. De este modo, las pruebas insertadas en el llama-
do “pipeline” de entrega o de despliegue pueden interrumpirse si alguna
prueba de seguridad falla. De esta manera, el desarrollador que entregó un
determinado cambio y lanzó el pipeline deberá corregir el error. De todos
modos, esto no excluye la necesidad de auditorías completas con una cier-
ta periodicidad que actuarían a modo de evaluación global que garantice
que problemas anteriormente resueltos no hayan sido reintroducidos o se
expresen de una manera distinta.
• Los resultados de estas auditorías tienen que ser incorporados en el propio

proceso de desarrollo y priorizados correctamente por el responsable del
producto. Este tiene que ser muy consciente del valor de la información
y de los riesgos que los problemas detectados implican. Es decir, estos res-
ponsables de producto deben ser conscientes de que el uso de estas prácti-
cas que agilizan la entrega de funcionalidad en el producto final no deben
ir en detrimento de la seguridad, y que deben asegurarse de que existan
los controles insertados en el mismo proceso ágil de desarrollo, así como
posiblemente revisiones periódicas sobre un periodo más amplio.
• Los propios desarrolladores deben ser capaces de producir software sin

errores de seguridad empleando herramientas que analicen el código antes
de su entrega y corrigiéndolos en la propia iteración. Al estar estas herra-
mientas insertadas en el entorno de desarrollo permiten al desarrollador
disponer de la información lo antes posible y corregir los problemas casi
en el momento en el que él introdujo el error.
En cualquier caso, la introducción de metodologías de desarrollo ágil implica

un desafío muy elevado para la seguridad, y tanto responsables de producto
como auditores deben ser conscientes de ello y llegar a un acuerdo en que la
seguridad se inserte correctamente en el propio proceso.
3.1.6. Revisión de los planes de continuidad de negocio
Otro de los aspectos que son susceptibles de requerir una auditoría es la ges-
tión de la continuidad de negocio. A medida que las TI han adquirido mayor
peso en los procesos de negocio de las organizaciones, la capacidad operativa
y la supervivencia de una organización están ligadas de un modo u otro a la
continuidad de los servicios de TI.
En este sentido, las organizaciones suelen requerir que se realicen auditorías

de sus procesos de continuidad de negocio para que una organización externa
evalúe sus planes de continuidad de negocio y determine si garantizan adecua-
damente la supervivencia de la organización en caso de contingencia grave.
Por lo tanto se tratará de evaluar de qué modo se ha establecido el estudio del

análisis de impacto sobre el negocio (en ingles business impact analysis, BIA),
cómo se han determinado los parámetros de RPO y el RTO para cada uno de
los procesos de negocio, la estrategia de respaldo determinada y posteriormen-
te se revisará la implantación de los planes de continuidad que se hubieran
derivado del anterior estudio.
En el siguiente diagrama, recordamos los conceptos de RPO (recovery point ob-

jective) y RTO (recovery time objective), que son los dos parámetros básicos que
definen la estrategia de continuidad de negocio que debe abordar una entidad.
Parámetros RPO y RTO de un Plan de Continuidad de negocio
Este tipo de revisiones requerirá, por lo tanto, combinar pruebas técnicas –que
determinen de qué modo se ha previsto el respaldo de los sistemas de infor-
mación– con pruebas no técnicas –entrevistas, visitas, estudio de documenta-
ción– para completar la revisión del modo en que la organización gestiona la
continuidad.
3.1.7. Revisión de la capacidad de respuesta ante incidentes
Otro de los pilares de la gestión de la seguridad que mantiene preparada a la

organización en las situaciones de emergencia es el modo en que se gestionan
o se responde ante los incidentes de seguridad. Junto con la gestión de la con-
tinuidad de negocio, la gestión de incidentes forma el frente de respuesta ante
situaciones imprevistas que quedan fuera de la capacidad de los controles de
seguridad implantados, ya sea por su mal funcionamiento o porque simple-
mente no están preparados para proteger contra todo tipo de situaciones de
riesgo. El auditor puede ser también requerido para que realice una evaluación
de los procesos que la organización haya puesto en marcha para gestionar este
tipo de situaciones. Las técnicas que emplearía diferirán de las que tratamos
generalmente en este módulo, puesto que trabajaría más con simulaciones.
El auditor podría comprobar la efectividad de estos procesos poniéndolos a
prueba en situaciones simuladas. Estas técnicas quedan ligeramente fuera del
alcance de este curso, pero es interesante conocer que esta también es un área
en que puede participar un auditor de seguridad.
3.2. Impacto del conocimiento previo en el alcance de la

auditoría
En el apartado anterior se han presentado distintas maneras de orientar una

auditoría de seguridad según cual es el proceso cuyo control se quiere auditar.
En este siguiente apartado, se tratará de qué modo condiciona a una auditoría
de seguridad el conocimiento previo que se le facilite al auditor y en cierta
medida también al auditado. Tanto si es una auditoría puramente técnica co-
mo si es una auditoría sobre algún otro aspecto, según el conocimiento previo
que se tenga del entorno y la infraestructura que se ha de auditar, tendrá un
claro impacto sobre cómo determinar el alcance y los objetivos de la auditoría.
La clasificación que se va a presentar tiene especial sentido en el caso de au-

ditorías puramente técnicas; en el resto, habitualmente se tratará siempre de
auditorías en las que el equipo auditor tiene que disponer de un conocimiento
previo elevado. En ciertas asignaciones de auditoría, carece de sentido que el
auditor no disponga de cierta información sobre el entorno a auditar, resul-
tándole imposible alcanzar los objetivos de auditoría.
En las auditorías puramente técnicas (por ejemplo, revisiones de seguridad pe-

rimetral en la red, revisión de controles de acceso lógico o físicos), es legítimo
que el cliente de auditoría quiera obtener, como resultado de la misma, una
evaluación práctica de la seguridad de sus sistemas de información cuando se
han de enfrentar a una situación de riesgo real mediante la confrontación de
los controles implantados contra una amenaza simulada. Por lo tanto, querrá
comprobar cómo se comportan sus mecanismos de control en una hipotéti-
ca situación de riesgo. En estos casos, se solicita al equipo auditor que realice
una auditoría en la que se le facilitará la menor cantidad de información po-
sible, con el fin de que se simule una situación real en la que los sistemas de
información se tienen que enfrentar a un agente externo que desea acceder a

información de la organización. A este tipo de auditoría se la suele denominar
de caja negra (black box), puesto que para el equipo auditor el sistema es una
caja negra en la que, únicamente, se puede examinar dadas unas determinadas
entradas que salidas produce el sistema.
Las dos situaciones anteriormente descritas son los dos extremos que se pue-
den dar. Fijándonos en el grado de conocimiento que se tiene de las infraes-
tructuras a revisar, también se pueden clasificar las auditorías en:
• White�box. El equipo auditor dispone, o puede disponer si lo solicita, de

todo el conocimiento (o gran parte de él) sobre las infraestructuras o pro-
cesos a auditar. No existen limitaciones al respecto de la información a
la que puede tener acceso (no más allá, claro está, de lo que determinen
los acuerdos de confidencialidad) y el resultado de la auditoría depende,
exclusivamente, de la capacidad del auditor para analizar la información
recopilada. El valor añadido de la auditoría viene de este análisis, no del
proceso de recopilar la información.
• Black� box. Con el fin de simular lo mejor posible un escenario real, el

equipo auditor no dispondrá de ninguna información sobre los sistemas
de información que no sea información pública o información que pueda
ir extrayendo en base a las distintas pruebas que se vayan desarrollando. El
proceso de recopilación de la información constituye una parte del valor
que la auditoría aportará al cliente.
Limitaciones de las auditorías black box
Un black box 100% auténtico presenta muchas limitaciones. La principal es tener la cer-
teza de que la auditoría haya examinado o puesto a prueba todos los mecanismos de
control o haya detectado todos los problemas potenciales. En la práctica, este tipo de
auditoría tiene un alcance muy determinado y reducido a determinar de manera general
si en un momento dado, los sistemas de información son o no vulnerables a un agente
externo. En este caso nos encontramos con lo que se denomina una prueba de intrusión
o pen-test. En este tipo de auditoría se prima la efectividad frente a la exhaustividad, y lo
que se pide al equipo auditor es que obtenga pruebas de que la intrusión en los sistemas
de información es posible. En estos casos, como parte de la determinación del alcance,
el equipo auditor y el auditado deberán pactar las características que deberán tener las
evidencias de la intrusión.
Otra de las limitaciones de este tipo de auditorías es su elevado coste, tanto por el tiempo
necesario como por los grandes conocimientos que exige al equipo auditor. Para final-
mente conseguir resultados, es necesario invertir mucho en ambos aspectos. En determi-
nados tipos de auditoría técnica de seguridad, y con el fin de optimizar más el tiempo
dedicado por los expertos del equipo auditor, es factible que se facilite cierta informa-
ción, como por ejemplo direcciones IP, nombres de dominios y de servidores, e incluso
en ocasiones credenciales para acceder con un determinado nivel de privilegios. Esto nos
conduce al siguiente tipo que se describe a continuación.
• Grey�box. Se sitúa a medio camino entre los dos tipos de auditoría anterior.
En la práctica supone la mayor parte de las auditorías realizadas. Se com-
binan análisis realizados en modo black box, que pueden ser corroborados
por el auditado y posteriormente se continúa la evaluación en las áreas

que hubieran quedado fuera de las pruebas black box. El equipo auditor va
adquiriendo parte del conocimiento.
A este respecto merece la pena mencionar la metodología OSSTMM. Es intere- Ved también
sante comprobar cómo la OSSTMM clasifica las auditorías empleando esta idea
La metodología OSSTM será
pero ampliándola y, por lo tanto, aplicándola también al conocimiento que tratada en el módulo 4.
tiene el personal responsable de la operación y mantenimiento de las infraes-
tructuras auditadas.
En este sentido no se ha de olvidar que la OSSTMM es una metodología muy

orientada a auditoría desde el punto de vista externo de la organización y, por
lo tanto, su clasificación debe entenderse como una clasificación de auditorías
de tipo técnico de evaluación de las medidas de seguridad de los sistemas de
información expuestos en redes públicas. Y, por otro lado, la OSSTMM es una
metodología conocida pero es habitual aplicarla directamente, por lo que la
clasificación que se presentará a continuación es muy interesante para mostrar
los distintos matices y el modo en que influye el conocimiento previo tanto de
auditor como de auditado en aspectos muy sustanciales de una auditoría como
pueden ser sus características, así como el coste que puede implicar (como se
mostrará en el siguiente apartado).
Esta metodología realiza una clasificación de las auditorías en las siguientes

categorías:
Clasificación auditoría en base al conocimiento. Fuente: OSSTMM
1)�Blind. El auditor inicia la auditoría sin un conocimiento previo de los con-

troles existentes, de la arquitectura de los sistemas, de los activos de informa-
ción o de los distintos canales disponibles para acceder a la información. Sin
embargo, los sistemas de información evaluados son preparados con anterio-
ridad por el auditado con el conocimiento del tipo de pruebas que el auditor
realizará.
Este tipo de pruebas son empleadas habitualmente tanto para examinar las
capacidades de un auditor, como para evaluar la robustez de unas infraestruc-
turas con posterioridad a la implantación de algún tipo de mecanismo de con-
trol y que el auditado desea poner a prueba.
2)�Double�blind. Este tipo se corresponde exactamente con el modo black box

mencionado anteriormente. El auditor inicia la auditoría sin un conocimien-
to previo de los controles existentes, de la arquitectura de los sistemas, de los
activos de información o de los distintos canales disponibles para acceder a
la información. Los sistemas de información auditados no son preparados es-
pecíficamente para la auditoría, y el personal a cargo de su operación y man-
tenimiento no es advertido con anterioridad a la auditoría. Habitualmente,
únicamente el personal en el nivel de gestión es conocedor de las actividades
que el equipo auditor está desarrollando.
El principal objetivo de este tipo de auditorías es la comprobación lo más real

posible del modo en que tanto la organización como los sistemas de informa-
ción responderían a un intento de ataque por parte de un intruso (recordemos
que el Institute for Security and Open Methodologies, ISECOM, afronta la au-
ditoría como la evaluación desde el exterior). Como objetivo adicional de este
tipo de auditorías se obtiene también una evaluación de los controles de de-
tección que se hayan implantado. Por otra parte, se tiene que destacar que, por
lo limitado del conocimiento del auditor, no se puede pretender una evalua-
ción en un entorno real de cada una de las medidas de seguridad implantadas
y que, por lo tanto, las pruebas buscarán la consecución de la vulneración de
alguno de los aspectos de seguridad (confidencialidad, integridad o disponibi-
lidad) de la información manejada por la organización mediante la búsqueda
y posterior explotación de cualquier tipo de debilidad o vulnerabilidad en las
infraestructuras auditadas.
3)�Grey�box. El auditor inicia la auditoría con un conocimiento previo parcial

de los controles existentes, de la arquitectura de los sistemas, de los activos de
información o de los distintos canales disponibles para acceder a la informa-
ción. Por su parte, los sistemas de información auditados se encuentran pre-
parados y el personal de operación y mantenimiento advertido del detalle de
las actividades que se van a realizar.
La naturaleza y objetivos de este tipo de pruebas es comprobar la eficiencia

de los controles implantados ante una situación lo más cercana a la realidad
en la que un atacante externo no dispone de información a priori de las infra-
estructuras. Sin embargo, para disponer de un resultado más exhaustivo que,
en el caso de una auditoría de tipo blind, se facilita información adicional al
auditor para concentrar las actividades en las áreas de especial interés.
4)�Double�grey�box. El ISECOM identifica a este tipo de auditorías como au-

ditorías de caja blanca (white box), aunque se puede discutir mucho sobre lo
apropiado de denominarlas así.
En la double grey box, el auditor inicia la auditoría con un conocimiento previo

parcial de los controles existentes, de la arquitectura de los sistemas, de los
activos de información o de los distintos canales disponibles para acceder a
la información. Por parte del auditado, el personal de operaciones y mante-
nimiento se encuentra advertido del marco temporal en que se realizarán las
pruebas, aunque sin el conocimiento exacto de las técnicas que se emplearán,
de modo que los sistemas no se encuentran específicamente preparados para
las pruebas. Este tipo de auditorías comprueban tanto las capacidades técnicas
del auditor como la eficacia de los controles de detección del auditado.
Tanto en este caso como en las auditorías de tipo grey box, en la fase inicial el
auditor y el auditado intercambiarán información acerca de las características
técnicas de las infraestructuras probadas; además, durante el desarrollo de las
pruebas, se podrá ir mejorando el grado de conocimiento que el auditor tenga
sobre los sistemas auditados, tanto por información inferida de las pruebas
como por información adicional proporcionada por el auditado.
Los objetivos de este tipo de pruebas son similares a los obtenidos con una
auditoría de tipo grey box con el valor añadido de que también se podrá com-
probar la eficacia de los controles de detección.
5)�Tandem. Este tipo de auditorías es denominado por ISECOM como crystal

box, puesto que se corresponde con aquellas auditorías en las que tanto el au-
ditor como el auditado disponen de toda la información acerca de la infraes-
tructura que se debe auditar y en gran número de ocasiones las pruebas son
realizadas conjuntamente o de manera coordinada según un plan de auditoría.
El objetivo de la auditoría será la evaluación exhaustiva de los controles de

seguridad en alguna de las áreas, aunque obviamente no podrá evaluar com-
pletamente los controles de detección y aún menos los procesos de la organi-
zación para gestionar las incidencias.
6)�Reversal. Este tipo de pruebas de auditoría tiene como objetivo principal

comprobar la preparación de la organización a la hora de gestionar las inci-
dencias de seguridad, puesto que la organización auditada no conoce nada so-
bre el desarrollo de las pruebas (al menos sus niveles más operativos), mientras
que el auditor dispone de toda la información que el auditor le haya facilitado.
Esta clasificación debe ser utilizada por el equipo auditor para determinar qué
enfoque de auditoría se ha de tomar teniendo en consideración el alcance de la
auditoría y los objetivos que deberá cumplir de cara a satisfacer las expectativas
del auditado.
3.3. Impacto del esfuerzo en el alcance
Hemos visto que el alcance de las auditorías está afectado por los aspectos pu-
ramente técnicos que se han de revisar y también por el nivel de conocimiento
previo de que se dispondrá, así como, en cierta medida, por los matices res-
pecto al objetivo de la auditoría que tenga el cliente.
De cada combinación de tipos de auditoría que hemos repasado tenemos un

amplio abanico de los distintos tipos de trabajos que un auditor de seguridad
de la información puede llegar a realizar. Cada una de estas asignaciones de
auditorías tiene un coste que la entidad auditora debe conocer, prever y es-
tar dispuesta a asumir. Por tanto, el esfuerzo (costo en tiempo necesario y re-
cursos técnicos y humanos necesarios) es el otro gran parámetro por el que
se pueden clasificar las auditorías. Los dos primeros criterios de clasificación
nos servirán para determinar mejor el alcance y objetivo de la auditoría y, por
último, los recursos disponibles de auditoría (evaluados en personas, conoci-
mientos y tiempo) nos determinarán las técnicas a aplicar. De todos modos, la
entidad auditora debe ser capaz de realizar este ejercicio de comparar alcance
y recursos que se pueden movilizar para poder determinar si se encuentra en
disposición de alcanzar los objetivos de auditoría que se han pactado con el
cliente. Ya hemos dicho que este es uno de los factores críticos para el éxito
de la auditoría, y también podemos afirmar que es uno de los más afectados

cuando se realizan cambios no gestionados en el alcance de la auditoría. To-
do cambio del alcance debe conllevar una nueva evaluación de los recursos
necesarios y contrastarlos con el total previstos para la asignación. Si no se
pueden cumplir los objetivos con el presupuesto previsto, el equipo auditor
debería comunicarlo al cliente de la auditoría, puesto que se podría incurrir
en un elevado riesgo de auditoría (ved el módulo 1 para revisar su significado)
si no se dedican los recursos necesarios.
(4)
Las técnicas para determinar los recursos necesarios y su uso no difieren de Para más información sobre ges-
tión de proyectos, se recomienda
las que se emplean para la planificación y gestión de cualquier otro tipo de
consultar la guía ampliamente re-
proyecto, por lo que no entraremos en detalles sobre técnicas de gestión de conocida del PMBOK (Project Ma-
nagement Body of Knowledge), el
proyectos4, lo cual es una temática muy amplia sobre la que existe literatura estándar para la gestión de proyec-
tos desarrollado por el PMI (Project
especializada.
Management Institute).
Por tanto, el presupuesto previsto para la asignación de la auditoría y su alcan-

ce determinarán las fases y pruebas de auditoría, y también las técnicas que
se emplearán. Cuando nos encontramos ante auditorías puramente técnicas
que evalúan la implantación de controles de seguridad, para distinguir las di-
ferentes técnicas y sus implicaciones, nos fijaremos de nuevo en la OSSTM,
que ofrece la clasificación que examinaremos a continuación:
Clasificación de las auditorías en base al coste y el tiempo. Fuente: OSSTMM
Esta clasificación adolece de una visión demasiado técnica, pero nos sirve co-
mo referencia para comprobar que existen distintas formas de abordar la au-
ditoría de seguridad de los sistemas de información. Emplearemos la termino-
logía utilizada por la OSSTMM, aunque alguna de las denominaciones puede
inducir a confusión; sin embargo, la distinción entre cada una de las audito-
rías es completamente coherente.
1)� Búsqueda� de� vulnerabilidades. Cuando los recursos involucrados sean

muy reducidos, la auditoría se podrá limitar a comprobaciones automáticas
de un sistema dentro de una red, mediante herramientas que automaticen las
tareas y empleen fuentes de información externa, o bases de datos que recojan
las vulnerabilidades conocidas de los sistemas involucrados.
2)�Escaneo�de�la�seguridad. No se diferencian demasiado de la auditoría de Terminología

búsqueda de vulnerabilidades salvo por la intervención del equipo auditor a
Las auditorías de escaneo de la
la hora de analizar los resultados. Las herramientas de búsqueda de vulnerabi- seguridad también suelen ser
lidades adolecen de generar demasiados "falsos positivos". La gran mayoría de denominadas análisis de vulne-
rabilidades.
herramientas de este tipo examinan los sistemas desde su exterior y por ello
suelen generar más avisos de los que finalmente resultan significativos. Serán
necesarias, por tanto, verificaciones manuales de falsos positivos, la identifi-
cación de los puntos débiles de la red y el análisis profesional individualizado.
3)�Test�de�intrusión. Desde el punto de vista de los recursos de auditoría ne- Test de intrusión
cesarios, este tipo de auditoría se encuentra limitada en el tiempo. Además,
Recuerda que un test de intru-
los requisitos de capacidad del equipo auditor son elevados al tener que en- sión es una auditoría de segu-
frentarse a una infraestructura de la que no se tiene información inicial. Este ridad de tipo técnico sin cono-
cimiento previo del equipo au-
tipo de pruebas suelen encontrarse limitadas tanto en el tiempo como en los ditor.
objetivos, que consisten en evidenciar de algún modo el compromiso de la

seguridad de la información manejada (modificar algún archivo en algún sis-
tema, facilitar en el informe final de auditoría detalles de arquitecturas, etc.).
4)�Evaluación�de�riesgo. Los anteriores tipos de auditorías se refieren a eva-

luaciones puramente técnicas de la seguridad; no examinan en ningún caso
la implantación de controles que son aplicables a los procesos organizativos
en el auditado. Sin embargo, sabemos que los controles de seguridad pueden
ser de diferentes tipos. Este tipo de auditoría se combinará con auditorías de
escaneo de seguridad y se realizará específicamente una evaluación del riesgo
combinando estos resultados técnicos con entrevistas e investigación de nivel
medio que incluye la justificación de negocios, las justificaciones legales y las
justificaciones específicas de la industria.
5)�Auditoría�de�seguridad. Desde su punto de vista eminentemente técnico,

la OSSTMM entiende la auditoría de seguridad como una auditoría técnica de
la seguridad de los sistemas de información y, por tanto, hace referencia a la
inspección manual con privilegios administrativos del sistema operativo y de
los programas de aplicación del sistema o sistemas dentro de una red o redes.
Por lo tanto, cuanto más extensa sea la infraestructura y más exhaustiva sea
la auditoría deseada, más recursos de auditoría se requerirán.
6)�Hacking�ético. Se refiere generalmente a los tests de intrusión, cuyo objetivo Técnicas de hacking ético
es obtener trofeos en la red dentro del tiempo predeterminado de duración del
Las técnicas que se pueden
proyecto. La diferencia con los tests de intrusión es que su duración puede ser emplear en las auditorías de
mayor, puesto que se combinarán distintas técnicas. hacking éticos son tan dispares
como la ingeniería social o el
análisis de vulnerabilidades.
7)�Test�de�seguridad. Por último tendremos las auditorías similares a una eva-

luación de riesgo, pero con un alcance más amplio que no se limita a las impli-
Evaluación de postura
caciones técnicas, legales y de normativa del sector. Se evaluarán los distintos
procesos de negocio que influyan sobre la seguridad de la información bajo La evaluación de postura es el
equivalente militar de los test
el alcance de la auditoría. de seguridad.
El conocimiento del tipo de auditoría que se ha de realizar permitirá

al equipo auditor determinar y pactar con el auditado el alcance de la
auditoría, los plazos para su ejecución y los recursos necesarios.
4. Planificación de una auditoría técnica de seguridad
La planificación que os proponemos aquí de auditoría es genérica y cada equi- Ved también
po auditor deberá aplicarla a su caso particular. Sin embargo, podemos afirmar
La planificación de auditoría ya
que para adherirse a las metodologías más reconocidas, cualquiera que sea el se introdujo en el módulo 1,
tipo de auditoría que se afronte, se deberán ejecutar las siguientes fases: en el punto 3.
• Definición del plan de auditoría e iniciación del proyecto
• Ejecución de la auditoría
• Recolección de información previa
• Ejecución de las pruebas de auditoría
• Análisis de la información
• Elaboración y presentación del informe
• Seguimiento de la auditoría
El esquema general de una auditoría sería el mostrado en el siguiente diagrama.

Proceso general de una auditoría
Hay que destacar que esta organización de la auditoría está recogida también
en el estándar para la auditoría de sistemas de gestión ISO19011, por lo que
podemos concluir que el proceso de auditoría tiene aspectos independientes
del objeto que se está auditando.
Examinemos un poco más en detalle qué actividades se incluirán en cada una

de estas fases.
4.1. Definición del plan de auditoría
Una vez establecido con el auditado el alcance de la auditoría, se deberán rea-

lizar las siguientes acciones:
a) El alcance de una auditoría se plasma en un documento en el caso de que

el equipo auditor sea externo, por ejemplo, en una oferta de prestación de
servicios profesionales, o se establece por la creación de un proyecto interno
de auditoría, en el caso de una auditoría interna.
b) El equipo auditor tendrá que obtener el compromiso y el apoyo de la direc-

ción de la organización auditada para la realización de la acción de auditoría.
Esto se suele reflejar en algún tipo de documento que refleje compromiso por
parte de la dirección.
En auditorías internas en organizaciones maduras, se suele denominar carta

de�auditoría o carta�de�asignación�de�auditoría al documento que descri-
be la asignación de tareas que el equipo auditor tiene que realizar. En él se
indican temas como el objetivo de la auditoría, su alcance, los criterios para
determinar el éxito o no de la auditoría, el material a entregar al finalizar la
auditoría, el nivel de acceso a la información que se facilitará al auditor, los
procedimientos de comunicación entre el auditor y el auditado, etc. Cuando
se trata de auditorías de tipo técnico, existe otro aspecto que hay que estable-
cer: el tipo de pruebas y el modo en que se desarrollarán. Esto es especialmente
importante en el caso de que se vayan a incluir pruebas que puedan causar
la interrupción de algún servicio. En estos casos, gracias a este documento el
equipo auditor se encontrará libre de responsabilidades.
En una auditoría externa, este documento no suele denominarse carta de au-

ditoría y su contenido suele estar establecido en la propia oferta de servicios
profesionales. Pero en el caso de una auditoría interna, el estatus del auditor
puede quedar indefinido y, por lo tanto, es muy importante que la dirección
que impulsa la acción de auditoría apoye oficialmente al equipo auditor me-
diante la firma de este tipo de documento de uso exclusivamente interno.
Si la auditoría es de segunda o de tercera parte, siempre habrá algún documen-

to que acredite la motivación y el alcance de esta. En auditoría de segunda
parte, dependerá del contexto, por ejemplo en auditorías sobre un proveedor
para el control del servicio que se está prestando, este documento será proba-
blemente el contrato de prestación de servicio que incluirá alguna cláusula
que da derecho al cliente a auditar al proveedor, y alguna carta oficial en la
que se informa al proveedor que se desea realizarla. En auditorías de tercera
parte, este documento será la solicitud de servicio por parte del auditado a una
entidad externa que realiza la auditoría, por ejemplo una entidad de certifica-
ción. En general, la aceptación de este documento por parte de la dirección de
la entidad auditada es lo que constituye el compromiso de la dirección con la
acción de auditoría que se va a llevar a cabo.
c) El equipo auditor tendrá que garantizar que tratará la información con las Nota
debidas garantías de confidencialidad y con arreglo a cualquier normativa que
Es conveniente que el acuer-
sea de aplicación. En el caso de realizarse una auditoría externa, se debe reflejar do de confidencialidad sea re-
este compromiso del equipo auditor con el deber de secreto profesional en al- visado por un asesor legal para
que incluya todos los aspectos
gún tipo de soporte legal. Este tipo de documento se suele denominar "acuerdo legales, como por ejemplo la
protección de datos de carác-
de confidencialidad" (en inglés, non-disclosure agreement - NDA). En el caso de ter personal.
tratarse de auditorías internas con personal interno, lo habitual será que todo
el personal de la organización haya firmado un acuerdo de confidencialidad
en los términos que les sean aplicables según las funciones laborales que fue-
ran a desarrollar, por lo que podría no ser necesario. Sin embargo, si el auditor
es externo, es completamente necesario y en su redacción deberá quedar claro
que todo el equipo auditor se encuentra sometido a él, no sólo el auditor jefe.
d) El equipo auditor deberá definir, presentar y pactar con el auditado el plan

de auditoría. Éste debe determinar con exactitud lo siguiente:
• Plazos temporales:
– Fechas de inicio y fin de los periodos de prueba.
– Periodos del día para realizar las pruebas.
– Periodicidad del plan de auditoría. Establecer la periodicidad convierte
el plan en un programa de auditoría (puede estar ligado al contenido
de algún elemento de SGSI).
• Procedimientos de comunicación con los responsables de proyecto en el

auditado, especialmente para:
– La comunicación del descubrimiento de vulnerabilidades críticas o si-
tuaciones de fraude.
– Cualquier protocolo que pueda solicitar o necesitar el auditado sobre

comunicación de inicio y fin de pruebas, especialmente cuando se tra-
ta de pruebas técnicas en entornos productivos.
– Tipo de reporte hacia el auditado y el cliente de auditoría que pudiera

ser necesario realizar durante el desarrollo de las pruebas de campo
con el fin de controlar que no se produzca ninguna desviación sobre el
alcance o que se materialice ningún tipo de riesgo que pudiera poner
en compromiso el éxito de la auditoría.
• Inventariado de las políticas corporativas que afecten a la auditoría y que

van a ser comprobadas por el proceso de auditoría.
• Documentación de las pruebas que se van a realizar indicando:
• Objetivo de la prueba: se tratará de identificar qué requisito de las políticas
de seguridad del auditado, o en caso de no existir, qué requisito de un
catálogo de buenas prácticas se va a auditar. Es por esta razón por lo que
en esta fase el equipo auditor deberá estudiar las políticas y catálogos de
buenas prácticas que sean de aplicación en el alcance de la auditoría.
• Modo en que se realizará la prueba: descripción, al menos somera, del pro-
cedimiento y técnicas de auditoría que se aplicarán para comprobar el/los
requisito/s auditado/s.
• Herramientas o requisitos específicos necesarios para realizar la prueba.
Documentación de pruebas
Hay que notar que si el alcance de la auditoría es muy amplio, la documentación de las
pruebas puede resultar un proceso muy laborioso. Obviamente, el trabajo previo no debe
sobrecargar el esfuerzo total dedicado a la auditoría. Por lo tanto, la documentación de las
pruebas debe realizarse de un modo proporcionado al esfuerzo total. Si el alcance es muy
amplio, las pruebas que se han de realizar se podrán describir de un modo más general,
aunque no deberá sacrificarse la exhaustividad a la hora de cubrir las áreas comprobadas;
quizá sí que se podrá describir cada tipo de prueba de un modo no totalmente descriptivo
y ser más indicativo del objetivo de la prueba y de las técnicas aplicadas en la misma.
El plan de auditoría deberá estar aprobado tanto por el jefe del equipo
auditor como por parte de la entidad auditada.
Caso práctico: plan de auditoría
Una entidad financiera ha desarrollado una nueva aplicación bancaria para uso de
sus clientes a través de Internet. Se trata de una aplicación en 3 capas con un front-
end constituido por un servidor web. Antes de pasar la aplicación a producción, y en
el marco de las pruebas de aceptación de usuario, la dirección desea que una entidad
externa realice una auditoría de seguridad de la aplicación.
El equipo auditor, una vez firmados los acuerdos de confidencialidad y la Carta de

Auditoría materializada en la oferta de servicios profesionales, facilita a la dirección
del auditado un Plan de Auditoría con el siguiente contenido (resumido):
Plan de auditoría de una aplicación web
1. Información general
• Objetivo� del� Plan. El objetivo general de la auditoría a realizar será iden-

tificar errores de programación o de configuración en la aplicación "BAN-
CA-ONLINE" accesible desde el portal del banco XXXX en la URL: http://ban-
ca-online.XXXX.com.
El objeto del presente documento es recopilar los distintos aspectos a revisar den-
tro de la aplicación bajo auditoría. Se describirán todos los aspectos relevantes
que serán revisa-dos.
Este documento constituirá la guía a emplear para la coordinación entre equi-
po-auditor y XXXX a la hora de planificar, programar las pruebas a realizar y ges-
tionar las autorizaciones que sean necesarias para la realización de la auditoria.
Este plan no pretende recopilar el detalle de todas y cada una de las pruebas que se
realizarán sino que su objetivo es describir en detalle la estrategia de prueba que se
seguirá. Esta estrategia se encuentra basada en los principios para la programación
segura de aplicaciones Web descritos por la organización independiente OWASP
(Open Web Application Security Project). Por tanto se describirán en detalle el tipo
de pruebas que se realizarán aunque no se indicará explícitamente en que partes
de la aplicación se realizarán las pruebas por ser demasiado amplio el alcance.
• Alcance. La presente auditoría se ceñirá a la revisión de controles de seguridad

aplicados en la capa de aplicación, es decir NO se realizará un análisis de la plata-
forma tecnológica que da soporte a la aplicación (sistema operativo u otras apli-
caciones distintas a las propias aplicaciones, como por ejemplo Web servers, Ap-
plication Servers, etc) salvo que se indique de otro modo por la dirección de pro-
yecto de XXXX en cuyo caso se actualizará este documento. Sí se ha de destacar
que la determinación de la plataforma tecnológica empleada constituye una de
las pruebas a realizar por constituir una de las informaciones empleadas para las
subsiguientes pruebas. Sin embargo, una vez determinada, no se realizará una
verificación de posibles vulnerabilidades que pudiera tener esta plataforma.
Este plan de auditoría se ejecutará previsiblemente entre las fecha DD/MM/AAAA
y DD/MM/AAAA.
Nota
Si el equipo auditor pudiera dar un cronograma del desarrollo de las pruebas sería más
apropiado, pero al menos como mínimo se ha de dar un marco temporal delimitado
para la fase de pruebas
• Visión�general�del�sistema�bajo�prueba. El sistema bajo prueba se corresponde

con el siguiente:
– La aplicación bajo estudio es accesible desde el portal de XXXX en la URL:
http://www.XXXX.com a través del enlace: http://banca-online.XXXX.com
Se revisará la aplicación de BANCA-ONLINE en su parte de operativa destinada

a clientes particulares excluyéndose expresamente todas las operativas desti-
nadas a empresas o relacionadas con gestión de valores cotizados en bolsa.
No se realizarán pruebas que puedan afectar a sistemas no incluidos bajo el
alcance de la auditoría.
– La aplicación facilita acceso a todas las operativas de la aplicación BANCA-ON-

LINE permitiendo comprobar su funcionamiento.
– La aplicación se encuentra en PRODUCCIÓN por lo que todas las pruebas

serán coordinadas con XXXX mediante la gestión de las apropiadas autori-
zaciones en los casos que se considere necesario por el equipo de proyecto
conjunto de EQUIPO-AUDITOR y XXXX con los departamentos adecuados.
• Documentos� de� referencia. Para la realización del presente documento se ha

tomado como referencia los siguientes documentos:
– Oferta del proyecto <código identificativo de la oferta>
– Guía OWASP en su versión oficial y estable: contiene la descripción de los

aspectos que se comprobarán en el presente proyecto.
– Guía OWASP de testing en su versión oficial y estable: contiene una relación

del marco de prueba y de las pruebas a realizar en una aplicación web.
2. Procedimientos de control de las pruebas
• Entorno�de�prueba�requerido. Para la realización de las pruebas anteriormente

descritas será necesario el siguiente entorno:
– Las aplicaciones de BANCA-ONLINE de XXXX (en su versión clientes particu-
lares) deberán estar activas durante el periodo que se determine para la reali-
zación de las pruebas.
– Uno o más puestos clientes desde donde se realizarán las pruebas interac-
tuando con la aplicación a través de comunicaciones sobre Internet. Es-
tos puestos se encontrarán ubicados en las instalaciones de EQUIPO-AUDI-
TOR en c/YYYYYY. La dirección IP desde la que se realizarán las pruebas es:
XXX.XXX.XXX.XXX
– En los puestos clientes se empleará el software de auditoría necesario para

realizar las pruebas. En la definición de cada una de las pruebas se detallará
las herramientas necesarias.
• Procedimiento�de�comunicación�de�inicio�y�fin�de�pruebas. Puesto que el en-

torno bajo prueba es un entorno en producción y se encuentra monitorizado con
herramientas de seguridad, es necesario que, antes de iniciar cualquier prueba, se
planifique la intervención con el centro de control operativo. Con anterioridad
a la fecha prevista para las pruebas, se deberá obtener del mismo la autorización
y un número de intervención. Al inicio de las pruebas, se comunicará al centro
de control operativo mediante el envío de un correo electrónico a la dirección
soc@XXXXX.com en el que se informará del nombre de la empresa auditora, la
persona de contacto en la organización, el número de intervención, la dirección
IP (una o varias), una indicación de si se realizarán pruebas automatizadas y un
teléfono de contacto para casos de emergencia. Igualmente, se realizará una lla-
mada telefónica al 902xxxyyy que informará del número de intervención. Al fi-
nalizar el plazo previsto para las pruebas, se comunicará la finalización mediante
un correo electrónico a la dirección anteriormente indicada.
• Gestión�de�las�incidencias. En el caso que durante la ejecución del Plan de Audi-

toría se detectará una vulnerabilidad grave que pudiera comprometer la seguridad
(confidencialidad, disponibilidad o integridad) de la aplicación se comunicará a
XXXX la incidencia y circunstancias que la provocaron.
Con anterioridad al inicio de la ejecución de las pruebas se tendrá que determinar
con exactitud los procedimientos a emplear, los POC (point of contact) adecuados
y los periodos en los que se encontrarán disponibles y los medios a emplear en
cada caso. En el caso que XXXX tuviera ya definido un modo de proceder, se
procederá de la manera que se tenga prevista en estos procedimientos. En caso
contrario, se procederá del siguiente modo:
a. El procedimiento de comunicación urgente de las incidencias se activará cuan-

do un auditor de EQUIPO-AUDITOR detecte, ya sea mediante la realización de
una prueba o bien por cualquier otra circunstancia, una vulnerabilidad grave.
Se entiende por vulnerabilidad grave cualquier aspecto del funcionamiento de la
aplicación que cause:
– Una filtración de información confidencial
– Una modificación no autorizada de información
– Un malfuncionamiento de la aplicación que cause, o pudiera causar si fuera

explota-da de manera adecuada, una denegación de servicio
– En general, cualquier incidente que pudiera situar al sistema en un estado

inoperable.
En este caso y una vez comprobada la existencia de la vulnerabilidad, el auditor

se podrá en contacto con el POC mediante los cauces previstos para informar de
la situación y las circunstancias que lo provocan.
b. El detalle de la incidencia se documentará en el informe de auditoría.
3. Definición de las pruebas.
A continuación se presentan el conjunto de pruebas que se realizarán para la auditoría

dentro del alcance determinado anteriormente.
• Estrategia�de�prueba. El presente Plan de Auditoria se centra en la comprobación

de la implementación de los controles de seguridad en la capa de aplicación, es
decir, en los controles que la propia aplicación debe implementar para garantizar
la confidencialidad, integridad y disponibilidad de la información que se tratada
desde ella. Puesto que la aplicación que se pretende auditar tiene una arquitectura
de 3 capas basada en tecnologías Web, se ha tomado como referencia la metodo-
logía OWASP. Esta metodología nos facilita una guía detalla-da con los conceptos
necesarios para diseñar, desarrollar, desplegar o auditar aplicaciones Web. Por lo
tanto la estrategia empleada para diseñar las pruebas de este Plan de Auditoria
deriva de esta metodología.
De este modo, se han organizado diferentes fases de pruebas con objetivos dife-
rencias que detallamos a continuación:
– INF – Recogida de información
– LOG – Estudio de la lógica de negocio
– AUT – Revisión del proceso de identificación y autenticación
– SES – Revisión de la gestión de sesiones
– VAL – Revisión de la validación de los datos de entrada
– DOS – Revisión de situaciones de denegación de servicio
• Recogida�de�información. El objetivo de esta fase es la comprobación de la in-

formación relativa a la aplicación auditada que puede ser obtenida de forma le-
gítima empleando los diversos canales exis-tentes en Internet.
a. Prueba [INF-001]-Identificación del servidor Web
• Requerimiento a probar. Identificar el tipo de servidor Web que aloja la capa de

presentación de la aplicación. Si se determina correctamente la versión exacta del
software del servidor Web se podrá determinar las vulnerabilidades públicas exis-
tente a fecha de auditoria y determinar la política de parcheado / mantenimiento
de los sistemas de soporte de la aplicación.
• Descripción de la prueba. Conectar con el servicio HTTP en el puerto 80 (u otro

si se emplea) y determinar la aplicación y versión del servidor Web. Para ello se
emplearán las siguientes herramientas:
– Netcat. Para recoger el "banner" expuesto por el servidor
– HTTPRINT. Para examinar la respuesta del servidor a diversas peticiones http

y compararla contra diversas "firmas" mantenidas en el catálogo de la aplica-
ción HTTPRINT.
b. Resultados esperados. Se deberán identificar los siguientes aspectos:
• Nombre de la aplicación
• Fabricante
• Versión
• Nivel de parcheado
c. Prueba [INF-002]-Identificación del aplicaciones
a) Requerimiento a probar. Identificar todas las aplicaciones Web / portales servidos

desde un servidor Web concreto.
Cuando el objetivo de la auditoria consiste en la comprobación de manera general
de la seguridad de una infraestructura, es importante inventariar e identificar las
distintas aplicaciones ofrecidas puesto que cada una de ellas es susceptible de ser
examinada de manera diferente. En el caso que ya esté determinada la aplicación
que se ha de auditar esta prueba carecerá de sentido.
b) Descripción de la prueba:
• Investigar si existen diferentes URLs base que hospedan diferentes aplicacio-
nes Web.
• Investigar si en la IP existen otras aplicaciones instaladas en otros puertos

distintos a los estándares (80, 443, 8080, 8000). Emplear para ello la herra-
mienta NMAP.
• Para identificar hosts virtuales y encontrar nombres de dominios asignados

a la IP auditada:
– Comprobar la posibilidad de realizar transferencias de zona en el servidor
DNS del dominio examinado
– Comprobar la posibilidad de realizar resolución inversa de nombres (Re-

verse DNS query)
– Conectar con servicios en Internet para examinar registros DNS, o direc-

tamente buscadores tradicionales.
Páginas web
Algunas "herramientas": www.live.com, www.dnsstuff.com, www.google.com, etc.
d. Resultados esperados. Se deberá identificar, para cada una de las IP examinadas

dentro del ámbito del proyecto, los dominios, subdominios y las URLS de entrada a
las aplicaciones identificadas.
El�plan�continuaría�con�todo�el�detalle�de�las�pruebas�a�realizar
4.2. Ejecución de la auditoría
Una vez que el equipo auditor y el auditado han aprobado el plan de auditoría,
los auditores se encuentran en disposición de iniciar su trabajo.
A pesar de que la ejecución es completamente dependiente del alcance, enfo-

que y tipo de auditoría, podemos identificar ciertas fases que se cumplen de
manera general en cualquier tipo de auditoría.
A continuación repasaremos las subfases que componen la ejecución de la

auditoría.
4.2.1. Recolección de información previa
Esta subfase permitirá al equipo auditor preparar la ejecución de las pruebas

identificadas en el plan de auditoría. Las actividades que se desarrollarán in-
cluyen:
• Recopilar toda la información relevante para obtener un correcto enten-

dimiento del entorno a auditar:
– Los requisitos del negocio y los riesgos asociados.
– Leyes y regulaciones.
• Identificación de cargos/roles/funciones para detectar las entrevistas ne-

cesarias y el personal que deberá asistir:
– La estructura organizacional.
– Los roles y responsabilidades.
• Identificación y estudio de la documentación existente del auditado que

sea relevante para la auditoría:
– Políticas y procedimientos.
– Descripción de los entornos de tratamiento de la información y estu-
dio de las vulnerabilidades conocidas que les sean aplicables.
– Descripción de las medidas de control establecidas.
4.2.2. Ejecución de las pruebas de auditoría
Una vez recopilada toda la información necesaria, el equipo auditor desarro-

llará de manera efectiva el conjunto de pruebas documentadas en el plan de
auditoría. Tal y como se ha comentado, para la realización de una auditoría
de seguridad dependiendo de su alcance, enfoque y tipo, las pruebas que se
deben practicar serán:
• Revisión�de�documentación, como por ejemplo las políticas que se han

de auditar para comprobar su idoneidad dado el entorno del auditado y
las mejores prácticas reconocidas por la industria. Asimismo, se revisará
otro tipo de documentación relevante para el proyecto como podrían ser
inventarios, documentos de diseño, procedimientos operativos, etc.
• Realización�de�entrevistas para comprobar si el personal conoce las po-

líticas y las aplica. Pueden ser necesarias diversas entrevistas dentro de un
mismo nivel funcional con el objetivo de detectar incongruencia, olvidos
o intentos de esconder el modo habitual de proceder.
Desarrollo de la entrevista
Las entrevistas se desarrollarán habitualmente en instalaciones propias del auditado pa-

ra interrumpir lo menos posible las operaciones normales de la organización y deberán
realizarse siempre al personal más representativo y mejor preparado para cubrir los as-
pectos que se quieren analizar. El desarrollo de las entrevistas se tiene que realizar en un
tono no amenazador para el entrevistado y, aunque se trate de una auditoría, se tiene
que transmitir la idea de que constituye una oportunidad para mejorar algún aspecto de
la seguridad y/o la eficiencia de los procedimientos.
• Ejecución�de�pruebas�técnicas para comprobar el modo como se encuen-

tran implantados los controles técnicos de acuerdo tanto a las políticas
como a las buenas prácticas de la industria. Las áreas más habituales que
se examinarán en este tipo de pruebas serán:
– Funcionamiento de los sistemas y las comunicaciones (con especial
importancia para el control y uso de accesos remotos).
– Configuración de los sistemas (servidores, puestos de trabajo o elemen-
tos de la infraestructura de comunicaciones).
– Revisión de registros de actividad de sistemas.
Durante la ejecución de estas pruebas es posible que el equipo auditor

detecte vulnerabilidades técnicas que, por su especial criticidad, se deberán
transmitir con agilidad al auditado.
• Realización�de�visitas para examinar aspectos de seguridad física y/o com-

probar in situ el modo en que operan los sistemas de información.
Es importante que a medida que se desarrolla el plan de auditoría, el

equipo auditor vigile si, sobre la base de la nueva información que se va
adquiriendo, no existen cambios sustanciales que impliquen o bien una
modificación del alcance o bien la ejecución de pruebas diferentes a las
inicialmente planteadas. En un primer momento, estos puntos deben
ser discutidos por el equipo internamente y posteriormente concretados
con el auditado, puesto que pueden implicar la necesidad de dotar de
más recursos a la auditoría.
4.2.3. Análisis de la información
En realidad, el proceso de análisis se inicia desde el mismo momento en que

comienza la ejecución de la auditoría y únicamente finaliza con la aceptación
por parte del auditado de la última revisión del informe de auditoría. Sin em-
bargo, cuando el desarrollo de las pruebas se encuentra en un estado avanza-
do, el equipo auditor deberá compaginarlas con el análisis de la información
recopilada. Este análisis realizado en paralelo con la ejecución de pruebas per-
mite ir refinando las sucesivas pruebas, tanto las puramente técnicas como
aquellas otras que requieran nuevas entrevistas, visitas o documentación adi-
cional del auditado.
El riesgo es proporcional a tres factores:
• Al valor del activo de información involucrado.

• A la probabilidad de que una amenaza pueda aprovechar una vul-
nerabilidad o problema que hemos detectado durante la auditoría.
• Al impacto que pueda llegar a provocar la explotación de la vulne-
rabilidad.
A la hora de analizar la información recopilada, podemos, de un modo general,

separarla en dos grandes áreas:
1)�Revisión�de�políticas. Tal y como hemos expuesto en numerosas ocasiones

(no nos cansaremos de repetirlo) la piedra angular de un programa efectivo
de seguridad de la información son sus políticas de seguridad, tanto las gene-
ralistas como las más específicas diseñadas con un alcance reducido orientado
a una temática o un entorno de sistemas de información determinado, bien
redactadas, comunicadas y cumplidas. Estas políticas sirven de origen para to-
do el resto de documentación: directivas, estándares, procedimientos, guías,
etc. Por lo tanto, es importante analizarlas con el objeto de responder a las
siguientes preguntas:
• ¿Existen y están al alcance del personal que se encuentra afectado por

ellas?
• ¿Cuán bueno es su contenido? En este sentido es importante que las polí-

ticas sean concisas, claras y no deben generar confusión e introducir nue-
vos problemas en la organización. La calidad y efectividad de una política
nos las determinará el modo en que se respondan las siguientes preguntas
(las 5 W del periodismo):
– What: ¿cuál es la temática de la política y cuál es el activo de informa-
ción que se pretende proteger?
– Who: ¿quién es el responsable de emitir la política y quién se encuentra

afectado por ella?
– Where: ¿a qué partes de la organización afecta la política?
– Why: ¿por qué es relevante la política?
– How: ¿cómo se protege el activo de información?

2)�Revisión�de�la�información�recopilada�durante�las�pruebas. Las pruebas Dominio del proceso de

tendrán un carácter esencialmente técnico, pero también se deberán analizar análisis
los resultados de entrevistas y visitas, para contestar a las preguntas: ¿cómo se El proceso de análisis de este
distribuyen, comunican y aplican las políticas de seguridad? ¿Cuán efectivos tipo de información es tan am-
plio y responde a unas casuísti-
son los controles de seguridad? cas tan diversas, que es difícil
dominarlo mediante un libro o
una metodología.
De manera general podemos destacar que el análisis de los resultados deben
buscar la identificación de:
• Incumplimientos de los controles de seguridad implantados que se debe-

rían encontrar documentados en las políticas.
• Vulnerabilidades en el modo en que están implantados los controles, es-

pecialmente cuando se trata de controles cuya implantación se realiza me-
diante medios técnicos, ya sean problemas en la arquitectura de los sis-
temas implementados, errores de configuración en elementos de la infra-
estructura o aplicaciones en modo Cloud (herramientas en modo SaaS -
Software as a Service) o fallos en sistemas operativos o aplicaciones.
Una vez identificados estos resultados, el auditor deberá identificar los hallaz-
gos de auditoría que se derivan de ellos. No siempre existe una relación directa
1 a 1 entre el resultado de una prueba de auditoría y un hallazgo. Los resulta-
dos de varias pruebas pueden poner de manifiesto un incumplimiento de una
política o una mala implementación de un control.
De este modo, el análisis de los resultados de las pruebas proporcionará la

visión de la efectividad y eficiencia de los controles de seguridad y del listado
de hallazgos que debe ser trasladado como resultado del proceso de auditoría.
Durante esta fase de análisis, uno de los aspectos que el auditor deberá ir eva-
luando es la importancia relativa o el riesgo de no conformidad del problema
que detecte. Esta actividad tiene especialmente relevancia en auditorías técni-
cas de seguridad en las que el auditor identifica vulnerabilidades en sistemas
de información. Suele denominarse en determinados ambientes como “mo-
delado de amenazas”. Existen varias técnicas, pero en general todas ellas em-
plean técnicas de análisis de riesgos consistentes en aplicar la conocida ecua-
ción del riesgo:
Factores de la ecuación de riesgo
Para poder valorar adecuadamente las evidencias encontradas en la auditoría y

poder relativizarlas, será necesario realizar este ejercicio. Hay que destacar que,
para la valoración de hallazgos de auditoría referentes a vulnerabilidades en
sistemas de información, existe un método ampliamente utilizado, el common
vulnerability scoring system (CVSS), que trataremos en el módulo 5.
4.3. Reporting de la auditoría
Una vez realizadas las distintas pruebas planificadas y el análisis de la infor-

mación obtenida, el equipo auditor se encuentra en disposición de transmitir
al cliente auditado sus conclusiones de la auditoría. Esta fase es crítica puesto
que un equipo auditor con insuficiente capacidad de transmitir sus conclusio-
nes al cliente no conseguirá cubrir los objetivos de la auditoría.
Los auditores deben realizar un informe lo más simple y directo posible y siem-
pre facilitando la información relevante, así como los distintos hallazgos rea-
lizados. Al mismo tiempo, debe facilitar de manera sencilla la forma de resol-
ver las deficiencias halladas.
El informe final de auditoría puede seguir cualquier esquema, pero el elegido

debe incluir o tratar de un modo u otro los siguientes aspectos:
1)�Resumen�ejecutivo. Cuando se desarrolla el informe, y una vez analizada

la información recogida durante la auditoría, es recomendable comenzar por
este punto, puesto que puede requerirse por parte de la dirección una primera
versión de las conclusiones de auditoría. Este apartado es muy recomendable
incluirlo ya que en muchas ocasiones, esta parte del informe es la única que
será leída por algunos de sus destinatarios que tienen poder de decisión tanto
en el cliente de la auditoría como en el auditado. Por lo tanto, deberá reflejar
de manera resumida su contenido. Incluirá, por tanto, una introducción, una
visión general de la metodología empleada, las principales conclusiones que se
hayan obtenido y las recomendaciones más relevantes que el equipo auditor
pueda dar. El lenguaje empleado será lo más directo y comprensible para un
público amplio.
Es recomendable incluir en el resumen ejecutivo tanto las fortalezas co-

mo las debilidades o fallos detectados para facilitar una conclusión me-
surada de la auditoría.
2)�Metodología�empleada. Se debe dar una breve explicación de la metodo-

logía que se ha empleado. No es necesario que sea muy extenso ya que en el
plan de auditoría ya se da detalle de ello. Se hará referencia a los estándares
empleados o bien si se emplean estándares propios deberán ser explicados,
detallando los objetivos, las fases y las técnicas utilizadas para realizar la audi-
toría. El receptor del informe debe conocer con qué criterios y de qué modo
se ha realizado el trabajo. En este apartado puede hacer referencia al plan de
auditoría si constituía un entregable de la asignación de auditoría (que aunque
siempre debe existir, al menos internamente, para el equipo auditor, puede
que no siempre se entregue al auditado) o, en su defecto, puede ser interesante
incluir una explicación de las pruebas sin entrar en todos los detalles. Mínima-
mente se consignarán los datos de las entrevistas realizadas (personas, lugares
y fechas), las pruebas técnicas realizadas con sus respectivos objetivos y las he-
rramientas empleadas, así como los plazos en los que se realizaron las pruebas.
3)�Listado�detallado�de�los�hallazgos. Este apartado contendrá en detalle los

resultados del proceso de auditoría que son los hallazgos y que no deben con-
fundirse con los resultados concretos de las distintas pruebas de auditoría que
se han realizado. Como resultado, se recogerán todos los hallazgos realizados,
teniendo muy en cuenta que el auditor debe entender bien la diferencia entre
un hallazgo y un resultado de una prueba. Por ejemplo, la detección de múlti-
ples parches sin instalar no implica un hallazgo por cada uno de ellos, sino un
único hallazgo que sería el incorrecto mantenimiento del sistema. En el infor-
me solo se deben consignar los hallazgos, mientras que, si se estima oportuno
e interesante, los resultados de las pruebas se recogerían en un anexo técnico
al informe. El modo concreto en que se organice este apartado dependerá ex-
clusivamente del alcance de la auditoría, del objetivo que tenga el cliente de
la auditoría, y del detalle al que se haya llegado. Por claridad es recomendable
facilitar inicialmente un listado de los hallazgos indicando su clasificación res-
pecto a la importancia, y posteriormente, en hojas independientes, cada ha-
llazgo de manera separada y con mayor detalle. De cada hallazgo se deberá in-
dicar cuál es el problema (política que se incumple, vulnerabilidad encontra-
da, etc.) del que se han encontrado evidencias y se mostrarán estas (sin entrar
en el detalle de cómo se obtuvieron, que puede dejarse para un anexo técnico
con los resultados de las pruebas). Es conveniente facilitar una evaluación de
su importancia o impacto que podría causar en la organización y de este modo
clasificar su criticidad. La técnica empleada es la anteriormente mencionada
en la fase de análisis de realizar una estimación del riesgo empleando alguna
de las metodologías de modelado de riesgos existentes, aunque cuanto más
sencilla y fácil de transmitir al auditado, mejor. Esta información se podrá in-
cluir en el informe. Es de gran utilidad dar una clasificación de la importancia

de los hallazgos puesto que será empleada por el destinatario del informe para
realizar el seguimiento de la resolución o mejora.
Subjetividad de la clasificación de los hallazgos
No se debe perder de vista que la clasificación de la criticidad de un hallazgo es siempre

un acto subjetivo con lo que, a pesar de ser necesaria una opinión del auditor, siempre
debería ser pactada con el auditado, ya que él es el mejor conocedor del posible impacto
en su negocio del hallazgo.
Ejemplo de clasificación de los hallazgos
Una posible clasificación de los hallazgos podría ser la siguiente:
ID Nivel Explicación
5 Crítico Necesita una resolución inmediata.
4 Importante Debe ser resulto en cuanto sea posible (por

ejemplo, planificar una próxima parada del
sistema con objeto de resolver el problema).
3 Moderadamente importante Debe ser gestionado en el modo en que el

cliente considere conveniente, empleando sus
procedimientos de cambio, pero no debe ser
ignorado ni asumido por la organización.
2 Ligeramente importante Debe ser gestionado en la próxima "reconfi-

guración" planificada, pero no debe ser igno-
rado ni asumido por la organización.
1 A título informativo en este mo- Es recomendable que sea gestionado en la

mento "reconfiguración" planificada y no es reco-
mendable que sea ignorado, aunque podría
ser asumido por la organización después de
su evaluación mediante un análisis de riesgos.
4)�Anexos. En los anexos se deberá recopilar la información que dé respaldo

a los hallazgos descritos en el cuerpo del informe. Incorporan, por tanto, las
salidas de las herramientas que se empleen, los resultados de los checklist rea-
lizados, las actas de las reuniones celebradas, etc. También incluirán los deta-
lles de la resolución recomendada a los hallazgos cuando por su complejidad
requieran una explicación más extensa.
El cuerpo del informe no se debe saturar de información que, a pesar de ser

relevante y útil por su profundidad y exhaustivo detalle, podría sobrecargar
su contenido y desviar la atención del destinatario del contenido del hallazgo
hacia los detalles de su descubrimiento o resolución.
4.4. Seguimiento de la auditoría
Una vez realizada la auditoría y entregado el informe, la responsabilidad de

adoptar las medidas que se recomienden recae en la organización auditada.
No obstante no significa que la labor del auditor haya acabado.
En ciertas ocasiones, puede estar incluida en el documento que define la labor

de auditoría, que el equipo auditor realice una verificación de la resolución
de los hallazgos que el auditado haya aplicado. Por lo tanto, es posible que
el equipo auditor deba, transcurrido un periodo de tiempo, ejecutar de nuevo
parcialmente su plan de auditoría con el fin de verificar si se dan los mismos
resultados que llevaron a la conclusión de la existencia de un determinado
hallazgo o no. Esta fase de “verificación de las resoluciones” puede generar un
informe en sí mismo o bien ser simplemente una modificación del informe
original.
Y finalmente, tampoco está excluida la participación del equipo auditor en las

tareas o proyectos que se deriven de la resolución de hallazgos de la audito-
ría. Aunque su capacidad para involucrarse es muy alta y participa en tareas
de implementación, si la organización auditora y el equipo auditor lo hacen,
puede quedar comprometida su independencia a la hora de volver a auditar
de nuevo la organización. Por lo tanto, lo más habitual es que la organización
auditora no ejecute tareas concretas destinadas a la resolución y que simple-
mente el equipo auditor asista a la organización auditada en la toma de deci-
siones, en el seguimiento de las actividades que se deriven, y una vez finaliza-
da la implantación de recomendaciones, en la revisión de la implantación de
las recomendaciones tal y como se ha comentado.
M1.810 · Auditoría Técnica · PAC-3 – mayo - 2022

PLANIFICACIÓN Y DISEÑO DE AUDITORÍAS
• Cuestión 1 – Definición del alcance de una auditoría
Discutid y explicad los factores que determinan el alcance una auditoría así
como los elementos más básicos que se deben de dar para establecerlo.
Relacionad estos factores con los puntos clave para garantizar el éxito de una
auditoría.
Módulo 3 – Auditoría técnica de seguridad
Punto 1 Factores de éxito de una auditoría
Punto 2.1 Características del alcance de una auditoría
Punto 2.2 Determinación del alcance
El alcance de una auditoría definirá y establecerá el límite a trabajo que debe

hacer el auditor. En tanto que es una delimitación del trabajo a realizar, es un
factor clave para el éxito de la auditoría que el auditor y el cliente de la
auditoría estén de acuerdo en su definición. De esta manera el primero no
tendrá que invertir más recursos de los previstos ni el segundo verá que no se
alcanzan sus objetivos al no haberse tratado algún aspecto que le era de
interés. La ambigüedad o desacuerdo en la definición del alcance que no es
detectado a tiempo lleva inexorablemente ya sea a un sobre esfuerzo no
previsto por el equipo auditor o bien en una insatisfacción por parte del cliente
de la auditoría con los resultados obtenidos.
Los factores y elementos básicos que lo determinarán son variados en cuanto
que los objetivos de la auditoría lo son, pero incluiría todos aquellos que
definan bien los límites del trabajo del auditor, por ejemplo:
1
- - Las áreas y tipos de controles de seguridad que se tengan que

auditar, es decir, si tuviéramos que tomar como referencia la ISO
27001 que capítulos son los relevantes para la auditoría, ¿se trata de
auditar controles de seguridad físico, o bien controles de acceso
lógico, o algún otro capítulo?
- - Tipo de infraestructuras técnicas de tratamiento de información a
auditar: Sistemas físicos (instalaciones), segmentos de red, sistemas
de información y/o tipos de aplicaciones.
- - Personal involucrado con las áreas que se ha de auditar ya sea por
ser usuarias o por ser parte de la operación de las mismas
- - Procesos operativos para la operación de los servicios involucrados
en alcance.
- - Procesos de negocio de la organización a los que da soporte el área
que se quieren auditar (por ejemplo un sistema de información que da
soporte a un determinado proceso de negocio) y en qué consisten
cada uno de ellos (especialmente relevante en auditorias de seguridad
para poder evaluar la importancia de los hallazgos).
El desacuerdo, indefinición o desconocimiento de cualquiera de estos puntos
puede llegar a producir que no se alcancen los objetivos de la auditoría, y por
lo tanto desde el punto de vista del cliente de la auditoría ésta habría
fracasado, o que aunque se alcancen los objetivos del cliente, desde el punto
de vista del auditor se tenga que ir modificando los recursos necesarios y por
tanto incurriendo en un sobrecoste.
A parte de los elementos anteriores que son inherentes al objeto auditado,
también dentro del alcance se incluiría aspectos prácticos o logísticos como
podrían ser
- Marco temporal en que se va a desarrollar la auditoría
- Frecuencias de repetición si es aplicable
- Lugares
• Cuestión 2 – Plan de auditoría

El Plan de Auditoría es un documento fundamental que debería existir en toda
auditoría. Explicad por qué razón es un elemento básico y fundamental para
garantizar el éxito de la auditoría. ¿Qué relación tiene con el alcance y el éxito
o fracaso de una auditoría? ¿Qué problemas debe resolver y/o evitar que se
produzcan?
Punto 4.1 Definición del plan de auditoría (y especialmente el ejemplo dado)
2
El alumno debe explicar que el Plan de Auditoría es la “hoja de ruta” de la

auditoría, que describe todo lo que se va a realizar y en la medida de lo
posible cómo (en el caso de las pruebas técnicas no llega a detallar el modo
en que se realizarán pero si que las describirá) y que debe ser conocido de
antemano por el auditado. Es el documento por el que el auditado conocerá
las pruebas que se realizarán, cuando se realizaran (y periodicidades si es
aplicable) el modo, en general, cómo se realizaran (por ejemplo especificando
si será contra sistemas en producción o no). Además de estos aspectos
concretos sobre la acción puramente auditora, también contendrá los
aspectos de coordinación y comunicación entre auditor y auditado
(procedimientos de comunicación para iniciar las pruebas, procedimientos de
comunicación de incidencias, reporting periódico durante la auditoría. etc.) y
cualquier otro aspecto de orden práctico que se deba conocer para garantizar
la ejecución de las pruebas de auditoría.
En general, el plan de auditoría debe buscar comunicar y pactar con el
auditado todo lo relevante durante la ejecución para evitar desacuerdos,
malentendidos o incidencias que puedan poner en peligro la ejecución de la
auditoría y por tanto la consecución de los objetivos que el cliente de la
auditoría desea que se alcancen. Los desacuerdos o malentendidos vendrán
en gran medida por un alcance que puede ser ambiguo en fases iniciales del
proyecto de auditoría pero que el plan de auditoría debe dejar claro puesto
que reflejará todas las acciones de auditoría que realizaran y las que se
excluirán. En caso que existieran errores de definición del alcance estos
debería de manifestarse en el momento de acordar el Plan de auditoría y
permitir por tanto corregir esta indefinición.
Por otro lado las incidencias en una auditoría de seguridad pueden ocurrir
sobre todo si las pruebas incluyen la identificación de vulnerabilidades ya que
las pruebas diseñadas podrían tener la capacidad potencial de poner en
peligro algún aspecto de seguridad (habitualmente preocupa en estas
ocasiones la integridad y la disponibilidad, y no la confidencialidad ya que la
acción de auditoría suele estar acompañada de un acuerdo de
confidencialidad entre las partes) que es necesario saber a priori como se ha
de gestionar. Otro tipo de incidencias que pueden ocurrir es que durante una
auditoría se pueda identificar situaciones de fraude, debilidades en los
controles extremadamente graves o incluso compromisos de sistemas ya
realizados, y todas estas situaciones deben ser gestionadas prioritariamente y
debe ser descrito el modo en el plan de auditoría.
Finalmente, en caso de conflicto entre auditor y auditado durante la ejecución
de la auditoría, podría ser aclarado mediante este documento ya debe reflejar
cómo se actuará durante la auditoría.
3
• Cuestión 3 – Enfoque de la auditoría

Tomemos como ejemplo la empresa XXXX,SA y supongamos que acaba de
desarrollar una nueva aplicación web, por ejemplo una aplicación para una
gran cadena de librerías que sea un “marketplace” con interacción tanto con
una pasarela de pago para poder efectuar compras on-line, como también el
sistema de gestión de stocks y pedidos de la entidad cliente.
Esta pregunta busca que el alumno describa 2 auditoría distintas que, aun
siendo sobre el mismo alcance, el sistema TIC explicado anteriormente, se
afronte desde 2 perspectivas distintas según el nivel de conocimiento del
equipo auditor. Una deberá ser enfocada desde la perspectiva “black box” y la
otra desde el extremo contrario, “White box” (o incluso más aún, según
ISECOM, “crystal box”). Para cada una de ellas se deberá describir el
alcance, que objetivo busca el cliente de la auditoría, recursos técnicos o
entornos necesitaría el auditor. La explicación deberá mostrar claramente las
diferencias.
Punto 3 Tipos de auditoría (especialmente el punto 3.2)
Este punto es práctico y se podría dar diversos ejemplos. Pero el alumno

deberá dejar claro en sus ejemplos que se ha comprendido que por el simple
hecho de modificar el enfoque que se la da a la auditoría respecto al nivel de
conocimiento previo que el auditor tendrá sobre el entorno auditado cambia
completamente las características de la auditoría aunque se trate del mismo
entorno y en líneas generales el mismo objetivo final.
En el ejercicio, el alumno debe mostrar que ambos ejemplos que presenta
tienen por objetivo la identificación de vulnerabilidades en la aplicación
“Marketplace”.
Si el enfoque que se da a la auditoría es SIN tener conocimiento previo del
entorno, nos encontramos ante una situación típica de realización de un test
de intrusión o un análisis de vulnerabilidades planteado desde el punto de
vista de un atacante externo.
Si por el contrario nos encontramos ante un enfoque en que la auditoría es
con conocimiento previo, existen muchas opciones pero la más habituales y
directa para identificar todas las vulnerabilidades sería la revisión de código
de la aplicación, que sería el paradigma de una auditoria en la que se tiene el
conocimiento absoluto sobre el entorno que se audita, y también dentro de
este mismo concepto tendríamos pruebas de verificación de configuraciones,
es decir repasar al detalle el modo en que el sistema está configurado para
verificar si se han seguido las mejores práctica en bastionado de sistemas
4
(protección de sistema operativo, aplicaciones de medidas de control de

acceso a recursos de sistema, correcta segmentación de privilegios de los
usuarios de las aplicaciones, etc. Existen múltiples guías de bastionado
disponibles en el mercado para ser tomadas de referencia por el equipo
auditor).
• Cuestión 4 – Planificación de una auditoría técnica

Imaginad que la empresa XXXX.SA descrita en el anexo, decide externalizar
alguna de las auditorías técnicas internas previstas en el Programa de
Auditoria, en concreto una cuyo alcance sea la verificación de la aplicación de
los controles técnicos sobre las redes de comunicación, en concreto de las
redes wifis, la segmentación y filtrado de tráfico a nivel 3/4 (capas de red y
transporte de la pila del conjunto de protocolos TCP/IP) y especialmente en
los puntos de interconexión con otras redes, las conexiones con redes de 3ª
partes mediante conexiones punto a punto o VPNs, y la protección de acceso
al nivel 2 (capa de interfaz de red según el modelo de protocolos TCP/IP).
En esta pregunta, suponed que sois el auditor jefe de la empresa auditora que
ha sido contratada. Vais a realizar la reunión de inicio del proyecto a la que
asistirán además del Responsable de Seguridad y el de Revisión Interna,
también estará el Comité de Seguridad en el que el conocimiento sobre
aspectos de seguridad en redes no son muy amplios.
En esta pregunta se os pide que expliquéis la planificación COMPLETA del
proyecto, es decir todas las fases desde la reunión de inicio que estáis
realizando hasta la finalización completa del proyecto. En cada una de las
fases deberéis describir someramente cuál es el objetivo y de manera general
las actividades que se realizarán.
Atención, NO se pide el PLAN de AUDITORIA con todas y cada una de las
pruebas que se van a realizar (a muchos de los interlocutores de la reunión
no les interesaría además de no entenderlo probablemente) sino una visión
general y completa del proyecto.
Como punto adicional para mejorar el resultado, el alumno puede ofrecer un
cronograma de actividades. No se evaluará si se ha estimado correctamente
la duración de las tareas puesto que se entiende que el alumno no tiene la
práctica profesional adecuada para estimarlo correctamente, pero si el
alumno plantea una estimación razonable será considerado muy
positivamente.

Punto 4 Planificación de una auditoría técnica de seguridad
5
Este punto es totalmente práctico y se podría dar diversos ejemplos. Pero en

líneas generales el alumno debe organizar las distintas fases en que
descompondrá el proyecto completo según lo mostrado en el cuadro “Proceso
General de una auditoría”, sin olvidar sobretodo la fase final de seguimiento
que es altamente recomendable que toda auditoría realice y que puede ser
tanto verificar que los problemas detectados se han resuelto como incluso dar
soporte para la resolución (aunque esto ciertamente podría poner más
adelante la independencia del equipo auditor para seguir auditando a esta
entidad).
6
Marcos de trabajo de las
auditorías de seguridad TIC
01 Presentación
Marcos de trabajo de las

02 auditorías de seguridad TIC
03 Solución PEC 4
-1-
Universitat Oberta
de Catalunya
Aula
Módulo 4 - Marcos de trabajo de las auditorías de seguridad TIC
Inicio: Fin:
11/04/22 01/05/22
00:00h 24:00h
Materiales
Marcos de trabajo de las auditorías de seguridad TIC

Audiolibro
ePub
Mobipocket
html5
Pdf
Marcos de trabajo
de las auditorías
de seguridad TIC
PID_00285948

© FUOC • PID_00285948 Marcos de trabajo de las auditorías de seguridad TIC



Producción: FUOC
© FUOC • PID_00285948 Marcos de trabajo de las auditorías de seguridad TIC
Índice
Introducción............................................................................................... 5
1. Metodologías y guías del NIST....................................................... 7

1.1. Marco de referencia de la FISMA (Federal Information
Security Management Act) .......................................................... 8
1.2. NIST SP 800 115 - Technical guide to Information Security
testing and assessment ................................................................ 13
2. Metodologías del movimiento de software libre....................... 19

2.1. ISECOM (Institute for Security and Open Methodologies) ......... 19
2.2. OWASP (Open Web Application Security Project) ...................... 21
2.2.1. OWASP Top ten vulnerabilities.......................................... 23
2.2.2. Estándar de verificación de seguridad para
aplicaciones web ............................................................ 28
2.2.3. OWASP - Web Security Testing Guide ........................... 32
2.2.4. Herramientas del OWASP .............................................. 35
2.3. PTES (penetration testing execution standard) ................................ 36
2.4. OISSG (Open Information Systems Security Group) .................. 37
3. Norma PCI - DSS................................................................................. 39

3.1. Mantenimiento del estándar PCI-DSS ........................................ 39
3.2. Requerimientos del estándar PCI-DSS ........................................ 42
3.3. Aplicabilidad del estándar PCI-DSS a la industria ...................... 43
3.4. Cumplimiento y auditoría del estándar PCI-DSS ....................... 45
4. Estándares de auditoría de la ISACA............................................ 50

4.1. COBIT .......................................................................................... 50
4.2. Reglamentación de la actividad de auditoría IT por ISACA ........ 55
4.2.1. Estándares de auditoría de la ISACA ............................. 55
4.2.2. Las guías o directrices de auditoría ............................... 58
© FUOC • PID_00285948 5 Marcos de trabajo de las auditorías de seguridad TIC
Introducción
Debido a la reciente importancia y notoriedad que han adquirido la seguridad

de los sistemas de información y la necesidad de asegurar que se está gestio-
nando correctamente tanto organizativamente como técnicamente, han sur-
gido gran número de iniciativas para ayudar a comprender los distintos aspec-
tos que componen una auditoría o incluso, más ambicioso, un programa de
auditoría completa de la seguridad de la información. La ambición y medios
con los que han contado las distintas organizaciones que los han promovido
varían mucho, por lo que tanto su detalle como el alcance de los aspectos que
tratan son muy variados, así como su evolución y mantenimiento a lo largo
del tiempo. En este apartado, no pretenderemos explicar exhaustivamente y
en detalle todos los marcos de trabajo en la materia que se han publicado y/o
estandarizado. Se pretende dar a conocer algunos de los más representativos,
conocidos y quizá con más proyección a fecha de hoy. Por consiguiente, nos
centraremos únicamente en un pequeño conjunto de ellos por la gran relevan-
cia con que cuentan hoy en día, y forma parte de la profesionalidad de cada
auditor estar al corriente de las novedades y evoluciones dentro de su sector.
El auditor tiene que conocer los marcos de trabajo más empleados en cada
momento por varios motivos. Por un lado, los clientes de auditoría desearán
tener un punto de referencia para conocer qué métodos o formas de trabajar
tiene el auditor y su grado de fiabilidad y el nivel de conocimiento de la evo-
lución de la industria de la seguridad de la información. Este respaldo se lo
proporcionará el hecho de ajustar su forma de trabajar, reflejada en un plan
de auditoría a los marcos de trabajo y las metodologías (cuando estas existan
en esos marcos de trabajo que escoja) que más se adecuen al alcance y tipo de
auditoría prevista, y por esta razón es un punto importante que se debe incluir
en el plan de auditoría, tal y como se ha comentado en anteriores módulos.
Asimismo, el conocimiento de los distintos marcos de trabajo es una herra-
mienta para que el auditor mantenga su nivel de formación al día en cuanto
a áreas de interés, nuevos marcos de control de la seguridad de la información
y evolución o nuevas formas de realizar pruebas de auditoría. Estos marcos de
trabajo que vamos a repasar son revisados y actualizados periódicamente, para
reflejar la evolución tanto de la tecnología como de los nuevos tipos de riesgos
a los que se enfrenta una infraestructura TIC y la información manejada por
las organizaciones modernas. Un auditor debe estar al corriente de la evolu-
ción de los mismos e ir adecuando sus procedimientos de trabajo propios a
esta evolución.
Por otra parte, se tendrá muy en cuenta que no se debe dar un crédito com-
pleto a estos marcos de trabajo, en el sentido de no pretender ajustar la forma
de trabajar completamente a las indicaciones que en ellos se den, salvo que
la asignación de la auditoría lo requiera explícitamente. Es difícil tanto que
estos marcos detallen todos los aspectos que se han de tener en cuenta en una
auditoría, como que los objetivos de auditoría del cliente estén completamen-
te alineados con los genéricos que pueden tener estos marcos de trabajo que
están fundamentados en modelos de referencia o mejores prácticas. En cada
asignación de auditoría, el auditor, antes de decidirse a aplicarlos total o par-
cialmente en un marco en concreto (o varios combinados), examinará en de-
talle en qué circunstancias son aplicables, cuáles son sus características y pun-
tos fuertes que los hacen relevantes y útiles para la asignación. Únicamente,
nos centraremos en un pequeño conjunto de ellas por la gran relevancia con
que cuentan hoy en día.
Es difícil abarcar en este módulo todos los marcos de trabajo relevantes para un
auditor de seguridad TIC, pero sí que existen ciertas iniciativas interesantes.
La gran mayoría de ellas hacen hincapié en los aspectos más técnicos, y pocas
hacen referencia de manera general a los aspectos organizativos de la seguridad
de la información. Las metodologías que examinaremos serán:
• Las metodologías y guías norteamericanas emitidas por el NIST relaciona-

das con la seguridad de la información (grupo de publicaciones especiales
SP 800).
• Las metodologías del movimiento de software libre con énfasis especial en

el proyecto OWASP.
• Las metodologías publicadas por las principales entidades emisoras de

tarjetas de crédito y aplicables a las organizaciones involucradas en las
transacciones de pago y que, por tanto, almacenan, procesan o transmiten
datos de tarjetas de crédito: payment card industry (PCI), data security stan-
dard, security audit procedures.
• Los estándares y guías de buenas prácticas publicadas por la ISACA (Infor-

mation Systems Audit and Control Association).
Insistimos finalmente de nuevo que es importante que un equipo auditor co-

nozca los marcos de trabajo ya publicados para ir formando su propia meto-
dología, y así diseñar la más apropiada al alcance y enfoque de cada auditoría
en concreto, para poder formalizarla en el documento de plan de auditoría.
1. Metodologías y guías del NIST
Para entender el contexto en que esta guía se aplica, se ha de comprender el

entorno que aplica a las agencias federales estadounidenses. Como en otros
países desarrollados, la Administración estadounidense ha comprendido que
es necesario garantizar la seguridad de la información manejada por los servi-
cios públicos para dar un servicio correcto y seguro a los ciudadanos al tratar
su información y en general la del gobierno del país. Para ello, en el año 2002,
se aprobó en Estados Unidos la "Federal Information Security Management
Act" (FISMA), que reconoce la importancia de la seguridad de la información
para la seguridad económica y nacional del país.
Esta ley obliga a todas las agencias federales a desarrollar un sistema de ges-
tión de la seguridad de la información, basado en una gestión del riesgo y un
proceso de mejora continua, fundamentado en revisiones anuales de la segu-
ridad. Es decir, les obligaba a todas las agencias (excepto las encargadas de la
seguridad nacional) a gestionar la seguridad de la información según los pa-
rámetros y el mecanismo que hemos estado repasando en este curso. En este
contexto, la FISMA otorga al NIST un papel importante. El NIST es una agen-
cia federal estadounidense de carácter público cuyo objetivo es la divulgación,
innovación y competitividad industrial mediante la promoción de la investi-
gación, para el establecimiento de patrones de medida (por ejemplo operan
el reloj atómico NIST-F1 que estable la hora oficial en el país) y el desarrollo
de estándares, guías y metodologías en casi todos los ámbitos de la ciencia.
Por lo tanto, el NIST está encargado de desarrollar estándares, guías, directri-
ces, métodos y técnicas, e incluso requerimientos mínimos aplicables a gran
número de distintos tipos de sistemas, incluidos los sistemas de información
y su seguridad.
En el marco del NIST existen múltiples suborganizaciones dedicadas cada una

a distintas áreas del conocimiento. Entre ellas, en lo referente a seguridad de
la información (o también llamado ciberseguridad), existe un centro específico
para esta temática, el Computer Security Resource Center (CSRC).
El CSRC facilita el intercambio y la divulgación de herramientas y buenas prác-

ticas de seguridad de la información, proporciona recursos sobre estándares de
seguridad de la información y directrices, e identifica los principales recursos
de seguridad en la red para apoyar a los usuarios en la industria, el gobierno
y el mundo académico.
En un principio, algunas de sus conclusiones y trabajos son elevados más ade-

lante a estándares federales (dentro de la familia de normas FIPS –federal infor-
mation processing standard– que son de obligada aplicación en el ámbito de la
Administración norteamericana. Pero también existen sus trabajos más gene-
rales de buenas prácticas (denominados SP-800 special publications serie 800)

que se encuentran disponibles para el público en general, y son una fuente
muy completa y fiable sobre distintos temas relacionados con la seguridad
de la información (reflejan los resultados de sus investigaciones y guías sobre
criptografía, infraestructuras de clave pública, sistemas de identificación y au-
tenticación, seguridad de redes de datos, seguridad en sistemas de control in-
dustrial, y también en gestión de la seguridad de la TIC). Por lo tanto, es in-
teresante su conocimiento por parte de los auditores de sistemas de informa-
ción para su aplicación en la medida en que resulte aplicable.
1.1. Marco de referencia de la FISMA (Federal Information

Security Management Act)
El NIST ha desarrollado todo un conjunto de documentos SP-800 con el objeto

de dar un marco de referencia completo a la gestión de la seguridad de la
Información que debe ser aplicado por las agencias norteamericanas debido a
la ley FISMA (Federal Information Security Management Act).
Es interesante conocerlo, puesto que es muy completo y ha pasado por el filtro

de una institución de reconocido prestigio y que dedica esfuerzos a mantener
actualizados sus guías y directrices. Además, trata ampliamente las fases de
revisión de la seguridad de la información, que es el objeto que nos ocupa.
El marco que se ha creado se puede resumir en las siguientes grandes directri-

ces:
• Categorización�de�los�sistemas�de�información (SP 800-60 Guide for Map-

ping Types of Information and Information Systems to Security Categories y FIPS
199 Standards for Security Categorization of Federal Information and Informa-
tion Systems). Se definen diferentes categorías de sistemas TIC de acuerdo
a los distintos niveles de riesgos para la confidencialidad, disponibilidad e
integridad. Da herramientas para categorizar y mapear distintos tipos de
información a estas categorías.
• Gestión�de�riesgos (SP 800-30 Risk Management Guide for Information Tech-

nology Systems). Se ofrece una guía para implantar un proceso completo
de gestión de los riesgos para asegurar la confidencialidad, disponibilidad
o integridad por su impacto en las operaciones de la organización. Ofre-
ce, por tanto, una metodología para realizar el análisis de riesgos (análisis
de las amenazas, vulnerabilidades sobre los sistemas TIC y los potenciales
impactos o daños), así como las subsiguientes fases de la gestión de la mi-
tigación del riesgo basándose en la evaluación del coste-beneficio y, pos-
teriormente, la revisión del análisis.
• Catálogo�de�controles�de�seguridad (SP 800-53 Recommended Security Con-

trols for Federal Information Systems y FIPS 200 Minimum Security Require-
ments for Federal Information and Information Systems). Este catálogo pro-
porciona directrices para asegurar los sistemas de información dentro del

Gobierno federal mediante la selección y especificación de los controles
de seguridad. Estas directrices de la NIST SP 800-53 son adecuadas para
todos los sistemas de información federales, con excepción de los sistemas
nacionales como los sistemas de seguridad, por lo que también pueden ser
considerados como válidos para otro tipo de organizaciones, aunque no
sean parte de la Administración pública estadounidense.
– Describe el proceso de selección y especificación de los controles de
seguridad de un sistema de información, y de definición de la organi-
zación general del enfoque de la gestión del riesgo de la organización.
– Describe el proceso de selección del conjunto inicial de los controles

de seguridad mejorado, partiendo de los resultados de la evaluación
de riesgos.
– Define el conjunto mínimo de controles de seguridad que deben apli-

carse para crear un eficaz programa de seguridad de la información.
– Proporciona directrices sobre la actualización de los controles, como

parte de un continuo y exhaustivo proceso de supervisión.
– Aporta aclaraciones sobre cómo la utilización de controles de seguri-

dad apoya la implantación de un programa de seguridad de la infor-
mación.
Es importante entender la amplitud de esta guía. La FISMA obliga a las

agencias federales a implantar los controles del FIPS 200 que están deri-
vados del NIST SP 800-53. Primeramente, deben categorizar, mediante el
FIPS199 (derivado del NIST SP 800-60), los distintos tipos de sistemas de
información que tengan y, posteriormente, aplicar los controles mínimos
(se denomina baseline) que se reflejen en el FIPS 200 para el nivel determi-
nado de acuerdo a las guías y directrices del NIST SP 800-53. Por tanto, este
documento es detallado en cuanto a dar una guía para la implantación,
pero no deja de ser un catálogo de controles similar, aunque más exhaus-
tivo, al ISO/IEC 27002 (de hecho, el mismo NIST facilita una tabla de co-
rrespondencia entre controles de la ISO 27002 y controles del SP 800-53).
Para organizaciones que no tienen relación con agencias federales de los
EE. UU., es un marco interesante de controles especialmente por su am-
plitud y buen desarrollo. Es un estándar que está en continua revisión y
que tiene por objetivo cubrir todo tipo de sistema, no sólo típicamente de
información, sino también aplicable en organizaciones que operen siste-
mas de control industrial, entornos Cloud, IT, etc. Para tener una visión
general de la amplitud del catálogo de controles que ofrece, es interesante
conocer que dispone de más de 1.000 controles organizados en 20 grupos
de alto nivel (o familias tal y como se menciona en el estándar):
– AC - Access Control
– AT - Awareness and Training
– AU - Audit and Accountability

– CA - Assessment, Authorization and Monitoring
– CM - Configuration Management
– CP - Contingency Planning
– IA - Identification and Authentication
– IR - Incident Response
– MA - Maintenance
– MP - Media Protection
– PE - Physical and Environmental Protection
– PL - Planning
– PM - Program Management
– PS - Personnel Security
– PT - PII Processing and Transparency
– RA - Risk Assessment
– SA - System and Services Acquisition
– SC - System and Communication Protection
– SI - System and Information Integrity
– SR - Supply Chain Risk Management
Para cada una de estas familias se definen controles de base (base controls)
y para algunos de ellos se definen mejoras del control (enhancement con-
trols). Para ilustrar el grado de detalle al que se llega en la precisión de los
controles, presentamos los controles que corresponden a la familia AT -
Awareness and Training:
Identificador Número Número de me- Nombre del control (o mejoras del control)
del control del control joras del control
AT 1 Policy and Procedures
AT 2 Literacy Training and Awareness
AT 2 1 Literacy Training and Awareness | Practical Exercises
AT 2 2 Literacy Training and Awareness | Insider Threat
AT 2 3 Literacy Training and Awareness | Social Engineering and

Mining
AT 2 4 Literacy Training and Awareness | Suspicious Communica-

tions and Anomalous System Behaviour
AT 2 5 Literacy Training and Awareness | Advanced Persistent Th-

reat
AT 2 6 Literacy Training and Awareness | Cyber Threat Environ-

ment
AT 3 Role-based Training
AT 3 1 Role-based Training | Environmental Controls
AT 3 2 Role-based Training | Physical Security Controls
AT 3 3 Role-based Training | Practical Exercises

Identificador Número Número de me- Nombre del control (o mejoras del control)
del control del control joras del control
AT 3 4 Role-based Training | Suspicious Communications and

Anomalous System Behaviour
AT 3 5 Role-based Training | Processing Personally Identifiable In-

formation
AT 4 Training Records
AT 5 Contacts with Security Groups and Associations
AT 6 Training Feedback
El grado de cobertura tanto en amplitud de áreas de interés como en pro-

fundidad y detalle de los controles, hacen de este catálogo de controles
uno de los más completos e interesantes para conocer por parte de un au-
ditor de seguridad de la información.
• Plan� de� seguridad� de� los� sistemas� TIC (SP 800-18 Guide for Developing
Security Plans for Federal Information Systems). Se introduce un plan de se-
guridad de los sistemas TIC que documente los requisitos de seguridad y
controles de seguridad implantados, o en previsión de serlo, para la pro-
tección de la información y los sistemas de información. También se re-
conoce que este tipo de documentos deben ser vivos y que requieren una
revisión periódica, una modificación, y planes de acción y de hitos para
la aplicación de controles de seguridad. Han de existir procedimientos de
evaluación que se esbozan en los planes, se ha de mantener el plan actual
y dar seguimiento a los controles de seguridad previstos.
• Certificación�y�posterior�verificación�y�revisión�continua (SP800-53A Antecedente SP 800-53A

Guide for Assessing the Security Controls in Federal Information Systems). Una
Antiguamente, existía el docu-
vez implantados los controles, éstos deben ser evaluados para comprobar mento "NIST-SP 800-26 Guide
que funcionan correctamente. Este proceso se realizará con anterioridad for Information Security Pro-
gram Assessments and System
a la puesta en producción (se denomina certificación) pero también, pos- Reporting Form", que incluía
un anexo con un detallado
teriormente, durante el ciclo de vida del mismo. Por lo tanto, el NIST SP cuestionario para ser comple-
tado por el auditado (o con la
800-53A es un documento para orientar la evaluación de una organización ayuda de un asesor o, en nues-
si cumple con el NIST SP 800-53, pero puede ser empleada como referencia tro caso, el equipo auditor), in-
dicando el nivel de implanta-
para auditores para evaluar con cualquier otro marco de controles. Uno de ción conseguido de cada uno
de los aspectos del marco de-
los principales objetivos de diseño es proporcionar un marco de evalua- finido por el NIST-SP 800-53.
ción inicial y un punto de partida para los procedimientos de evaluación Sin embargo, este documento
fue retirado por el NIST y susti-
continua, que son esenciales para lograr la coherencia de las evaluaciones. tuido por el documento NIST-
SP 800-53A.
– Proporciona directrices para la construcción de planes eficaces de au-
ditoría de la seguridad y procedimientos que permitan la evaluación
de los controles de seguridad utilizados.
– Describe el marco conceptual para la creación de procedimientos es-

pecíficos para la auditoría de los controles de seguridad del NIST SP
800-53.
– Ilustra los componentes de un marco de auditoría de la seguridad.
– Amplía y explica el proceso de derivar procedimientos de auditoría a

partir del marco de auditoría.
– Describe el proceso de auditoría de los controles de seguridad en la or-

ganización de sistemas de información, incluida la creación de prue-
bas de auditoría.
– Analiza las acciones necesarias para preparar una auditoría de seguri-

dad.
– Describe el proceso de análisis, documentación, informes y resultados

de la auditoría de la seguridad.
– Comunica la importancia de la continuidad de las auditorías de segu-

ridad para la protección a largo plazo.
Es interesante destacar que el NIST SP 800-53A da un conjunto de procedi-

mientos de auditoría para los distintos controles del NIST SP 800-53, pero
constituye en realidad un punto de partida para que los auditores desarro-
llen sus propios procedimientos y planes de auditoría basándose en esta
metodología. Adicionalmente a este marco, y partiendo del grado de ofi-
cialidad que da un documento SP, el NIST también facilita un conjunto de
caso de evaluación mucho más concreto y detallado para distintos tipos
de auditoría o, como ellos dicen, assessment cases.
• Acreditación (SP 800-37 Guide for the Security Certification and Accreditation Nota
of Federal Information Systems). El proceso de acreditación de la seguridad
Con la revisión 4 del
de un sistema TCI es el proceso por el cual un responsable de una agencia SP800-53, se introdujeron mo-
federal toma la decisión de autorizar el funcionamiento de un sistema de dificaciones que no fueron
trasladadas a los assessment ca-
información y, explícitamente, a aceptar el riesgo para el funcionamien- ses. Actualmente, el CSRC los
mantiene disponibles pero sólo
to de las agencias sobre la base de la aplicación de un conjunto acordado son aplicables a aquellos con-
troles que existían en la revi-
de controles de seguridad. Mediante la acreditación de un sistema de in- sión 3, pero tal y como el mis-
formación, se responsabiliza plenamente de cualquier impacto adverso en mo CSRC indica, estos pueden
ser tomados como referencia
caso de una violación de la seguridad. Por lo tanto, la responsabilidad y la para construir nuevos casos
adaptados a cualquier otro ti-
rendición de cuentas son principios fundamentales que caracterizan a la po de control.
acreditación de seguridad. Es esencial que los funcionarios que tienen que
tomar esta decisión tengan la más completa, precisa y fiable información
posible sobre el estado de seguridad de sus sistemas de información, con
el fin de hacerla oportuna y creíble, a partir del riesgo y las decisiones so-
bre la posibilidad de autorizar el funcionamiento de los sistemas. Esta guía
ofrece en detalle cómo ha de ser tanto el proceso de certificación como el
de acreditación.
Al auditor de seguridad le resultará especialmente interesante conocer el catá-

logo de controles del NISP SP 800-53, así como su relación con otros tipos de
catálogos como el ISO/IEC 27002. Este conocimiento y comparación le per-
mitará aplicar las recomendaciones dadas en el NIST SP 800-53A y los distin-
tos casos de auditoría (assessment case) que contienen valiosas informaciones
y ayudas pero que necesitarán de su pericia para adaptarlas a sus propios in-
tereses.
Estos documentos son mantenidos, por lo que se recomienda acudir al sitio

web mencionado para obtener la última versión y otros documentos que pu-
dieran haber sido publicados como anexos.
1.2. NIST SP 800 115 - Technical guide to Information Security

testing and assessment
Fuera del marco desarrollado por el NIST descrito anteriormente, también Nota
desarrolla otros tipos de documentos de orden más práctico. A este respecto,
Este documento sustituye al
destacaremos el NIST SP 800-115 - Technical guide to Information Security SP800-42 Guideline on Net-
testing and assessment. work Security Testing, que te-
nía un alcance más limitado.
Este documento es una guía que complementa al documento SP800-53A, que

es más oficial y está integrado en los mecanismos de control de la información
que ha diseñado el NIST para las organizaciones federales norteamericanas.
Sin embargo, esta guía es más generalista, describe aspectos técnicos básicos
que se deben tener en cuenta en la realización de evaluaciones de seguridad
de la información y es un material utilizable de manera más general por parte
de la comunidad de seguridad. Presenta métodos técnicos de pruebas, exáme-
nes, técnicas y aspectos de planificación y organización que una organización
podría utilizar como parte de una evaluación, además de informaciones para
los auditores sobre su ejecución y el impacto potencial que pueden tener en
los sistemas y redes. Por otra parte, hay que ser consciente de que, además
de la ejecución de las pruebas técnicas, hay otros factores ya comentados que
dan soporte para garantizar el éxito del proceso de evaluación y, en general,
aportar valor para mejorar la posición de seguridad de un sistema (y en última
instancia, de toda la organización). Algunos de estos otros factores también se
presentan en esta guía, como un proceso de planificación robusta, un análisis
de resultados y detección de las causas raíz de los problemas identificados, y
una correcta presentación de resultados.
Este documento facilita al auditor indicaciones sobre dos vertientes muy dife-
renciadas: por un lado, cómo organizar la actividad de auditoría y, por otro,
facilitar información sobre el tipo de acciones técnicas que puede desarrollar
un auditor para realizar sus pruebas de auditoría. En términos generales, esta
guía facilita tanto a las organizaciones auditoras como a las auditadas indica-
ciones sobre los siguientes aspectos:
• Desarrollar una política en la organización referente a la evaluación de la

seguridad, la metodología que se ha de emplear y los roles y responsabili-
dades individuales relacionados con los aspectos técnicos de la evaluación.
• Planificar con precisión para una evaluación técnica de seguridad de in-

formación, proporcionando una guía para determinar qué sistemas se uti-
lizan para evaluar y qué enfoque. Hacer frente a las consideraciones logís-
ticas que puedan proceder. Desarrollar un plan de auditoría y dar garantías
de que se han tomado en consideración los aspectos legales y de cumpli-
miento de otras políticas o normativas aplicables.
• Ejecutar de forma segura y con eficacia una evaluación técnica de seguri-

dad de información utilizando los métodos y las técnicas que se presentan,
y responder a cualquier incidente que pueda ocurrir durante la evaluación.
• Manejar adecuadamente los datos técnicos (recogida, almacenamiento,

transmisión y destrucción) en todo el proceso de evaluación.
• Realizar el análisis de resultados y elaborar los informes técnicos, así como

traducir los hallazgos en acciones de mitigación de riesgos que mejoren la
situación de seguridad de la organización.
Este documento no da una metodología concreta para realizar las evaluacio-

nes, pero determina que cualquiera que ponga en marcha una organización
debe contar con un mínimo de fases, y facilita información para definirlas:
1) Planificación
• Desarrollo de una política de evaluación de la seguridad que sea acorde

a las necesidades de la organización y esté debidamente respaldada por
la dirección para poder establecer roles, responsabilidades, periodicidades,
entregables que se han de realizar, etc.
• Planificación y priorización de asignaciones de acuerdo con la importancia

de los activos que hay que analizar, según su criticidad (por la misión que
cumple un determinado sistema o por la tipología de la información que
trate, por ejemplo, podría tratarse de datos personales muy sensibles como
salud, datos de tarjetas de crédito o información crítica para el negocio).
Se pueden establecer distintos requerimientos tanto en cuanto a los tipos
de evaluaciones como a las frecuencias, de manera que se optimicen los
recursos disponibles para realizar las evaluaciones.
• Determinación de los tipos de técnicas de evaluación de seguridad que se

deben emplear según los requerimientos que se han establecido en la pla-
nificación y priorización. Como veremos más adelante, algunas técnicas
pueden implicar ciertos riesgos a la hora de ejecutarlas, y ello debe tenerse

en cuenta en la planificación.
• Resolución de los aspectos logísticos de las evaluaciones, como la asigna-

ción de personas, desplazamientos, posible hardware que sea necesario,
licencias de herramientas, etc.
• Desarrollo y comunicación para cada asignación del correspondiente plan

de auditoría que detalle las actividades que se vayan a realizar.
2) Ejecución de la evaluación de acuerdo con la política establecida mediante

la realización de las distintas asignaciones de evaluación con arreglo a su co-
rrespondiente plan de auditoría previo. Durante la ejecución, es importante
tener en cuenta aspectos como la comunicación con las partes interesadas,
el escalado en caso de incidencias o el descubrimiento de problemas graves.
Por otro lado, esta fase conlleva en sí misma la realización de las pruebas y
su posterior análisis. En ocasiones, según el tipo de técnica empleada, esto
puede producirse de manera iterativa, puesto que el análisis de ciertos resulta-
dos puede determinar la necesidad o conveniencia de realizar nuevas pruebas
hasta conseguir los objetivos generales de la evaluación. Este sería el caso, por
ejemplo, en el que se realiza un test de intrusión. Asimismo, también se tiene
que tener especial cuidado con el modo en que se maneja la información re-
cogida durante la ejecución de pruebas, y debe existir un protocolo adecuado
para su manejo que cubra las distintas fases (recogida, almacenamiento, co-
municación y destrucción), puesto que la información recogida durante este
tipo de pruebas puede ser especialmente sensible.
3) Postejecución. La guía contempla que, con posterioridad a la ejecución y

al análisis de la información, existe una fase propia destinada a transmitir a
las partes interesadas los resultados mediante la elaboración de un informe
que contemple los hallazgos y también facilite recomendaciones para su mi-
tigación.
La implementación en una organización de una metodología que contenga

esas fases que contempla la guía ayudará a poder gestionar correctamente los
recursos necesarios (personas, herramientas, hardware, plazos de tiempo, fre-
cuencias, etc.) y, en general, los costes, así como a obtener los objetivos de
dichas evaluaciones de seguridad.
Un aspecto importante que se ha de tener en cuenta es que el documento está

orientado únicamente a la evaluación de la seguridad de sistemas de informa-
ción y redes de comunicación, y no a otros aspectos organizativos de la segu-
ridad de la información (este es el punto que lo hace claramente distinto del
SP800-53A). Es puramente técnico y, por lo tanto, aplicable a sistemas como
los siguientes:
• Elementos de interconexión. Por ejemplo: routers, interruptores (gestiona-

bles o no).
• Elementos de seguridad perimetral, como cortafuegos (tanto internos co-

mo externos), sistemas de detección o prevención de intrusos (IDS/IPS).
• Servicios típicos de red. Por ejemplo, servidores de nombres (DNS), servi-

dores de directorios (LDAP, Activedirectory, etc.), servidores de ficheros,
servidores web, servidores de correo electrónico (tanto servidores SMTP
como IMAP o POP3), y en general servidores de aplicaciones.
Una arquitectura típica que sería analizable, mediante las técnicas y pruebas
descritas en esta metodología, sería el diagrama que aparece en el siguiente
ejemplo de referencia de una arquitectura de red para auditar:
Esta guía plantea distintos tipos de técnicas de pruebas que se pueden realizar
para evaluar el modo en que una infraestructura cumple con los requerimien-
tos de seguridad. Estas técnicas pueden ser tanto pruebas como exámenes, y
la matización que introduce esta guía entre estos dos tipos es que las pruebas
suelen conllevar una interacción con los sistemas de información, mientras
que los exámenes acostumbran a relacionarse con la verificación del nivel de
implementación de un control de seguridad técnico de una manera indirecta
mediante observación, por ejemplo de la documentación, de ficheros de con-
figuración, de conjuntos de reglas, etc. Teniendo esto en cuenta, de manera

general la guía agrupa las distintas técnicas en las siguientes tres grandes ca-
tegorías:
1) Técnicas de revisión
• Revisión de documentación que describa arquitecturas de sistemas de in-

formación y de otros sistemas específicos de seguridad.
• Revisión de registros de actividad.
• Revisión de conjuntos de reglas (de cortafuegos, de IDS, de antivirus, en

general de cualquier sistema de seguridad que esté basado en reglas).
• Revisiones de configuraciones.
• Recogida y análisis de tráfico de red.
• Verificación de integridad de ficheros críticos.
2) Técnicas de identificación y análisis de objetivos
• Descubrimiento de sistemas conectados a la red.
• Identificación de puertos y servicios disponibles en los sistemas conecta-

dos a la red.
• Escaneo de vulnerabilidades.
• Escaneo en redes inalámbricas.
3) Técnica de verificación de vulnerabilidades
• Ataques contra contraseñas (por fuerza bruta o, más conveniente, por dic-
cionario).
• Test de intrusión.
• Ingeniería social (que se puede combinar con el test de intrusión para te-
ner una visión más realista de la posición general de seguridad de una or-
ganización).
Para cada una de estas categorías, la guía facilita información y sugerencias

sobre los aspectos que se deberán tener en cuenta a la hora de realizarlas. Es
importante tener presente que la guía no facilita información concreta sobre
el modo explícito en que se realizan las pruebas, pero sí facilita información
muy interesante para que el auditor pueda elaborar correctamente un plan de
auditoría y diseñar sus pruebas sin obviar todos los aspectos prácticos que cada
uno de estos tipos de pruebas puede conllevar, desde logísticos a cuestiones
de coordinación con el auditado.
2. Metodologías del movimiento de software libre
Otra fuente de información y referencia que cada día está recibiendo más cre-
dibilidad es el movimiento de software libre. Con una fecha de fundación re-
lativamente reciente, se han creado varias comunidades con unos objetivos,
cada uno de ellos ligeramente distintos, pero que, en lo referente a la audito-
ría técnica de seguridad en sistemas de información, ha aportado sus propios
marcos de trabajo y en ocasiones metodologías o guías para mejorar la seguri-
dad que el equipo auditor debe tener en cuenta a la hora de planificar la par-
te técnica de sus auditorías. Sin ánimo de desacreditar a otros movimientos,
proyectos y comunidades que también existen y que aportan su propia visión
de la actividad de auditoría, actualmente los movimientos que más destacan
son los siguientes:
2.1. ISECOM (Institute for Security and Open Methodologies)
El ISECOM es una comunidad de usuarios independientes, creada en el 2001, Enlace recomendado

constituida como una organización no gubernamental y sin ánimo de lucro
La versión 3.0 está publi-
cuyo objetivo es la concienciación, investigación y certificación en materia de cada, en inglés, en la URL
seguridad de los sistemas de información. Destaca por haber desarrollado una http://www.isecom.org/mi-
rror/OSSTMM.3.pdf
metodología (OSSTMM: open source security testing methodology manual) para la
auditoría de los sistemas de información. En su versión 3 cambió su visión,
que hasta entonces estaba orientada a dar una metodología de auditoría desde
la óptica de comprobar la seguridad de los sistemas frente a ataques realizados
por una tercera parte externa a la organización.
En la última revisión de este material hasta la fecha, la metodología ha evo-

lucionado aún más con el objetivo de proporcionar una valoración objetiva
de la seguridad operacional de una organización. OSSTMM pretende definir
un método de auditoría para determinar, de la manera más objetiva posible y
de modo cuantitativo, cómo de bien operan los controles de seguridad que se
han implantado para realmente proteger la información. Es decir, OSSTMM
se acerca más a una metodología de evaluación de riesgos para poder buscar
cómo evaluar la eficacia de los controles, no su simple cumplimiento de guías
de buenas prácticas, normas, documentación interna corporativa o aspectos
normativos de cumplimiento legal. La metodología busca ser lo más científica
y repetible posible con el objetivo final de evaluar numéricamente el grado de
eficacia del desempeño de la seguridad, y por esta razón consideramos que es
tanto una metodología de auditoría como también de evaluación de riesgo. La
ejecución de un test según OSSTMM facilita al final una puntuación (denomi-
nada RAV) que varía desde 0 hasta valores que pueden superar 100, cuando
100 representa que existe un balance óptimo entre los controles existentes y
cómo se opera frente a las amenazas reales, mientras que un valor por debajo
de 100 representaría una situación en la que los controles son ineficaces. Los
valores superiores a 100 indicarían situaciones en las que la complejidad de

los controles es superior al nivel óptimo y, además de incurrir en ineficiencia,
también pueden producirse problemas de gestión de los mismos que podrían
provocar, incluso, situaciones adversas para la seguridad. En este sentido y co-
mo se ha comentado, OSSTMM se acerca más a una metodología de análisis de
riesgos que a una metodología de auditoría de seguridad, puesto que el proceso
que establece es muy cerrado y orientado a la evaluación de distintos aspectos
con el objetivo final de realizar el cálculo del RAV. Una organización puede
emplear esta metodología para evaluar periódicamente el estado de la seguri-
dad, observar cómo evoluciona el nivel de eficacia de los controles y desarro-
llar planes para ajustarlos con el objetivo de acercarse al valor objetivo 100.
Por otro lado, al ser muy completa, tiene en cuenta casi todos los factores que
pueden incidir en la seguridad de la información, por lo que es una fuente de
información interesante para el auditor de seguridad TIC a la hora de realizar
sus propias metodologías.
Para ver el modo en que puede ser empleado por un auditor, hay que tener Enlace recomendado
presente que OSSTMM, conceptualmente, realiza un análisis muy metódico
La versión 3.0 está pu-
de un determinado entorno o alcance. El alcance se define como el conjunto blicada, en inglés, en la
de los activos que se quiere proteger y, a partir de ellos, también las personas, URL www.isecom.org/mi-
rror/OSSTMM.3.pdf
los procesos y los servicios que los emplean, los mecanismos de protección
que los afectan y los aspectos externos que los condicionan para el correcto
funcionamiento, como su ubicación, suministros, proveedores, normativas,
contratos, etc. Este alcance interactúa o, en cierta medida, se producen flujos
de información tanto dentro mismo del alcance como hacia el exterior, a tra-
vés de distintos niveles o, como la metodología denomina, canales en los que
se evalúa la seguridad y que OSSTMM clasifica del siguiente modo:
a) Nivel PHYSEC - Seguridad física. Puede ser por dos canales:
• Humano: referente a las implicaciones de las relaciones de confianza entre

las personas.
• Físico: referente a aspectos tangibles de seguridad (muros, cámaras, puertas

de acceso, etc.).
b) SPECSEC - Seguridad "radioeléctrica". Básicamente, todo lo referente a co-

municaciones inalámbricas, y también aspectos de seguridad de la informa-
ción que pueden ser relevantes, a través de emanaciones electromagnéticas
(emisiones de señales radioeléctricas quizá no intencionadas que pueden tener
implicaciones de seguridad).
c) COMSEC - Seguridad de las comunicaciones. En este aspecto, OSSTMM se-

para lo referente a los canales:
• Telecomunicaciones: cualquier aspecto relacionado con los sistemas de in-

formación relacionados con el transporte de voz (incluidos voz sobre IP,
centrales de conmutación y señalización, sistemas de registros de llama-

das, buzones de voz, etc.).
• Redes de datos: en este canal se contempla, en general, todo lo que se

entiende por sistema de información y comunicación, cuando su finalidad
no está relacionada con sistemas de voz.
Para evaluar la seguridad de los controles aplicados en cada uno de estos cinco
canales, la metodología que OSSTMM da es idéntica para cada uno de ellos
que sea relevante en los intercambios de información, y todos ellos pasan por
la evaluación de unos conceptos precisos. En la práctica, obviamente no se
evalúa del mismo modo cada uno de esos pasos, y es aquí donde OSSTMM
es una buena fuente de información para afrontar la evaluación de aspectos
para los que un auditor puede que no esté todavía perfectamente capacitado
y sobre los que necesite una visión sobre cómo auditar determinados aspectos
relevantes de la seguridad de una infraestructura TIC:
• Seguridad de la información existente sobre la organización en medios pú-

blicos, básicamente información publicada en Internet de manera inten-
cionada o no y relevante para la organización.
• Seguridad de los procesos en los que interviene el personal de la organiza-

ción, en búsqueda de evaluar en qué medida es susceptible de ser atacada
empleando técnicas de ingeniería social.
• Seguridad vista desde el punto de vista puramente técnico de los sistemas

de la organización expuestos en Internet.
• Seguridad vista desde el punto de vista puramente técnico de los sistemas

de comunicaciones de voz, incluido voz sobre IP.
• Seguridad vista desde el punto de vista puramente técnico de las comuni-

caciones inalámbricas, incluyendo redes Wi-Fi (802.11x), RFID, Bluetooth,
Infrarrojos, etc.
• Seguridad física vista desde el punto de vista puramente técnico.
2.2. OWASP (Open Web Application Security Project)
El OWASP es una comunidad de usuarios independiente y muy activa iniciada

en septiembre del 2001. Está constituida como una organización no guberna-
mental, sin ánimo de lucro, que tiene por objetivo facilitar a las organizaciones
la información y los medios para desarrollar, adquirir y mantener, de manera
segura, aplicaciones basadas en tecnologías de Internet, también llamadas co-
múnmente aplicaciones web y recientemente también se ha focalizado en las

aplicaciones móviles que interactúan con estas. Fundamentalmente, la inicia-
tiva facilita a la comunidad de seguridad TIC entregables de los distintos tipos:
• guías y/o documentación,
• herramientas,
• código para ser empleado en entornos productivos.
La visibilidad de esta iniciativa ha crecido enormemente en los últimos años

debido al auge del uso de tecnologías englobadas en lo que se conoce como
web applications, que ofrecen mejores niveles de estandarización e integración.
Hablamos de:
• Aplicaciones web con interfaces para usuario con independencia del so-
porte que empleen, ya sean ordenadores personales o dispositivos perso-
nales como tabletas o smartphones.
• Interfaces entre sistemas basados en tecnologías web como interfaces, lla-

mados webservices (distintas tecnologías como SOAP sobre HTTP, XML-
RPC, JSON-RPC, etc.).
• Aplicaciones en dispositivos móviles que interactúan con servicios web.
Por lo tanto, todos los documentos, metodologías y herramientas que el

OWASP facilita están orientados a la seguridad en el entorno de aplicaciones
web pero no describe técnicas para comprobar la seguridad de otros aspectos
en la gestión de la información, como procesos organizativos, continuidad de
negocio, seguridad física, etc.
Esta organización, al contrario que la ISECOM, afronta la seguridad sólo de las

aplicaciones web, pero desde todos sus aspectos del ciclo de vida, y considera
que sus recomendaciones se deben incluir desde las etapas iniciales del ciclo de
vida de un sistema. Por consiguiente, gran parte de sus esfuerzos se orientan en
definir las características que han de tener las aplicaciones web para garantizar
la seguridad de la información que tratan. En este sentido, la iniciativa OWASP
ha desarrollado a lo largo de los años muchos proyectos, algunos con más
éxito que otros, tanto debido al apoyo que han recibido por la comunidad
a la hora de continuar con su desarrollo como por su uso en el mundo real.
Actualmente, dentro de OWASP existe la tendencia a potenciar más la parte de
testing que la de diseño y, en ese sentido, es muy provechoso para un auditor de
seguridad TIC. Inicialmente, uno de sus proyectos estrella dentro del OWASP
fue la elaboración de una guía o manual que recoge estas características y que
puede ser empleada para diseñar, desarrollar, desplegar o auditar aplicaciones
web, y que está dirigida a arquitectos de sistemas, programadores, consultores
y auditores. Sin embargo, en los últimos años los proyectos destinados a la

comprobación de la seguridad han tenido mucho más apoyo y desarrollo por
parte de la comunidad.
A día de hoy, los proyectos más interesantes de esta comunidad a la hora de

facilitar información y herramientas al auditor de seguridad TIC son:
a) Documentación
• Estándares de verificación de seguridad: facilitan información en forma de

requerimientos tanto para desarrolladores y arquitectos que los emplearán
en el diseño de aplicaciones web y/o aplicaciones móviles, y para auditores
para la verificación de la completitud de sus planes de auditoría y consis-
tencia de sus resultados. Actualmente ofrece los siguientes:
– Application Security Verification Standard (ASVS)
– Mobile Application Security Verification Standard (MASVS)
• Guías para la realización de pruebas: contiene el conjunto de pruebas a

realizar para comprobar la seguridad de aplicaciones web y móviles. Estas
pruebas están relacionadas con los requerimientos descritos en los están-
dares de verificación de seguridad correspondientes. Actualmente están
publicados:
– Web Security Testing Guide (WSTG)
– Mobile Security Testing Guide (MSTG)
• Top Ten vulnerabilities: inicialmente creada para recopilar las diez vulnera-
bilidades que implican más riesgo en aplicaciones web pero actualmen-
te ampliada a otros entornos. Fundamentalmente se trata del OWASP Top
Ten, pero están en desarrollo otros catálogos más específicos para dar co-
bertura a otros tipos de aplicaciones web: OWASP Cloud-Native Application
Security Top 10 y OWASP Top 10 Low-Code/No-Code Security Risks.
b) Herramientas
• OWASP ZAP (Zed Attack Proxy).
• OWASP OWTF (Offensive Web Testing Framework).
• OWASP Modsecurity Core Rule Set.
2.2.1. OWASP Top ten vulnerabilities
Este proyecto no es, en sí mismo, ningún tipo de metodología, sino más bien
una herramienta para la educación y concienciación, en materia de seguridad,
en las aplicaciones web. Inicialmente se desarrolló orientado únicamente a
aplicaciones web pero recientemente se ha ampliado también a aplicaciones
web desarrolladas en entornos gráficos (denominados en OWASP como “low

code/no code”), y en aplicaciones nativas Cloud, aunque estos dos proyectos
están aún en sus inicios a fecha de actualización de este material.
El proyecto top ten tiene por objeto recoger el consenso al que ha llegado la
comunidad para identificar los diez fallos de seguridad más importantes que
se suelen cometer a la hora de diseñar una aplicación web. El público objetivo
de este top ten es muy amplio, por lo que el grado de detalle y modo de explicar
busca ser lo más didáctico posible. Se pretende, por medio de esta iniciativa,
que todas las partes involucradas en la gestión del ciclo de vida de una aplica-
ción web conozcan qué vulnerabilidades se deben evitar.
Por su simplicidad y facilidad de comprensión, se ha convertido en un refe-

rente de las vulnerabilidades que se deben evitar y es empleado, tanto por
clientes de auditorías como por los propios auditores, como referencia de los
objetivos que debe cumplir una auditoría que busque evaluar la seguridad de
una aplicación web. Este amplio espectro de uso hace que sea interesante o
casi imprescindible que un auditor de seguridad TIC lo conozca.
La última versión del 2021 recoge las siguientes vulnerabilidades (no se trata
de una traducción oficial al español, ya que a fecha de actualización de este
material todavía no se había realizado):
A01:2021 – Pérdida de control de acceso
El control de acceso aplica la directiva de tal manera que los usuarios no pueden actuar
fuera de sus permisos previstos. Este tipo de fallos generalmente conducen a la divulga-
ción, modificación o destrucción de información no autorizada de todos los datos o a la
realización de una función comercial fuera de los límites del usuario. Las vulnerabilida-
des comunes de control de acceso incluyen:
• Violación del principio de privilegios mínimos o denegación de forma predetermi-

nada, donde el acceso sólo debe otorgarse para capacidades, roles o usuarios particu-
lares, pero está disponible para cualquier persona.
• Omitir las comprobaciones de control de acceso modificando la URL (manipulación

de parámetros o navegación forzante), el estado interno de la aplicación o la página
HTML, o mediante una herramienta de ataque que modifica las solicitudes de API.
• Permitir ver o editar la cuenta de otra persona, proporcionando su identificador único

(referencias directas de objetos inseguras).
• Acceso a la API sin controles de acceso para POST, PUT y DELETE.
• Elevación de privilegios. Actuar como usuario sin haber iniciado sesión o actuar como
administrador cuando se inicia sesión como usuario.
• Manipulación de metadatos, como la reproducción o manipulación de un token de

control de acceso JSON Web Token (JWT), o una cookie o campo oculto manipulado
para elevar privilegios o abusar de la invalidación de JWT.
• La configuración incorrecta de CORS permite el acceso a la API desde orígenes no

autorizados/no confiables.
• Forzar la navegación a páginas autenticadas como usuario no autenticado o a páginas

privilegiadas como usuario estándar.
A02:2021 – Fallos criptográficos

Lo primero es determinar las necesidades de protección de los datos en tránsito y en re-

poso. Por ejemplo, las contraseñas, los números de tarjetas de crédito, los registros de
salud, la información personal y los secretos comerciales requieren protección adicional,
principalmente si esos datos caen bajo las leyes de privacidad, por ejemplo, el Reglamen-
to General de Protección de Datos (GDPR) de la UE, o regulaciones, como, por ejemplo,
la protección de datos financieros como PCI Data Security Standard (PCI DSS). Para todos
estos datos, hay que determinar aspectos como los siguientes, ya que su no implementa-
ción puede poner en riesgo su confidencialidad o integridad:
• ¿Se transmite algún dato en texto claro? Esto se refiere a protocolos como HTTP,
SMTP, FTP que también utilizan actualizaciones TLS como STARTTLS. El tráfico ex-
terno de Internet es peligroso. Verifique todo el tráfico interno, por ejemplo, entre
balanceadores de carga, servidores web o sistemas de backend.
• ¿Se utilizan algoritmos o protocolos criptográficos antiguos o débiles de forma pre-

determinada o en código más antiguo? Por ejemplo, PCI-DSS es muy explícito en las
versiones de TLS que son las aceptadas.
• ¿Están en uso las claves criptográficas predeterminadas, las claves criptográficas débi-
les generadas o reutilizadas, o falta la administración o rotación de claves adecuadas?
¿Las claves criptográficas se registran en los repositorios de código fuente?
• ¿No se aplica el cifrado, por ejemplo, faltan directivas de seguridad de encabezados

HTTP (navegador) o encabezados?
• ¿El certificado de servidor recibido y la cadena de confianza están validados correc-

tamente?
• ¿Los vectores de inicialización ignorados, reutilizados o no generados son lo suficien-

temente seguros para el modo de operación criptográfica? ¿Se utiliza un modo de
funcionamiento inseguro como el ECB? ¿Se utiliza el cifrado cuando el cifrado con
autenticación es más apropiado?
• ¿Se están utilizando contraseñas como claves criptográficas en lugar de emplear una
función de derivación de clave a partir de contraseñas?
• ¿Se utiliza la aleatoriedad con fines criptográficos que no fueron diseñados para cum-
plir con los requisitos criptográficos? Incluso si se elige la función correcta, ¿necesita
el desarrollador renovar la semilla generadora de la aleatoriedad? Y si no es así, ¿ha
sobrescrito el desarrollador la funcionalidad incorporada de renovación de la semilla
con una semilla que carece de suficiente entropía/imprevisibilidad?
• ¿Se utilizan funciones hash obsoletas como MD5 o SHA1, o se utilizan funciones hash
no criptográficas cuando se necesitan funciones hash criptográficas?
• ¿Se utilizan métodos de padding criptográfico obsoletos como PCKS número 1 v1.5?
• ¿Son explotables los mensajes de error criptográficos o la información del canal late-
ral, por ejemplo, en forma de ataques de tipo padding oracle?
A03:2021 – Inyección
Una aplicación con alguno de estos fallos es vulnerable a los ataques cuando:
• Los datos proporcionados por el usuario no son validados, filtrados o saneados por
la aplicación.
• Las consultas dinámicas o las llamadas no parametrizadas sin escape contextual se

utilizan directamente en el intérprete.
• Los datos hostiles se utilizan dentro de los parámetros de búsqueda de object relational
mapping (ORM) para extraer registros adicionales o confidenciales.
• Los datos hostiles se utilizan directamente o se concatenan. El SQL o comando con-

tiene la estructura y los datos malintencionados en consultas dinámicas, comandos
o procedimientos almacenados.
Algunas de las inyecciones más comunes son Cross Site Scripting (XSS), SQL, NoSQL, co-
mando OS, Object Relational Mapping (ORM), LDAP y lenguaje de expresión (EL) o inyec-
ción de Object Graph Navigation Library (OGNL). El concepto es idéntico entre todos los
intérpretes. La revisión del código fuente es el mejor método para detectar si las aplica-
ciones son vulnerables a las inyecciones. Se recomienda encarecidamente realizar prue-
bas automatizadas de todos los parámetros, encabezados, URL, cookies, JSON, SOAP y
entradas de datos XML. Las organizaciones pueden incluir herramientas de prueba de
seguridad de aplicaciones estáticas (SAST), dinámicas (DAST) e interactivas (IAST) en la
canalización de CI/CD para identificar los defectos de inyección introducidos antes de
la implementación de producción.
A04:2021 – Diseño inseguro
El diseño inseguro es una categoría amplia que representa diferentes debilidades, expre-
sadas como "diseño de control faltante o ineficaz". El diseño inseguro no es la fuente de
todas las demás categorías de riesgo top ten. Hay una diferencia entre el diseño inseguro y
la implementación insegura. Se diferencia entre defectos de diseño y defectos de imple-
mentación por una razón, tienen diferentes causas, raíz y remediación. Un diseño seguro
aún puede tener defectos de implementación que conducen a vulnerabilidades que pue-
den ser explotadas. Un diseño inseguro no se puede arreglar mediante una implemen-
tación perfecta, ya que, por definición, los controles de seguridad necesarios nunca se
crearon para defenderse contra ataques específicos. Uno de los factores que contribuyen
al diseño inseguro es la falta de perfiles de riesgo empresarial inherentes al software o
sistema que se está desarrollando y, por lo tanto, la falta de determinación de qué nivel
de diseño de seguridad se requiere.
A05:2021 – Configuración incorrecta de la seguridad
La aplicación puede ser vulnerable cuando:
• Falta una provisión de la seguridad adecuada en cualquier parte de la pila de aplica-

ciones o permisos configurados incorrectamente en los servicios en la nube.
• Se habilitan o instalan funciones innecesarias (por ejemplo, puertos, servicios, pági-

nas, cuentas o privilegios innecesarios).
• Las cuentas predeterminadas y sus contraseñas siguen habilitadas y sin cambios.
• El manejo de errores revela seguimientos de pila u otros mensajes de error demasiado

informativos a los usuarios.
• Para los sistemas actualizados, las características de seguridad más recientes están
deshabilitadas o no están configuradas de forma segura.
• La configuración de seguridad en los servidores de aplicaciones, marcos de aplicacio-

nes (por ejemplo, Struts, Spring, ASP.NET), bibliotecas, bases de datos, etc., no se es-
tablece en valores seguros.
• El servidor no envía encabezados o directivas de seguridad, o no están configurados

en valores seguros.
• El software está desactualizado o es vulnerable (consulte A06:2021 – Componentes

vulnerables y obsoletos).
Sin un proceso de configuración de seguridad de aplicaciones concertado y repetible, los

sistemas corren un mayor riesgo.
A06:2021 – Uso de componentes vulnerables u obsoletos
Es probable que la aplicación sea vulnerable:
• Si no conoce las versiones de todos los componentes que utiliza (tanto del lado del
cliente como del lado del servidor). Esto incluye los componentes que usa directa-
mente, así como las dependencias anidadas.
• Si el software es vulnerable, no es compatible o no está actualizado. Esto incluye el

sistema operativo, el servidor web/de aplicaciones, el sistema de administración de
bases de datos (DBMS), las aplicaciones, las API y todos los componentes, los entornos
de tiempo de ejecución y las bibliotecas.
• Si no analiza las vulnerabilidades con regularidad y se suscribe a boletines de seguri-

dad relacionados con los componentes que utiliza.
• Si no corrige o actualiza la plataforma, los marcos y las dependencias subyacentes de

manera oportuna y basada en el riesgo. Esto sucede comúnmente en entornos cuan-
do la aplicación de parches es una tarea mensual o trimestral bajo control de cam-
bios, dejando a las organizaciones abiertas a días o meses de exposición innecesaria

a vulnerabilidades fácilmente corregibles.
• Si los desarrolladores de software no prueban la compatibilidad de las bibliotecas ac-

tualizadas o parcheadas.
• Si no protege las configuraciones de los componentes (consulte A05:2021 – Configu-

ración incorrecta de seguridad).
A07:2021 – Errores de identificación y autenticación
La confirmación de la identidad, la autenticación y la administración de sesiones del

usuario es fundamental para protegerse contra los ataques relacionados con la autenti-
cación. Puede haber debilidades de autenticación si la aplicación:
• Permite ataques automatizados como el relleno de diccionario, donde el atacante

tiene una lista de nombres de usuario y contraseñas válidos.
• Permite la fuerza bruta u otros ataques automatizados.
• Permite contraseñas predeterminadas, débiles o conocidas, como "Password1" o "ad-

min/admin".
• Utiliza procesos débiles o ineficaces de recuperación de credenciales y contraseña

olvidada, como "respuestas basadas en el conocimiento", que no se pueden hacer
seguras.
• Utiliza almacenes de datos de contraseñas de texto sin formato, cifrados o con hash
débil (consulte A02:2021 – Errores criptográficos).
• No se emplea autenticación multifactor faltante o la implementación es ineficaz.
• Expone el identificador de sesión en la dirección URL.
• Reutiliza el identificador de sesión después de iniciar sesión correctamente.
• No invalida correctamente los ID de sesión. Las sesiones de usuario o los tokens de

autenticación (principalmente tokens de inicio de sesión único – SSO) no se invalidan
correctamente durante el cierre de sesión o un período de inactividad.
A08:2021 – Fallos de integridad del software o datos
Los fallos de integridad del software y datos se relacionan con el código y la infraestruc-
tura que no protegen contra violaciones de integridad. Un ejemplo de esto es cuando
una aplicación se basa en complementos, bibliotecas o módulos de fuentes, repositorios
y redes de entrega de contenido (CDN) que no son de confianza. Una pipeline de CI/
CD inseguro puede introducir la posibilidad de acceso no autorizado, código malicioso
o compromiso del sistema. Por último, muchas aplicaciones ahora incluyen la funciona-
lidad de actualización automática, donde las actualizaciones se descargan sin suficiente
verificación de integridad y se aplican a la aplicación de confianza anterior. Los atacan-
tes podrían cargar sus propias actualizaciones para distribuirlas y ejecutarlas en todas las
instalaciones. Otro ejemplo es cuando los objetos o datos se codifican o serializan en
una estructura que un atacante puede ver y modificar, y es vulnerable a la deserialización
insegura.
A09:2021 – Errores de registro y supervisión de seguridad
Su categoría es ayudar a detectar, escalar y responder a las brechas de seguridad activas.

Sin registro y monitoreo, las brechas no se pueden detectar. El registro, la detección, la
supervisión y la respuesta activa no se registran en ningún momento:
• Los eventos auditables, como los inicios de sesión, los inicios de sesión fallidos y las
transacciones de alto valor, no se registran.
• Las advertencias y los errores generan mensajes de registro no inadecuados o poco

claros.
• Los registros de aplicaciones y API no se supervisan en busca de actividades sospe-

chosas.
• Los registros sólo se almacenan localmente.

• Los umbrales de alerta apropiados y los procesos de escalamiento de respuesta no

están en su lugar o no son efectivos.
• Las pruebas de penetración y los análisis mediante herramientas (como OWASP ZAP)
de pruebas dinámicas de seguridad de aplicaciones (DAST) no activan alertas.
• La aplicación no puede detectar, escalar o alertar de ataques activos en tiempo real

o casi en tiempo real.
Es vulnerable a la fuga de información al hacer que los eventos de registro y alerta sean
visibles para un usuario o un atacante (consulte A01: 2021 – Pérdida de control de acceso).
A10:2021 – Server-Side Request Forgery (SSRF)
Los errores de SSRF se producen cada vez que una aplicación web obtiene un recurso
remoto sin validar la dirección URL proporcionada por el usuario. Permite a un atacante
obligar a la aplicación a enviar una solicitud diseñada a un destino inesperado, incluso
cuando está protegida por un firewall, VPN u otro tipo de lista de control de acceso a
la red (ACL).
A medida que las aplicaciones web modernas proporcionan funcionalidades a los usua-
rios finales, la obtención de una URL se convierte en un escenario común. Como resul-
tado, la incidencia de SSRF está aumentando. Además, la gravedad de SSRF es cada vez
mayor debido a los servicios en la nube y la complejidad de las arquitecturas.
Además de conocer el OWASP top ten, el auditor ha de conocer también las

técnicas para construir aplicaciones web seguras, así como las técnicas para
auditar el uso o implementación de estos controles.
2.2.2. Estándar de verificación de seguridad para aplicaciones

web
Inicialmente, el proyecto original de OWASP relacionado con la elaboración

de documentos fue la creación de una guía de desarrollo seguro de aplicacio-
nes web (OWASP Guide to building Security Web Applications and Web Services,
renombrada después a OWASP Developer Guide) pero actualmente ha evolucio-
nado hacia la redacción más sencilla de un conjunto de requerimientos a te-
ner en cuenta en el diseño e implementación de aplicaciones. El objetivo de
este cambio es facilitar a la comunidad un conjunto completo, riguroso y pro-
fesional de requerimientos que definan controles de seguridad que pueden ser
implementados en aplicaciones web. Esta evolución ha llevado a la retirada
de la OWASP Developer Guide y su sustitución por un documento de definición
de requerimientos, el OWASP Application Security Verification Standard (ASVS).
En sus inicios, este documento incluía requerimientos para aplicaciones mó-
viles pero, debido a su gran evolución, ha sido separado en un documento
aparte, el OWASP Mobile Application Security Verification Standard (MASVS). Nos
centraremos en este apartado en el ASVS.
El estándar es fundamentalmente utilizable tanto por desarrolladores como

por auditores y también por parte de personal que haga selección de producto
(denominado procurement en entornos anglófonos, o “proceso de compras” en
España). Estos requerimientos pueden ser tomados por:
• Desarrolladores: los distintos elementos del ASVS constituyen un catálogo

de controles que son recomendables de implementar y que pueden incluir
en su planificación de desarrollo de funcionalidades.
• Auditor de seguridad: el ASVS constituye la guía de los controles de segu-

ridad que son más recomendables implementar y, por lo tanto, será la base
para el desarrollo de su plan de auditoría.
• Responsables del proceso de compra: se podrán tomar los distintos ele-

mentos del estándar como cláusulas a incluir en un contrato o en un plie-
go técnico (o RFP – Request for Proposal, en inglés).
El ASVS define varios niveles a los que se aplican o no los requerimientos

concretos. Estos niveles son:
• ASVS Level 1: es el nivel más básico de controles y además son el conjunto

de controles que pueden ser verificados en una auditoría de estilo “Black
Box”, es decir, sin necesidad de tener acceso ni al código fuente ni a nin-
guna información adicional sobre la implementación concreta o su proce-
so de desarrollo y puesta en producción. Se trataría de pruebas conocidas
como dinámicas, o DAST – Dynamic Application Security Test.
• ASVS Level 2: este nivel ya es recomendable para las aplicaciones que ma-
nejan algún tipo de información sensible que debe ser protegida, transac-
ciones de negocio, información médica básica o en entornos que procesan
información que puede no ser confidencial pero que debe garantizar que
se impide su manipulación, como por ejemplo juegos online multiusuario.
En general, el estándar indica que este es el nivel recomendable para la ma-
yoría de las aplicaciones. Desde el punto de vista de una auditoría de segu-
ridad, la verificación de estos controles en ocasiones puede no ser posible
con pruebas de tipo “Black Box” y puede requerirse la realización, además
de pruebas DAST, también de revisiones estáticas de código o configura-
ciones, también conocidas como SAST – Static Application Security Test.
• ASVS Level 3: finalmente este nivel sólo es recomendable para aplicacio-

nes críticas que manejan información muy sensible como datos médicos,
financieros, entornos militares o de industrias en las que asegurar la segu-
ridad física de las personas es primordial, en general aquellas aplicaciones
con un nivel de clasificación muy elevado.
El catálogo de controles es muy amplio, organizado en estos grupos de control:
Objetivo de control Requerimiento
V1:�Architecture,�Design�and V1.1 Secure Software Development Lifecycle Requirements

Threat�Modelling�Require-
ments V1.2 Authentication Architectural Requirements
V1.3 Session Management Architectural Requirements
V1.4 Access Control Architectural Requirements
V1.5 Input and Output Architectural Requirements
V1.6 Cryptographic Architectural Requirements
V1.7 Errors, Logging and Auditing Architectural Require-

ments
V1.8 Data Protection and Privacy Architectural Requirements
V1.9 Communications Architectural Requirements
V1.10 Malicious Software Architectural Requirements
V1.11 Business Logic Architectural Requirements
V1.12 Secure File Upload Architectural Requirements
V1.13 API Architectural Requirements
V1.14 Configuration Architectural Requirements
V2:�Authentication�Verifica- V2.1 Password Security Requirements

tion�Requirements
V2.2 General Authenticator Requirements
V2.3 Authenticator Lifecycle Requirements
V2.4 Credential Storage Requirements
V2.5 Credential Recovery Requirements
V2.6 Look-up Secret Verifier Requirements
V2.7 Out of Band Verifier Requirements
V2.8 Single or Multi-factor One Time Verifier Requirements
V2.9 Cryptographic Software and Devices Verifier Require-

ments
V2.10 Service Authentication Requirements
V3:�Session�Management�Veri- V3.1 Fundamental Session Management Requirements

fication�Requirements
V3.2 Session Binding Requirements
V3.3 Session Logout and Timeout Requirements
V3.4 Cookie-based Session Management
V3.5 Token-based Session Management
V3.6 Re-authentication from a Federation or Assertion
V3.7 Defences Against Session Management Exploits
V4:�Access�Control�Verification V4.2 Operation Level Access Control

Requirements
V4.3 Other Access Control Considerations
V5:�Validation,�Sanitization V5.1 Input Validation Requirements

and�Encoding�Verification�Re-
quirements V5.2 Sanitization and Sandboxing Requirements
V5.3 Output Encoding and Injection Prevention Require-

ments
V5.4 Memory, String, and Unmanaged Code Requirements
V5.5 Deserialization Prevention Requirements
V6:�Stored�Cryptography�Veri- V6.1 Data Classification

fication�Requirements
V6.2 Algorithms
V6.3 Random Values
V6.4 Secret Management
V7:�Error�Handling�and�Log- V7.1 Log Content Requirements

ging�Verification�Require-
ments V7.2 Log Processing Requirements
V7.3 Log Protection Requirements
V7.4 Error Handling
V8:�Data�Protection�Verifica- V8.1 General Data Protection

tion�Requirements
V8.2 Client-side Data Protection
V8.3 Sensitive Private Data
V9:�Communications�Verifica- V9.1 Client Communications Security Requirements

tion�Requirements
V9.2 Server Communications Security Requirements
V10:�Malicious�Code�Verifica- V10.1 Code Integrity Controls

tion�Requirements
V10.2 Malicious Code Search
V10.3 Deployed Application Integrity Controls
V11:�Business�Logic�Verifica- V11.1 Business Logic Security Requirements

tion�Requirements
V12:�File�and�Resources�Verifi- V12.1 File Upload Requirements

cation�Requirements
V12.2 File Integrity Requirements
V12.3 File Execution Requirements
V12.4 File Storage Requirements
V12.5 File Download Requirements
V12.6 SSRF Protection Requirements
V13:�API�and�Web�Service�Ve- V13.1 Generic Web Service Security Verification Require-

rification�Requirements ments
V13.2 RESTful Web Service Verification Requirements
V13.3 SOAP Web Service Verification Requirements

V13.4 GraphQL and other Web Service Data Layer Security

Requirements
V14:�Configuration�Verifica- V14.1 Build

tion�Requirements
V14.2 Dependency
V14.3 Unintended Security Disclosure Requirements
V14.4 HTTP Security Headers Requirements
V14.5 Validate HTTP Request Header Requirements
2.2.3. OWASP - Web Security Testing Guide
Dentro del ámbito del OWASP, se ha desarrollado el proyecto OWASP - Web

Security Testing Guide con el objeto de proporcionar un marco completo para
la auditoría/pruebas de aplicaciones web. Desde su creación (hasta la fecha se
encuentra ya en su versión 4), este ha sido uno de los proyectos de OWASP que
más apoyo ha conseguido, y ha hecho que su contenido haya evolucionado, se
haya refinado y mantenido actualizado con la evolución de la tecnología y los
escenarios reales de riesgos. Esta guía, pretende ser una referencia para que las
organizaciones lo empleen e integren con sus propias metodologías o formas
de trabajo. En este sentido, este material puede ser empleado por el equipo
auditor para desarrollar su propio plan de auditoría, lo que facilitará esta tarea.
La metodología está claramente dividida en dos partes que han sido desarro-
lladas de manera sucesiva pero que, a partir de la última versión, se han com-
binado en un único documento.
En�una�primera�parte, se describe un marco de referencia que abarca las dis-

tintas tareas y técnicas de prueba más apropiadas a cada fase del ciclo de vida
de una aplicación. En este sentido, describe de manera general, como posibles
técnicas para realizar la auditoría de aplicaciones web, las siguientes:
• Inspecciones�y�revisiones�manuales. Tareas realizadas personalmente por

los auditores mediante consulta de documentación, la entrevista a perso-
nal clave, o realización de pruebas específicas sobre la aplicación.
• Realización�de�análisis�de�riesgos. Para estimar correctamente el impacto

de las vulnerabilidades detectadas, se deberá aplicar algún tipo de meto-
dología de análisis de riesgos como las que ya se han comentado en mó-
dulos anteriores a este.
• Revisiones�de�código. Examen detallado de partes del código de una apli-

cación.
• Pruebas�de�intrusión. Realización de pruebas en modo caja negra en un

sistema en producción o preproducción.
Otro de los aspectos que el marco de referencia muestra es el tipo de pruebas a

realizar según el punto en que se encuentre la aplicación dentro de su ciclo de
vida. De nuevo, el modelo de ciclo empleado es similar al empleado también
por el NIST. Dependiendo de la fase en que se encuentre la aplicación, propone
una serie de comprobaciones a realizar:
• Fase�1.�Inicio
– Revisión de las políticas y estándares aplicables.
– Revisión de los criterios de medición de los factores de funcionamiento

de la aplicación que deberán ser empleados para medir la eficacia de
la aplicación.
• Fase�2.�Definición�y�diseño
– Revisión de los requerimientos de la aplicación para comprobar la co-
rrecta inclusión de los requerimientos de seguridad (se empleará la guía
OWASP que detalla los requerimientos recomendados).
– Revisión de los diseños de arquitectura.
– Revisión de los casos de uso de la aplicación.
– Realización de un análisis de riesgos de la aplicación empleando los

requerimientos, el diseño de arquitectura y los casos de uso.
• Fase�3.�Desarrollo
– Revisión de código: para revisar la lógica de la aplicación y de bajo
nivel para detectar posibles vulnerabilidades, como las detalladas en
la guía OWASP.
• Fase�4.�Despliegue
– Prueba de intrusión en la aplicación en preproducción, como fase fi-
nal del despliegue y como parte del conjunto de las pruebas para la
aceptación del sistema.
– Revisión de la configuración de la aplicación.
• Fase�5.�Operación�y�mantenimiento
– Revisión del proceso de operación y mantenimiento para comprobar

que, desde el punto de vista puramente operativo, no se están come-
tiendo errores.
– Revisión periódica de la aplicación.
– Revisión de las actualizaciones.
En�su�segunda�parte, la metodología descrita por la OWASP - Testing guide es

la dedicada a la descripción técnica de las pruebas a realizar en una aplicación
para la comprobación de las vulnerabilidades más importantes, por lo que
no puede ser considerada una lista completa y cerrada de todas las pruebas a
realizar, aunque sí una muy completa. Esta lista ha de ser considerada como
un catálogo de pruebas y una fuente de información para el equipo auditor
a la hora de diseñar en detalle las pruebas a realizar e incluir en su plan de
auditoría de aplicaciones web. Las pruebas están orientadas a la realización de
pruebas de aplicaciones en modo de caja negra, y se organizan en las siguientes
categorías:
• Información sobre la aplicación revelada públicamente, sin ejecución de

ningún tipo de interacción fuera del uso habitual de la misma o de la
búsqueda en Internet.
• Aspectos de seguridad en la configuración de la plataforma.
• Proceso de gestión de la identidad de los usuarios de la aplicación.
• Proceso de gestión del proceso de autenticación.
• Proceso de gestión del marco de autorización.
• Proceso de gestión de la sesión de usuario.
• Validación de los datos de entrada.
• Manejo de errores.
• Uso de la criptografía.
• Lógica de negocio (este es uno de los aspectos a veces olvidados en las au-
ditorías y hace referencia al posible abuso de la lógica de negocio imple-
mentada por la aplicación, y no tanto a errores de programación).
• Revisión de los aspectos de seguridad en el lado cliente.

• Revisión de webservices empleados en aplicaciones móviles.
• Revisión de aspectos de seguridad específicos de entornos desplegados e

infraestructuras en la nube.
• Revisión de la preparación de la aplicación frente a ataques de denegación

de servicio.
Como se puede comprobar, el catálogo de pruebas que ofrece es muy amplio, y

el equipo auditor debe ajustar al alcance determinado el conjunto de pruebas
a realizar.
Finalmente, la guía también facilita indicaciones sobre la elaboración del in-

forme en el que se han de presentar los resultados.
2.2.4. Herramientas del OWASP
Además del propio contenido de la guía, el OWASP también promociona la

creación de herramientas bajo licencia GPL para el estudio y prueba de apli-
caciones web. En este sentido, hay varias iniciativas interesantes por su nivel
de desarrollo alcanzado corresponden a:
• OWASP ZAP (Zed Attack Proxy). Es una herramienta eminentemente para

la auditoría de aplicaciones web y es básica para la realización de pruebas
de auditorías web. Es un proxy local con funcionalidades de análisis de
seguridad que el auditor emplea para monitorizar, analizar, interceptar y
manipular cualquier parte de los parámetros de una comunicación HTTP
entre el navegador cliente y la aplicación web. Mediante este análisis, el
auditor puede evaluar el comportamiento de la aplicación y ejecutar gran
número de las pruebas diseñadas en el plan de auditoría. Es una herra-
mienta muy flexible y versátil que permite su ampliación con módulos,
algunos de los cuales permiten la automatización de ciertos tipos de prue-
bas.
• OWASP OWTF (Offensive Web Testing Framework). Se trata de una aplica-

ción web modular para ayudar a los auditores de aplicaciones web a uni-
ficar el entorno de ejecución de pruebas.
• OWASP ModSecurity CRS (Core Set Ruleset). ModSecurity es una herra-

mienta de código abierto de seguridad WAF (web application firewall) que
analiza el tráfico HTTP para detectar y, según el modo en que esté operan-
do, bloquear el tráfico en caso de identificar algún patrón de ataque. Es
una herramienta basada en patrones o signaturas. Este proyecto OWASP
proporciona un conjunto de reglas para la identificación de ataques de
distintas categorías.
2.3. PTES (penetration testing execution standard)
Dentro de las actividades de auditoría de seguridad en sistemas de informa-

ción, la realización de un test de intrusión (o penetration test en inglés) es uno
de los tipos de pruebas que, de manera más realista, evalúa la situación de
la seguridad de una infraestructura TIC, aunque no lo realiza de manera sis-
temática para todos los controles. A pesar de no facilitar la visión exhaustiva
de la situación de todos los controles en sus resultados, es una actividad que
en el mercado de la seguridad de la información se emplea como ejercicio de
prueba real de la eficacia global y combinada de los controles de seguridad, y
también de los equipos que los operan, en caso de que se hagan con su desco-
nocimiento. Por esta razón, son herramientas muy populares para aumentar,
sobre todo, la concienciación en capas directivas de la organización y además,
en algunos casos, para la obtención y el mantenimiento de determinadas cer-
tificaciones que requieren de la realización periódica de este tipo de prueba de
auditoría de seguridad TIC, por ejemplo PCI.
Ya se han comentado anteriormente distintas metodologías o marcos de traba- Enlace recomendado

jo a partir de los cuales un equipo auditor puede preparar su propia metodolo-
La página web de este pro-
gía de test de intrusión. Sin embargo, existe una iniciativa de la comunidad de yecto se encuentra en:
seguridad que busca facilitar una metodología uniforme y consensuada para la http://www.pentest-
standard.org/
ejecución de este tipo de pruebas. Es la llamada PTES (penetration testing execu-
tion standard). Sin estar explícitamente respalda por ningún fabricante ni gru-
po de desarrolladores de herramientas de seguridad conocidas, es importante
notar que esta metodología se emplea en materiales de divulgación generados
por organizaciones tan conocidas como Offensive Security (respaldada por la
empresa Offsec Services Ltd.) o por colaboradores de PTES que son o fueron
miembros de Rapid7, actualmente propietaria de la conocida herramienta de
pentesting Metasploit.
Hasta el momento, la metodología PTES no es un estándar oficial respaldado

por ninguna entidad de estandarización, sino una iniciativa gobernada desde
el espíritu de los movimientos colaborativos de Internet, y no tiene en sí mis-
ma la vocación de convertirse en un estándar oficial (al menos según decla-
ran sus principales promotores). Por el contrario, pretende obtener un estatus
de estándar de facto que quizá pueda ser empleado por otros estándares más
oficiales.
El estándar PTES está aún en fase de desarrollo en algunas de sus partes, pero
por su contenido es interesante que los equipos auditores lo conozcan para
poder desarrollar sus propios planes de auditoría o metodologías de trabajo
cuando la asignación que reciban sea realizar un test de intrusión. El trabajo
realizado en el proyecto PTES es muy ambicioso, puesto que pretende abarcar
todas las fases de un proyecto de test de intrusión, desde las iniciales de con-
tacto con el auditado y cliente del proyecto, hasta las finales de presentación
de resultados. Abarca las siguientes fases de un proyecto de test de intrusión:
1) Interacciones iniciales (corresponde a las acciones necesarias para establecer

tanto con el auditado como con el cliente de la auditoría todos los elementos
relevantes para el trabajo por desarrollar en la asignación de auditoría).
2) Recogida de inteligencia (entendiendo inteligencia como la información

relevante y procesada respecto al objetivo obtenida de manera no intrusiva).
3) Modelado de amenazas.
4) Análisis de vulnerabilidades.
5) Explotación de vulnerabilidades.
6) Postexplotación de vulnerabilidades.
7) Elaboración de informe de resultados.
Aunque no todos sus apartados están igualmente desarrollados, los más téc-
nicos (del 2 al 6) proporcionan un nivel de detalle y referencias externas sufi-
cientes para que el auditor pueda elaborar su propia metodología y también
seleccionar las herramientas adecuadas. Algunos apartados importantes, como
el 7, dedicado al reporte de los resultados, son muy escuetos y necesitan am-
pliación, aunque lo esencial está disponible.
2.4. OISSG (Open Information Systems Security Group)
Por último, merece la pena mencionar al OISSG como otro proyecto enmarca-
do dentro del conjunto de metodologías surgidas del movimiento de software
libre para proporcionar herramientas de auditoría de sistemas.
El OISSG es una comunidad de usuarios independientes, constituida como una

organización no gubernamental sin ánimo de lucro, que tiene por objetivo
facilitar a la comunidad información relevante en materia de evaluación de la
seguridad de la información mediante la publicación de guías, metodologías
y herramientas.
El OISSG destaca por ser un marco de referencia para las pruebas de seguridad
denominado ISSAF�(information�systems�security�assessment�framework).
La diferencia con otros marcos de referencia radica en el gran número de prue-
bas que propone y el gran número de entornos que han sido previstos. Sin em-
bargo, tiene el problema de encontrarse todavía en una fase reciente de desa-
rrollo, con lo que algunos aspectos no están completamente desarrollados. A
fecha de finales del 2021, existe una versión del documento en su versión 1,
aunque se tiene que considerar todavía como un borrador, ya que varios de los
apartados están incompletos o no han sido mantenidos al día en lo relativo
a los aspectos tecnológicos (por ejemplo, los apartados referentes a Microsoft
Windows solo hacen referencia a las versiones NT, 2000 y 2003, aunque mu-
cho del material explicado es totalmente aplicable a versiones más modernas
de este sistema operativo).
El hecho de que esté todavía en fase de desarrollo reduce, en gran medida,

la aplicabilidad de la metodología de modo íntegro. No obstante, es una ex-
celente fuente de información para que el equipo auditor prepare el plan de
auditoría y el diseño de las pruebas a realizar.
3. Norma PCI - DSS
Las principales empresas líderes en el mercado de las tarjetas de crédito (Ame-

rican Express, Discover Financial Services, JCB, MasterCard Worldwide, y Visa
International) han tenido siempre un interés por la protección de la informa-
ción de los datos contenidos en las tarjetas y en las transacciones. Todas han
elaborado, por separado, sus propios programas para concienciar a sus comer-
cios y clientes en materia de seguridad. Quizá el más activo haya sido Visa,
pero finalmente todas ellas han colaborado para la elaboración de un estándar
de seguridad que armonice cada uno de estos programas y que sirva, de una
manera conjunta, para la protección de los datos personales de los titulares
de la tarjetas y de la propia información de las tarjetas. El estándar que han
definido se denomina Payment�Card�Industry�Data�Security�Standard�(PCI
DSS). Para coordinar y armonizar sus distintos programas de seguridad y mos-
trar más independencia, estas empresas han creado la organización PCI�Secu-
rity�Standards�Council, con los objetivos de dar soporte a la aplicación del
estándar PCI DSS mediante la publicación de las herramientas (básicamente
guías) para la implementación del estándar, e igualmente mantener y desarro-
llar el propio estándar. Además del mencionado estándar, el consejo desarro-
lla otras actividades que también pueden ser del interés para el auditor y que
merecen su atención.
Otras actividades que desarrolla el consejo
• Listado de requerimientos de seguridad y técnicas para su evaluación, para dispositi-

vos de introducción de número personal secreto (PIN Entry Device, que pueden ir
desde cajeros automáticos, también conocidos como ATM, puntos de ventas infor-
matizados), que recoge un conjunto único de requerimientos aplicables a los fabri-
cantes para poder proteger información crítica manejada en estos dispositivos, como
PIN, datos del titular de la tarjeta, etc. Asimismo, también ofrece un listado de los
fabricantes y dispositivos que cumplen con este estándar, y también laboratorios au-
torizados para realizar las pruebas.
• Estándar para la seguridad de las aplicaciones de pago. Con el fin de garantizar que
las aplicaciones desarrolladas por un tercero y empleadas por comerciantes o provee-
dores de servicios cumplen con los requerimientos del PCI-DSS, se ha desarrollado
este estándar y el listado de aplicaciones.
• Mantenimiento del listado de asesores de seguridad cualificados (QSA: qualified se-

curity assessor) para realizar revisiones de la implantación del PCI-DSS, así como de
los proveedores de servicios de análisis de vulnerabilidades (ASV: approved scanning
vendor).
3.1. Mantenimiento del estándar PCI-DSS
Indudablemente, el principal trabajo del PCI-SS Council es el mantenimiento

del estándar PCI-DSS.
El PCI DSS es un estándar que está en continua revisión y, a fecha de elabora-

ción de este material, la última versión publicada era la 3.2, de abril de 2016,
pero anualmente puede recibir pequeñas revisiones y actualizaciones. Sin em-
bargo, su objetivo se mantiene desde un inicio y consiste en facilitar un am-
plio conjunto de requerimientos para mejorar la seguridad de los datos rela-
cionados con las tarjetas de crédito. A partir de la edición de la versión 2 del
estándar PCI-DSS, el PCI SS Council decidió adoptar un modelo de revisión
constante del estándar para poder garantizar que se vaya adecuando al pano-
rama de amenazas contra la industria de las tarjetas de crédito, y también que
vaya beneficiándose de las mejoras tecnológicas que se van introduciendo.
Para ello, se ha definido un modelo de revisión para PCI-DSS y PA-DSS de tres
años con ocho fases consecutivas que aseguran una introducción gradual de
nuevas versiones y permiten a las organizaciones no quedarse fuera de cum-
plimiento por un cambio de versión.
El gráfico siguiente muestra las distintas fases (se trata de una combinación
entre fases e hitos).
Fuente: PCI Security Standards Council
• Fase 1 (hito): el estándar se publica a finales del mes de octubre. Es com-

pletamente vigente, pero las organizaciones no están obligadas a imple-
mentarlo hasta que no se haga efectivo.
• Fase 2 (hito): el nuevo estándar se hace efectivo. A partir de este momen-

to, las organizaciones deben emplear la nueva versión, pero existe un pe-
riodo de gracia de cuatro meses para pasar de una a otra y, durante este
periodo, las organizaciones pueden todavía mostrar su cumplimiento del
estándar empleando la versión antigua. Sin embargo, es recomendable que

cualquier modificación de controles de seguridad se realice con el nuevo
estándar como referencia.
• Fase 3 (fase): el primer año (desde la publicación) se considera el periodo

de implementación. Durante esta fase las organizaciones (tanto las que
deben implantar los controles como los QSA) deben familiarizarse con el
nuevo estándar e implantar los sistemas de información de acuerdo con
la nueva versión. Es un periodo en que toda la industria de las tarjetas de
crédito observa el estándar en su funcionamiento.
• Fase 4 (fase): en octubre del año 1 de vigencia del nuevo estándar, se inicia
oficialmente el periodo de revisión, que finalizará a finales de marzo del
año 2. Todas las partes interesadas tienen la posibilidad de enviar al PCI
SS Council sus comentarios y sugerencias, especialmente en todo aquello
que pueda hacer referencia a aspectos tecnológicos o de amenazas a los
datos de tarjetas de crédito.
• Fase 5 (hito): el 31 de diciembre del año 2 se retira la versión anterior

y las organizaciones solo podrán mostrar el cumplimiento del estándar
mediante la versión vigente.
• Fase 6 (fase): el PCI SS Council inicia oficialmente la revisión de todos los

comentarios recibidos a la nueva versión. Típicamente, el proceso consis-
te en evaluar la idoneidad del comentario o sugerencia e incorporarlo o
elaborar una revisión categorizándola como "Aclaración", "Guía adicional"
o "Requisito evolucionado". Este periodo comprende de abril a agosto del
año 2.
• Fase 7 (fase): desde el final de la fase de revisión de las sugerencias de la

comunidad hasta finales de abril del año 3, internamente el PCI SS Council
elabora el borrador de una posible nueva versión.
• Fase 8 (fase): en la última fase, el PCI SS Council comparte el borrador del

nuevo estándar con un panel de asesores para realizar una última revisión
y un ajuste del texto. Este periodo va de mayo a finales de julio del año 3.
De esta manera, el PCI SS Council garantiza que el estándar esté siempre ali-
neado con las mejores prácticas de seguridad y tecnología del mercado.
3.2. Requerimientos del estándar PCI-DSS
Desde un punto de vista global, podemos decir que el estándar PCI-DSS trata
temas como la gestión de la seguridad, políticas y procedimientos, arquitectura
de redes, y diseño de software. Su contenido es sencillo y está estructurado en
los siguientes seis objetivos de control y un total de doce requerimientos de
seguridad de alto nivel:
• Construir�y�mantener�una�arquitectura�de�red�segura
– Requerimiento 1. Instalar y mantener una infraestructura firewall para
proteger los datos de los titulares de las tarjetas.
– Requerimiento 2. No emplear los valores por defecto facilitados por
los fabricantes para sistemas de identificación u otros sistemas de se-
guridad.
• Proteger�los�datos�de�los�titulares�de�tarjetas
– Requerimiento 3. Proteger los datos almacenados de las tarjetas.
– Requerimiento 4. Cifrar la transmisión de datos de tarjetas por medio
de redes públicas.
• Mantener�un�programa�de�gestión�de�las�vulnerabilidades
– Requerimiento 5. Emplear y actualizar regularmente software antivi-
rus.
– Requerimiento 6. Desarrollar y mantener sistemas y aplicaciones se-
guros.
• Implementar�medidas�robustas�de�control�de�acceso
– Requerimiento 7. Restringir el acceso a los datos de las tarjetas según
el principio de necesidad de conocer por razones de negocio.
– Requerimiento 8. Asignar una identificación única a cada persona con
acceso.
– Requerimiento 9. Restringir el acceso físico a lugares, dispositivos y
sistemas con datos de tarjetas.
• Monitorizar�y�auditar�regularmente�las�redes
– Requerimiento 10. Registrar y monitorizar todos los accesos a recursos
de red y sistemas que contengan datos de tarjetas.
– Requerimiento 11. Auditar regularmente los sistemas y procesos.
• Mantener�una�política�de�seguridad�de�la�información
– Requerimiento 12. Mantener una política que trate específicamente la
seguridad de la información.
Junto a estos doce requerimientos, el estándar PCI-DSS define otros adiciona-

les específicos para circunstancias concretas, como por ejemplo en el caso de
proveedores de servicios de alojamiento compartido.
Estos objetivos de control y sus doce requerimientos son desarrollados con

más detalle dentro del estándar. Como se puede comprobar, afronta la seguri-
dad de la información (en este caso, los datos de las tarjetas) desde una pers-
pectiva amplia, como se hace en la Norma ISO/IEC 27001 o COBIT, aunque un
poco más centrada en los controles aplicados en redes de datos, aplicaciones y
algunos procesos alrededor de la gestión de los mismos como la definición de
políticas que describan la forma de operar de los controles, o también los con-
troles aplicables a los recursos humanos. Sin embargo, se eluden o no se tratan
con demasiada profundidad aspectos como la estructura organizativa (comités
o estructuras para la gobernanza de la seguridad o esquemas de clasificación y
tratamiento de la información) para la gestión de la seguridad, la continuidad
de negocio o el cumplimiento del marco legal que, en este caso, sería muy
importante en países como España u otros de la Comunidad Europea con una
protección de la privacidad y de la información de carácter personal, la cual
es muy relevante cuando se habla de información relacionada con tarjetas de
crédito y pago efectuados.
3.3. Aplicabilidad del estándar PCI-DSS a la industria
La norma PCI-DSS es de obligado cumplimiento siempre que una organización

trate cualquiera de estos datos de tarjetas de crédito (algunos tienen un nivel
de protección más o menos elevado según el estándar):
• Datos de titulares de la tarjeta:

– numeración completa de la tarjeta,
– nombre y apellido,
– fecha de vencimiento,
– código de servicio.
• Datos confidenciales:
– datos almacenados en la banda magnética (conocidos como track1 y
track2),
– código de seguridad impreso en la tarjeta,
– PIN.
Por lo tanto, es aplicable a las instituciones financieras y comerciales que ha-

cen uso de los servicios de los emisores de tarjetas de crédito, y también pro-
veedores de servicios que procesen, almacenen o trasmitan información en
nombre de instituciones financieras, comerciales o las propias empresas emi-
soras de tarjetas de crédito durante una transacción económica con una tarje-
ta. Este entorno es relativamente complejo y, en el momento de realizar una
transacción, de manera general intervienen los siguientes actores:
• Cardholder: titular de la tarjeta. Se trata de la persona a nombre de quien

está emitida la tarjeta y en principio es su usuario. Debe conocer el PIN
de la misma y es responsable de su custodia. En un principio, el usuario
real y el titular de la tarjeta son la misma persona, pero en la práctica se
dan muchos casos en que no es así. Del mismo modo, hay que recordar
que en los inicios de las tarjetas de crédito no existían mecanismos para
realizar verificaciones en línea ni PIN, por lo que la autenticación se reali-
zaba mediante la firma manuscrita del titular de la tarjeta y un documento
acreditativo de su identidad (en EE. UU. esto último no ocurre, puesto que
no existe la obligación legal de disponer de este tipo de documento, pero
sí en Europa).
• Merchant: comercio. En términos generales, se trata de quien desea recibir

un pago por parte del cardholder usando la tarjeta, a cambio de algún tipo
de mercancía o servicio. El merchant puede querer hacer la transacción en
un lugar físico (una tienda) o en un sitio web.
• Issuing bank: es el banco o entidad financiera que contrata el cardholder

para obtener una tarjeta. Es quien recibe las peticiones de autorización y
debe dar indicaciones de si se puede o no realizar la transacción.
• Acquiring bank: es el banco o entidad financiera contratado por el merchant

para que gestione los pagos que va a recibir. Tanto el issuing bank como el
acquiring bank deben pertenecer a una asociación de gestores de tarjetas.
• Payment processor: es la entidad que contrata el merchant para que haga

de intermediario con el acquiring bank. Además puede realizar tareas más
avanzadas, como procesamientos por lote, prevención de fraude, etc. No
es que sea muy habitual oír hablar de ellos, al menos en España, ya que
históricamente los acquiring banks tuvieron que implementar esta función
porque en el mercado no surgieron organizaciones independientes sufi-
cientemente fuertes para realizar esta labor y, en consecuencia, ellos mis-
mos implementaron los mecanismos técnicos para que los merchants pu-
dieran emplear mecanismos de autorización en línea. En EE. UU. sí exis-
ten varios que los merchants contratan directamente, sobre todo si son co-
mercios que van a generar muchas transacciones. En el pasado, algunos
fueron desgraciadamente conocidos por haber sufrido ataques de hackers.
Actualmente, en España están surgiendo nuevos actores en este ámbito
(Sagepay, Payvision, etc.) junto a otros tradicionales como Redsys (antes
conocida como SERMEPA, fusión de las áreas de procesamiento de pagos
de Servired y 4B).
• Card network: cada tipo de tarjeta tiene una red de interconexión para que,
a través del payment processor, se haga el proceso de autorización de la ope-
ración.
Aparte de estos actores, que son quienes intervienen en transacciones econó-

micas con tarjetas, cualquier organización que finalmente trate un dato de
una tarjeta para prestar un servicio también se ve afectada por la PCI-DSS. Por
ejemplo, las empresas de asistencia que prestan sus servicios a un titular de
una tarjeta de crédito pueden verse afectadas por la PCI-DSS si en sus procesos
operativos deben tratar el dato de la tarjeta de crédito del cliente.
Todas estas entidades que finalmente manejan los datos del cardholder tendrán
que aplicar este estándar en todos los elementos de sus sistemas TIC y procesos
operativos. Por elemento del sistema se entiende elemento de red, servidores,
aplicaciones que estén incluidos o conectados con un entorno de tratamiento
de datos de tarjetas de crédito. Mediante una adecuada segmentación de la
red, las entidades podrán limitar el alcance de la norma. Ese entorno sobre
el que una organización debe aplicar la norma PCI-DSS es conocido como el
CDE (cardholder data environment). A la hora de realizar una auditoría de cum-
plimiento de PCI-DSS, el auditor únicamente lo hará sobre ese alcance, por lo
que es crítico para una organización afectada por la PCI-DSS el conocer muy
bien los límites de su CDE. Mediante esta correcta delimitación conseguirá
optimizar los controles que la norma le obliga a implantar, que son muy exi-
gentes, y también garantizar que no existen fuera de ese CDE puntos en los
que puedan existir tratamientos de datos de tarjetas potencialmente suscep-
tibles de verse afectados por un incidente de seguridad, debido en parte a la
incorrecta aplicación de la norma PCI-DSS.
3.4. Cumplimiento y auditoría del estándar PCI-DSS
Todas las partes que intervienen en las transacciones comerciales con tarjetas
de crédito deben cumplir con la totalidad del PCI-DSS. Pero, además, de ad-
herirse a él (en la práctica, aplicar todos los controles en todos los elementos
y procesos dentro del CDE), periódicamente han de realizar unas auditorías
cuyo tipo y también forma de presentación dependerá de su nivel, y cuyo in-
forme deberá estar a disposición de las entidades emisoras de las tarjetas y en
ciertos casos en que el nivel es el más elevado incluso ser presentado al PCI
SS Council. De este modo, se demostrará que se cumple con el estándar1. El
tipo de auditoría a realizar dependerá del nivel y también de su clasificación
en "merchant" o "proveedor de servicio".
(1)
Con todo, este cumplimiento no es ninguna garantía de que no puedan suceder in-
cidentes graves. A modo de ejemplo, recordemos el caso protagonizado por la empresa
Heartland Payemnt Services que, en enero del 2009, cometió un error en el que se pu-
dieron comprometer millones de datos de tarjetas de crédito y que, por su condición de
"PCI Compliant", puso en tela de juicio todo el esquema de auditorías por medio de QSA
ideado desde el PCI SS Council.
Ya se ha dicho que el cumplimiento con la totalidad de los requerimientos del

estándar es obligatorio, pero existe un nivel de exigencia distinto en cuanto a
los mecanismos para acreditar el cumplimiento, o para afirmar que se es "PCI
Compliant". Es decir, todos los aspectos de la norma son de obligado cumpli-
miento, con independencia del tamaño de una organización. Solo se pueden
excluir controles específicos si, por la naturaleza de la actividad que realiza la

organización, realmente no son de aplicación. Por ejemplo, si la organización
no desarrolla software, pueden existir determinados controles que no le sean
de aplicación, o si realmente nunca llega a almacenar datos de tarjetas en nin-
gún sistema de información. Sin embargo, sí que existe una distinción en el
modo en que las organizaciones deben mostrar a la industria su nivel de cum-
plimiento, en especial hacia las entidades emisoras de tarjetas (VISA, American
Express, Mastercard, etc.), que será más o menos complejo o exigente a la hora
de facilitar evidencias y el informe de reporte de cumplimiento. Cada una de
las marcas determina el nivel de demostración del cumplimiento según pará-
metros tales como volumen de transacciones y determinadas circunstancias
(que comentaremos a continuación), así como el rol que se tiene en la cadena
de operación de los datos de las tarjetas.
En el caso de VISA, las instituciones financieras y comerciales, denominadas

merchants, están clasificadas de este modo:
Nivel Descripción
1 Cualquier merchant que cumpla alguno de los siguientes aspectos:

• Acepte más de 6.000.000 de transacciones anuales, independientemente del
canal por el que lleguen.
• Haya sufrido un ataque/intrusión en sus sistemas que haya supuesto el acceso
a datos de alguna cuenta.
• Haya determinado adherirse a este nivel.
2 Cualquier merchant que acepte entre 1.000.000 y 6.000.000 de transacciones

anuales, independientemente del canal por el que lleguen.
3 Cualquier merchant que acepte entre 20.000 y 1.000.000 de transacciones

anuales por canal de comercio electrónico.
4 Cualquier merchant que acepte menos de 20.000 de transacciones anuales por

canal de comercio electrónico, o menos de 1.000.000 de transacciones anuales,
independientemente del canal.
Los proveedores de servicio se clasifican de este modo:
Nivel Descripción
1 Todos los involucrados con la red de intercambio de datos financieros (como Vi-
saNet) y todas las pasarelas de pago.
2 Cualquier proveedor de servicio que no sea de nivel 1 y que almacene, procese

o trasmita más de 1.000.000 de cuentas o transacciones anuales.
3 Cualquier proveedor de servicio que no sea de nivel 1 y que almacene, procese

o trasmita menos de 1.000.000 de cuentas o transacciones anuales.
Pasarelas de pago
Las pasarelas de pago son entidades que participan en la transacción de pago facilitando
al merchant un "acceso" a un punto de la red de intercambio de datos financieros para
que se procese la transacción, especialmente en entornos de comercio electrónico.
En base a esta clasificación, se exigen distintos periodos y tipos de auditoría

a realizar.
Nivel Tipo de auditoría
1 Auditoría completa anual realizada por un asesor cualificado (QSA: qualified se-
curity assessor) por el PCS-DSS Council).
Escaneo de red trimestral realizado por un provedor de servicio de escaneo de
redes cualificado (ASV: approved scanning vendor) por el PCISS�Council.
2 Auditoría completa anual realizada internamente.

3 Escaneo de red trimestral realizado por un ASV cualificado (autorizado) por el
4 PCISS�Council.
Para los proveedores de servicio, la periodicidad y tipo es:
Nivel Tipo de auditoría
1 Auditoría completa anual realizada por un QSA cualificado (autorizado) por el

2 PCS-DSS Council.
Escaneo de red trimestral realizado por un ASV cualificado (autorizado) por el
PCISS�Council.
3 Auditoría completa anual realizada internamente.

Escaneo de red trimestral realizado por un ASV cualificado (autorizado) por el
PCISS�Council.
Como se puede observar, este es un sector altamente organizado y estandari-

zado, porque también se ha estandarizado el tipo de auditoría a realizar. En
este sentido, el PCISS�Council ha desarrollado una metodología para cada una
de estas auditorías, y ha publicado las siguientes metodologías:
• Procedimientos� para� auditoría� de� cumplimiento� del� PCI-DSS. Estos

procedimientos están incluidos en la propia norma PCI-DSS desde la ver-
sión 2, donde se facilita al equipo auditor el conjunto de herramientas
para realizar la auditoría:
– Indicaciones para determinar el alcance: la norma da algunas indica-
ciones sobre cómo delimitar el CDE, aunque aún es un punto en el
que, en la práctica, pueden existir divergencias de interpretación entre
auditores.
– Para todos y cada uno de los puntos de la norma se facilita, junto con
su enunciado, las indicaciones para el auditor sobre el modo en que
debe realizarse la comprobación del cumplimiento. Asimismo, a las
organizaciones se les facilita indicaciones o recomendaciones sobre el
modo en que deben implementar cada uno de los detalles de los con-
troles, de manera que estén alineados tanto el control como la revisión
que ha de realizar el auditor posteriormente.
Se ha de tener en cuenta que, en algunos casos, las pruebas propuestas por

la metodología pueden resultar complejas de realizar y no serán resueltas
en una simple entrevista o comprobación técnica. En estos casos, la pericia
del equipo auditor le servirá para determinar qué pruebas adicionales se
han de realizar.
• Procedimientos�para�hacer�los�escaneos�de�red�exigidos�por�el�PCI-DSS.
El PCI SS Council facilita al equipo auditor las distintas fases a realizar en
el escaneo de red exigido en los términos del PCI-DSS; se trata, en realidad,
de un análisis de vulnerabilidades de los sistemas expuestos a Internet de
la organización.
El documento no incluye el detalle técnico, y sí que todos los tipos de sis-
temas que se exigen sean escaneados. Por lo tanto, sólo puede ser tomado
como la referencia de los puntos a analizar; el equipo auditor deberá tener
el conocimiento técnico necesario para realizar el escaneo.
• Cuestionario�para�la�autoevaluación�del�cumplimiento�del�PCI-DSS.
Este documento tiene un ámbito de aplicación menor para el equipo au-
ditor, puesto que se trata de una guía para que los merchant o proveedores
de servicios realicen ellos mismos la auditoría. Por lo tanto, es más sencillo
que los procedimientos de auditoría de cumplimiento del PCI-DSS com-
pleto. También es interesante destacar que el PCI SS Council ha previsto
cuatro niveles distintos de cuestionario, dependiendo de ciertas caracte-
rísticas del comerciante, por lo que se deberá analizar en cada caso cuál
es el que aplica.
• Documento� de� ayuda� a� la� implantación� priorizada� y� progresiva� del

PCI�DSS. El PCI DSS ha preparado una guía para ayudar a los implantado-
res del estándar. Esta guía organiza los distintos requerimientos del están-
dar en cuatro niveles o hitos. De este modo, se pueden planificar de manera
progresiva y priorizada, de un modo coherente con el PCI SS Council, los
distintos requerimientos y por tanto las acciones a realizar. En cualquier
caso, esto no implica que todos los requerimientos deban cumplirse.
Estas metodologías y materiales deberán ser empleados por el equipo au-
ditor en caso de una asignación relacionada con la conformidad de una
entidad contra la PCI-DSS y, en otros casos, podrán ser tomados como re-
ferencia para preparar su propio plan de auditoría.
• Documento�de�ayuda�a�la�realización�de�pruebas�de�intrusión. Dentro
del requerimiento 11 de PCI-DSS es necesario que las organizaciones reali-
cen pruebas periódicas y concretamente en el 11.3 pruebas de intrusión
y de verificación de la segmentación. El PCISS Council ha creado un docu-
mento para ayudar tanto a las organizaciones que deben cumplir con el
requerimiento como a las que ofrecen sus servicios al respecto. La guía se
centra en facilitar información de alto nivel centrándose en:
– Facilitar una explicación de los componentes y características de una

prueba de intrusión y explicar la diferencia con un escaneo de vulne-
rabilidades.
– Explicar conceptos como el alcance de la prueba, diferencias entre

pruebas de la capa de red frente a la pruebas de aplicación, aclaracio-
nes sobre pruebas de verificación de segmentación, o términos como
"ingeniería social".
– Explicar factores a tener en cuenta a la hora de valorar la cualificación y

capacitación de un auditor o experto encargado de realizar las pruebas
de intrusión.
– Explicar los aspectos básicos y fases que debe contener la metodología

que se emplee para realizar las pruebas.
– Facilitar unas líneas maestras a seguir en la realización del informe

completo de prueba de intrusión que incluya la información necesa-
ria para documentar la prueba, así como una lista de verificación que
pueda ser utilizada por la organización o el evaluador para verificar si
se incluye el contenido necesario.
4. Estándares de auditoría de la ISACA
La Information�Systems�Audit�and�Control�Association�(ISACA), iniciada
en 1967, es actualmente una de las asociaciones más reconocidas mundial-
mente como fuente de información, estudio y desarrollo en materia de audi-
toría de sistemas de información, de gobierno de las tecnologías de la infor-
mación, y es la emisora de dos de las certificaciones profesionales más recono-
cidas internacionalmente, el Certified Information Systems Auditor (CISA®)
y el Certified Information Security Manager (CISM®).
El gobierno de IT, que ya se ha introducido en el módulo 1 de este curso, se

tiene que entender como el conjunto de técnicas, procesos y estructuras cor-
porativas incorporadas a la cultura corporativa, e integradas con el resto de
prácticas de gobierno corporativo, que tienen como objetivo asegurar que las
tecnologías de la información dan adecuadamente soporte a los objetivos de
negocio, maximizan las inversiones en IT, y gestionan los riesgos y oportuni-
dades que estas nuevas tecnologías presentan para el negocio.
4.1. COBIT
El concepto de gobierno de las tecnologías de la información (IT governance) es

central en la filosofía de la ISACA, hasta el punto de que, en 1998, decidió pro-
mover la creación del IT�Governance�Institute�(ITGI) para centrar sus activi-
dades en esta área. Actualmente, el ITGI es el responsable del mantenimiento
y promoción del estándar COBIT, y constituye una referencia en materia de IT
governance. La ISACA está más centrada en la gestión de los aspectos relacio-
nados con la auditoría y el control de los sistemas de información.
Desde el punto de vista de la ISACA, el buen gobierno IT se basa en cinco áreas

clave:
• Alineación�estratégica. Se debe garantizar el vínculo entre los planes de

negocio y de IT; definir, mantener y validar la propuesta de valor de TI; y
alinear las operaciones de IT con las operaciones de la empresa.
• Entrega�de�valor. Las IT deben aportar valor a todo lo largo de su ciclo de

vida, y se debe asegurar que generen los beneficios prometidos en la estra-
tegia global de la organización, concentrándose en optimizar los costos y
en brindar el valor intrínseco de las TIC.
• Administración�de�recursos. La gestión de las IT debe ser correta, de mo-

do que la inversión sea óptima, así como la administración adecuada de
los recursos críticos de IT: aplicaciones, información, infraestructura y per-
sonas. Los temas clave se refieren a la optimización del conocimiento y
de la infraestructura.
• Administración�de�riesgos. La gestión de las IT y las decisiones de inver-

sión requieren: la toma de conciencia de los riesgos por parte de los altos
ejecutivos de la empresa, un claro entendimiento del deseo de riesgo que
tiene la empresa, la comprensión de los requerimientos de cumplimiento,
la transparencia de los riesgos significativos para la empresa, y la inclusión
de las responsabilidades de administración de riesgos dentro de la organi-
zación.
• Medición�del�desempeño. Es necesario rastrear y monitorear la estrategia

de implementación, la terminación del proyecto, el uso de los recursos,
el desempeño de los procesos y la entrega del servicio, con el uso, por
ejemplo, de "cuadros de mando" (balanced scorecards).
(2)
COBIT 20192 se basa, por lo tanto, en seis principios del buen gobierno IT: A fecha de realización de este
material, la última versión de CO
BIT era la COBIT 2019 (aprobada
• Satisfacer las necesidades de las partes interesadas y generar valor en el uso en 2018).
de las IT. El valor refleja un equilibrio entre beneficios, riesgos y recursos,

y las empresas necesitan una estrategia y un sistema de gobernanza para
lograr este valor.
• Tener un enfoque holístico. Un sistema de gobierno IT se construye a partir
de una serie de componentes que pueden ser de diferentes tipos y que
trabajan juntos de una manera holística, combinada y coordinada.
• Ser un sistema dinámico. Por propia naturaleza, el IT es muy dinámico y
evoluciona con gran rapidez, por lo que el propio sistema para su gobierno
debe ser capaz de evolucionar a su mismo ritmo.
• Facilitar la separación de la gestión IT del gobierno IT. Deben distinguirse
claramente las estructuras enfocadas a la gestión, administración y opera-
ción IT de las destinadas a realizar su gobierno.
• Adaptarse a las necesidades de la empresa.
• Dar cobertura completa sobre todos los procesos de la organización. El
procesado de información y el uso de tecnología se puede producir en
cualquier proceso de la organización y no sólo en la función o área de IT
de la misma, por lo que el gobierno IT debe ser aplicado sobre todos los
procesos de negocio.
El sistema necesario para poder implantar esta función de gobierno IT es el

conjunto de distintos componentes:
• Los procesos que describen un conjunto organizado de prácticas y activi-

dades para lograr ciertos objetivos y producir un conjunto de productos
que respalden el logro de los objetivos generales relacionados con TI.
• Las estructuras organizativas, que son las entidades clave de toma de de-
cisiones en una empresa en el área de gobierno IT.
• Las políticas, normas y procedimientos que traducen el comportamiento
deseado en una guía práctica para la gestión diaria.
• La información necesaria para el funcionamiento eficaz del sistema de go-
bernanza de la empresa.
• La cultura, la ética y el comportamiento de los individuos y de la empresa
a menudo son factores críticos en el éxito de las actividades de gobierno
y gestión.
• Se requieren personas, con habilidades y competencias adecuadas para la
toma de buenas decisiones y la ejecución de las actividades de los procesos.
• Los servicios, la infraestructura y las aplicaciones incluyen la infraestruc-
tura, la tecnología y las aplicaciones que proporcionan a la empresa el sis-
tema de gobierno para el procesamiento de IT.
El estándar COBIT ayuda a las organizaciones a implantar ese sistema de go-

bierno de TI para conseguir esos objetivos antes mencionados, mediante un
marco de referencia que proporciona a la gerencia de IT los siguientes aspectos:
• Establece un enlace medible entre los requerimientos de negocio de la or-

ganización y los objetivos de la gestión IT, manteniendo bajo control los
riesgos inherentes al uso de las IT.
• Organiza la mayoría de las actividades de las IT en un modelo de referen-

cia reconocido de manera general y mantenido por una organización de
reconocido prestigio.
• Define los objetivos de control de la gestión IT que se deben tener en con-

sideración.
• Facilita herramientas para:

– Establecer objetivos y calcular métricas para poder medir la eficacia y
eficiencia de las IT.
– Modelar la organización de la gestión IT con arreglo a un modelo de

madurez que permita comparar la organización con otras de su en-
torno.
– Clarificar los distintos roles y responsabilidades en la gestión IT.
El estándar organiza los procesos de gobierno de TI (IT governance) y los de

gestión de TI (IT management) como unos aspectos integrados en el mismo
marco de definición. Se diferencia de la gobernanza de la gestión en que en el
primero se tienen en cuenta las necesidades de negocio, se evalúan los riesgos

y se monitoriza el desempeño, mientras que la segunda diseña, construye y
opera con arreglo a los principios de la gobernanza.
Los grandes procesos que define COBIT 2019 se reflejan en el siguiente dia-
grama que recoge los procesos centrales y básicos del modelo:
Fuente: COBIT 2019 Framework – Introduction and Methodology
a) Procesos de gobierno TI para evaluar, orientar y supervisar
• EDM01 - Asegurar el establecimiento del marco de gobierno.

• EDM02 - Asegurar la entrega de beneficios.
• EDM03 - Asegurar la optimización del riesgo.
• EDM04 - Asegurar la optimización de los recursos.
• EDM05 - Asegurar la transparencia hacia las partes interesadas.
b) Procesos de gestión TI que están agrupados en diferentes grupos de procesos
• APO - Alinear, planificar y organizar:

– APO01 - Gestionar el marco de gestión de TI.
– APO02 - Gestionar la estrategia.
– APO03 - Gestionar la arquitectura empresarial.
– APO04 - Gestionar la innovación.
– APO05 - Gestionar el portafolio.
– APO06 - Gestionar el presupuesto y los costes.
– APO07 - Gestionar los recursos humanos.
– APO08 - Gestionar las relaciones.

– APO09 - Gestionar los acuerdos de servicio.
– APO10 - Gestionar los proveedores.
– APO11 - Gestionar la calidad.
– APO12 - Gestionar el riesgo.
– APO13 - Gestionar la seguridad.
– APO14 - Gestionar los datos.
• BAI - Construir, adquirir e implantar

– BAI01 - Gestionar los programas y proyectos.
– BAI02 - Gestionar la definición de requisitos.
– BAI03 - Gestionar la identificación y la construcción de soluciones.
– BAI04 - Gestionar la disponibilidad y capacidad.
– BAI05 - Gestionar la introducción de cambios organizativos.
– BAI06 - Gestionar los cambios.
– BAI07 - Gestionar la aceptación del cambio y de la transición.
– BAI08 - Gestionar el conocimiento.
– BAI09 - Gestionar los activos.
– BAI010 - Gestionar la configuración.
– BAI011 - Gestionar los proyectos.
• DSS - Entregar, dar servicio y soporte

– DSS01 - Gestionar las operaciones.
– DSS02 - Gestionar las peticiones y los incidentes del servicio.
– DSS03 - Gestionar los problemas.
– DSS04 - Gestionar la continuidad.
– DSS05 - Gestionar los servicios de seguridad.
– DSS06 - Gestionar los controles de los procesos del negocio.
• MEA - Supervisar, evaluar y valorar

– MEA01 - Supervisar, evaluar y valorar el rendimiento y la conformidad.
– MEA02 - Supervisar, evaluar y valorar el sistema de control interno.
– MEA03 - Supervisar, evaluar y valorar la conformidad con los requeri-
mientos externos.
– MEA04 - Gestionar la revisión interna.
Dentro de cada una de estas áreas, se detallan los procesos que constituyen los
mecanismos que proporcionan el control sobre el gobierno IT. Posteriormen-
te, cada uno de los procesos se descompone en un cierto número de objetivos
de control. Dentro de los aspectos que apoyan el gobierno IT, está la seguridad
de la información; por esta razón, COBIT es considerado como un marco de
referencia también para la gestión de la seguridad de la información. Además,
como se puede observar, su modo de organizar el catálogo de controles es si-
milar al proporcionado por el ISO/IEC 27002:2005, y existen distintos trabajos

(de la propia ISACA) que realizan un mapeo de los controles de la Norma ISO
contra los controles de COBIT.
(3)
Dentro de cada una de estas áreas, se definen un conjunto de controles de Matrices para la asignación de
responsabilidades R-responsible,
seguridad que conforman el catálogo COBIT de controles de seguridad. Los
A-accountable, C-consulted, I-infor-
controles COBIT se encuentran organizados en base a los distintos procesos med.
TI anteriormente descritos; cada uno de ellos afecta tanto a alguno de los cri-
terios de información como a alguno de los recursos de TI. La información
que se facilita en cada uno de ellos es muy completa (comparada con las guías
para la implementación que se proporcionan en el estándar ISO/IEC 27002) e
incluye matrices RACI3 para distribuir responsabilidades entre distintos acto-
res típicos en una organización, ayudas para establecer métricas, y un esque-
ma para medir el grado de madurez de la implantación del control basado en
cinco niveles:
• 0 – No existe Nota
• 1 – Inicial/ad hoc
Este esquema está muy alinea-
• 2 – Repetible pero intuitivo do con el modelo CMMI (ca-
• 3 – Proceso definido pability maturity model integra-
tion del SEI) Software Enginee-
• 4 – Administrable y medible ring Institute de la Universidad
Carnegie-Mellon, para la mejo-
• 5 – Optimizado ra de los procesos.
4.2. Reglamentación de la actividad de auditoría IT por ISACA
En el ámbito de la auditoría, una de las iniciativas más interesante de ISACA,

y con relación a la auditoría de los controles COBIT y la auditoría en general
de los sistemas de información, es la publicación de documentos de referencia
sobre auditoría y control. Entre ellos, destacan los estándares, las guías y los
procedimientos para la auditoría de los sistemas de información. La ISACA ha
creado un marco de prácticas profesionales para la auditoría y verificación de
sistemas TIC, al que denomina ITAF –IT Assurance Framework–, que divide su
marco para estandarizar las auditorías en tres niveles: estándares, guías o di-
rectrices de auditoría IT en general, y también más específicas para la auditoría
de los controles de COBIT, y procedimientos.
4.2.1. Estándares de auditoría de la ISACA
Estas normas definen los requerimientos obligatorios para la realización de Enlace recomendado
una auditoría y la elaboración de informes de auditoría. Las normas son apli-
ISACA mantiene al día es-
cables a auditores certificados por la ISACA (CISA). Su propósito fundamentos estándares y se pue-
tal es dar las pautas que el auditor tiene que seguir, desde un punto de vista den encontrar en: http://
www.isaca.org/Knowled-
del comportamiento y la actitud frente a su trabajo, aunque también algunas ge-Center/ITAF-IS-Assu-
rance-Audit-/IS-Audit-and-
de las normas de corresponden a aspectos más específicos del desarrollo de la
Assurance/Pages/it-au-
auditoría. Adicionalmente, hay dos más, pero no son relevantes en cuanto a dit-and-assurance-guideli-
nes-spanish.aspx
definir los patrones; por ello, el trabajo del auditor se debe guiar. Las normas
establecidas por la ISACA para el trabajo del auditor de IT son, en líneas gene-
rales, las siguientes:
a) Serie 1000 - Normas generales. Son principios generales sobre los que un
auditor debe guiar su comportamiento:
• 1001 - Estatuto de la función de auditoría. La dirección de la organización

auditada debe documentar y aprobar un "estatuto de auditoría" o "carta de
compromiso" que refleje el propósito y alcance de la auditoría y la relación
entre auditor y auditado a la hora de presentar resultados.
• 1002 - Independencia organizativa. El equipo auditor debe ser totalmente
independiente de la estructura organizativa respecto del área o actividad
que se está auditando.
• 1003 - Independencia profesional. El equipo auditor debe tener total inde-
pendencia profesional respecto del área o actividad que se está auditando.
• 1004 - Expectativa razonable. Al afrontar una asignación, el auditor debe
ser lo suficientemente crítico para determinar si las circunstancias hacen
razonable la consecución de los objetivos.
• 1005 - Debido cuidado profesional. El auditor de SI debe cumplir con el
código de ética profesional de la ISACA, sus estándares de auditoría y cual-
quier otro estándar profesional aplicable al realizar tareas de auditoría.
• 1006 - Competencia. El equipo auditor debe estar formado por miembros
que tengan la adecuada capacitación profesional para realizar la auditoría
e, igualmente, mantener al día sus conocimientos profesionales.
• 1007 - Afirmaciones. El auditor debe revisar las afirmaciones con las que el
tema será evaluado para determinar que estas sean auditables, suficientes,
válidas y relevantes.
• 1008 - Criterios. Los criterios de auditoría que escoja el auditor, con los
que será evaluado el tema, deben tener un origen confiable (por ejemplo,
estándares o buenas prácticas de la industria), ser objetivos, completos, re-
levantes, medibles, comprensibles, autorizados y comprendidos o dispo-
nibles para los destinatarios del reporte.
b) Serie 1200 - Normas sobre ejecución. Se refieren en concreto a la ejecución

(planificación, definición de alcances, supervisión, riesgos, etc.):
• 1201 - Planificación de la asignación. El equipo auditor debe planificar y

reflejar adecuadamente en un documento, plan o programa el desarrollo
de la auditoría, de manera que se cumpla con los objetivos previstos y con
las leyes y normas profesionales de auditoría que le sean aplicables (en-
tre ellas, estas mismas). Dicho documento estará basado en un análisis de
riesgos que minimice el riesgo de que la auditoría obtenga unos resultados
erróneos.
• 1202 - Evaluación de riesgo en planificación. En una planificación general
o estratégica de las actividades de auditoría de una organización, se deben
emplear técnicas de análisis de riesgos para la planificación táctica de las
auditorías y, de este modo, gestionar más eficientemente los recursos de

auditoría.
• 1203 - Desempeño y supervisión. La ejecución de la auditoría se hará si-
guiendo un plan de auditoría, de manera supervisada y documentada, a
partir de la obtención de evidencias que den soporte a las conclusiones
de auditoría.
• 1204 - Materialidad. La materialidad o importancia relativa en las audito-
rías puede ser considerada como la magnitud de un error en la información
obtenida durante una auditoría, que podría llevar al auditor a tomar una
decisión basándose en esa información. Por lo tanto, está relacionada con
el riesgo de auditoría. A mayor nivel de materialidad, menor será el riesgo
de auditoría. El auditor tendrá en cuenta este aspecto a la hora de planifi-
car los recursos, tiempos y tipos de procedimientos de auditoría aplicados.
Esto implica también que el auditor debe deducir los riesgos que se deriven
de la falta de controles o errores en su implementación, considerando este
concepto de materialidad y si son suficientes las evidencias obtenidas.
• 1205 - Evidencia. Las conclusiones del auditor deben estar basadas en las
evidencias de auditoría, recogidas en su asignación, que sean suficientes,
apropiadas y de confianza.
• 1206 - Uso del trabajo de otros expertos. El auditor podrá emplear el trabajo
de otros equipos auditores, siempre y cuando tenga la certeza de su nivel
de profesionalidad y conocimientos, y deberá recurrir a realizar pruebas
adicionales cuando las evidencias aportadas por otros equipos auditores
no sean suficientes.
• 1207 - Irregularidades y actos ilegales. El equipo auditor ha de ser cons-
ciente de que existe un cierto nivel de riesgo de irregularidades y acciones
fraudulentas en el área que se ha de auditar (especialmente si es un área
con impacto financiero) durante e incluso después de haber realizado su
trabajo. Por ello, cuando realice su auditoría, debe prestar gran atención
a detectar situaciones que pudieran manifestar o conducir a alguna situa-
ción irregular o fraudulenta, y siempre basarla en evidencias de auditoría
suficientes. Finalmente, si se detecta una situación fraudulenta o ilegal,
deberá reportarse sin demora al nivel de gerencia adecuado. Esta norma
refleja la gran relación que la ISACA tiene con otras organizaciones de au-
ditoría, en especial con la auditoría de cuentas.
c) Serie 1400 - Normas sobre el reporte. Hacen referencia a los tipos de reporte,
las vías y el contenido de la información que se ha de comunicar:
• 1401 - Reportes. Al finalizar la auditoría, el equipo auditor deberá sumi-

nistrar un informe de auditoría firmado que trate los siguientes aspectos:
– destinatarios del informe,
– nivel de restricciones aplicables al documento (su nivel de clasifica-
ción: secreto, confidencial, uso restringido, etc.),
– el periodo de cobertura de sus conclusiones,
– la identificación del alcance (organización, objetivos, naturaleza, fe-
chas y extensión de las pruebas realizadas),
– los hallazgos, las conclusiones y las recomendaciones, que deberán es-

tar debidamente respaldados por evidencias suficientes.
• 1402 - Actividades de seguimiento. El equipo auditor deberá informarse

de cómo la organización ha decidido tratar las conclusiones emitidas en
el informe, y si las decisiones son las oportunas o no.
Los auditores, especialmente si se trata de auditores certificados por la ISACA

(es decir, los CISA®) deben tomar estas normas como las reglas sobre las que
construir sus propios planes de auditoría, sus propias metodologías a la hora
de ejecutarlas, y su código de conducta y profesionalidad. Al tratarse de una
norma, no explica explícitamente el cómo, sino que simplemente nos dice
qué debe constituir la auditoría. Para ayudar a los auditores a poder cumplir
con el estándar ISACA de auditoría, la asociación ha desarrollado unas guías
de directrices de auditoría.
4.2.2. Las guías o directrices de auditoría
Como directrices de auditoría, se pueden destacar dos tipos de directrices que

la ISACA ha publicado. Por un lado, se trata de las directrices de auditoría para
el cumplimiento de la Norma de auditoría ISACA, a la hora de realizar labores
de auditoría en distintos ámbitos relacionados con la seguridad y la gestión IT
en general, y luego, para la comprobación de la implantación de los controles
COBIT.
Directrices para la auditoría IT
Las directrices�de�auditoría�IT�para�el�cumplimiento�del�estándar�ISACA
facilitan al equipo auditor una guía para poder aplicar los estándares de au-
ditoría y, por lo tanto, deben ser aplicados a juicio del auditor; en caso de
no aplicar alguna de las directrices, el equipo auditor debe conocer la razón
que lo motiva, sin que ello implique que no se vaya a cumplir el estándar de
auditoría; el estándar es de obligado cumplimiento para los auditores CISA®.
Del mismo modo que los estándares de auditoría se dirigen tanto a aspectos
relacionados con la actitud del auditor frente a su trabajo como a aspectos del
desarrollo de una auditoría, las guías y directrices también tratan de manera
diferenciada estos aspectos.
Adicionalmente, puesto que tienen como objetivo proporcionar más detalles

sobre la aplicación del estándar ISACA de auditoría, dan ciertos detalles sobre
la auditoría de algunas de las tecnologías de la información más relevantes en
el entorno corporativo actual.
Directrices de auditoría de COBIT
Por otro lado, se tienen que destacar las directrices�de�auditoría�de�COBIT,

o como se indica en la última versión disponible únicamente en inglés, "IT
Assurance�Guide�–�Using�COBIT".
Estas directrices de auditoría contienen una descripción del marco referencial

COBIT y un conjunto de directrices para la comprobación de la implantación
de los distintos controles de seguridad COBIT. Estas directrices se van actuali-
zando en la medida en que el estándar COBIT evoluciona.
Las directrices de auditoría de ISACA proporcionan guías para preparar planes

de auditoría que se integran en el marco referencial de COBIT y en los objetivos
de control detallados del COBIT. Deben ser usados conjuntamente con estos
dos últimos, y a partir de ahí pueden desarrollarse programas específicos de
auditoría. Sin embargo, las directrices no son exhaustivas ni definitivas; no
pueden incluir todo ni ser aplicables a todo, así que deberán ajustarse a las
condiciones específicas.
La ISACA entiende la auditoría como el proceso por el que comprueba el con-

trol de la gerencia sobre las TI con el objetivo de:
• Proporcionar a la dirección del auditado con aseguramiento razonable de

que se están cubriendo los objetivos de control.
• En donde existan debilidades de control significativas, justificar los riesgos
resultantes.
• Aconsejar a la dirección del auditado sobre acciones correctivas necesarias.
En este sentido, para ISACA el proceso de auditoría de TI se organiza general-

mente en las siguientes fases:
• Obtención de un entendimiento de los riesgos relacionados con los reque-

rimientos del negocio y de las medidas relevantes de control, mediante la
identificación de procesos TI y su documentación.
• Evaluación de la pertinencia de los controles establecidos.
• Pruebas de cumplimiento del control probando si están establecidos y fun-

cionando como se espera, de manera consistente y continua.
• Pruebas de comprobación de la eficacia del control, ya que existe el riesgo

de que los objetivos de control no se estén cumpliendo.
Como se puede observar, la planificación es acorde con la mostrada en este

documento.
Las directrices de auditoría de COBIT facilitan al auditor una guía para com-
parar el modo en que la organización realiza los procesos específicos de TI con
los objetivos de control de COBIT recomendados para ayudar al auditado a
identificar en qué casos los controles son suficientes, o para asesorarlos res-
pecto a los procesos que requieren ser mejorados.
No obstante, hay cuatro cosas que las directrices no son:
• Las directrices de auditoría no pretenden ser una herramienta para crear

el plan global de auditoría que consideraría una amplia gama de factores,
incluyendo debilidades anteriores, riesgos de la organización, incidentes
conocidos, nuevos acontecimientos, y selección de estrategias. Aun cuan-
do el marco referencial y los objetivos de control ofrecen algunas orienta-
ciones y son bastante detalladas, el alcance de las directrices no incluyen
una guía precisa para actividades específicas.
• Las directrices de auditoría no están diseñadas como instrumento para en-

señar las bases de la auditoría, aun cuando incorporen los elementos nor-
malmente aceptados de la auditoría general y de TI.
• Las directrices de auditoría no pretenden explicar en detalle la forma en

que pueden utilizarse las herramientas técnicas para apoyar y automati-
zar los procesos de auditoría a TI, en materia de planeación, evaluación,
análisis y documentación (que están incluidas, pero no se limitan a ellas,
en las técnicas de auditoría asistidas por computador). Existe un enorme
potencial para usar la tecnología de información dirigida a aumentar la
eficiencia y efectividad de las auditorías, pero una orientación en este sen-
tido tampoco está dentro de los alcances de las directrices.
• Las directrices de auditoría no son exhaustivas ni definitivas, pero se desa-

rrollarán conjuntamente con COBIT y sus objetivos de control detallados.
Las directrices de auditoría se encuentran organizadas como objetivo de con-

trol de alto nivel de COBIT. Para cada uno de estos objetivos de control, las
directrices facilitan al auditor la siguiente información:
• Los interlocutores más adecuados y la relación de documentación relevan-

te habitualmente existente en las organizaciones para poder obtener el
mejor entendimiento de la situación.
• Las comprobaciones y aspectos a revisar para evaluar la idoneidad y sufi-

ciencia de los controles implantados.
M1.810 · Auditoría Técnica · PAC-4 ·julio-2022

EJECUCIÓN E INFORMES DE AUDITORÍAS
respuesta según su gusto y experiencia profesional. Por tanto, la solución a la
• Puntuación de vulnerabilidades con CVSS versión 3.1.
Tomad la vulnerabilidad CVE-2017-0144 descubierta en la implementación
del servidor SMBv1 de Microsoft Windows.
https://nvd.nist.gov/vuln/detail/CVE-2017-0144
Buscad información sobre la misma y explicad porqué en la NVD (National
Vulnerability Database) del NIST (National Institute for Standards and
Technology) le ha otorgado una puntación de base de 8.1 según el esquema
CVSS (versión 3.1). Discutid si estáis de acuerdo con esta puntación.
A continuación, empleando la herramienta del NIST para el cálculo de la
puntación CVSS de una vulnerabilidad, y empleadla para precisar y
contextualizar de manera razonada el grupo de métrica de la temporalidad.
(https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator)
El alumno que desee optar por la nota máxima debe valorar también el grupo
de métrica de entorno y en ese caso deberá tomar como ejemplo la empresa
XXXXXX,SA de anteriores PEC. En caso de dudas respecto de la
infraestructura desplegada, se podrá hacer las suposiciones que se deseen o
consultar en el foro de la asignatura.

Módulo 4 – Técnicas de auditoría
Punto 4.4 Valoración de las vulnerabilidades de los sistemas TIC
Punto 4.4.1 CVSS (Common Vulnerability Scoring System)
1
El alumno debe mostrar que se ha informado sobre la vulnerabilidad, sus

características, las condiciones necesarias para su explotación, y el impacto
que produce. Con esta información, debe confirmar la puntuación dada por el
NIST en el NVD para la versión 3.1 de CVSS.
Otras fuentes para obtener información al respecto serian por ejemplo:
Sitios especializados en seguimiento de vulnerabilidades:
• https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-0144
• https://docs.microsoft.com/en-us/security-
updates/SecurityBulletins/2017/ms17-010
• https://research.checkpoint.com/eternalblue-everything-know/
• Exploits:
o https://github.com/RiskSense-Ops/MS17-010
o https://www.exploit-db.com/exploits/42031/
o https://www.bleepingcomputer.com/news/security/nsa-exploits-
ported-to-work-on-all-windows-versions-released-since-
windows-2000/
• Información adicional
o https://www.bleepingcomputer.com/news/security/one-year-
after-wannacry-eternalblue-exploit-is-bigger-than-ever/
Existen aspectos sobre los que el alumno podría discrepar y es

fundamentalmente sobre la complejidad de explotación. La existencia de
multitud de exploits disponibles y la notoriedad que adquirió el incidente
Wannacry hace que sea legítimo argumentar que una complejidad “alta” no
corresponde con la realidad que se ha observado. En cualquier caso, la
puntuación no va a entrar a valorar la argumentación puesto que ambas
posiciones son defendibles y sí como se emplea para generar una puntuación
u otra.
El alumno también deberá mostrar la comprensión del sistema de puntuación
de la versión 3.1. En el grupo de métricas básicas, se valorará que el alumno
argumente el valor que se otorga a la dimensión “SCOPE” que es la más
novedosa y que más conflicto genera. El valor más correcto para esta
dimensión sería UNCHANGED ya que la explotación de la vulnerabilidad no
impacta otro entorno más allá de en el que se encuentra el elemento
vulnerable. Para referencia respecto a la explicación de cómo aplicar esta
dimensión, consultar el punto 2.2 del siguiente enlace:
2
https://www.first.org/cvss/specification-document
Para el cálculo de la métrica temporal y del entorno el alumno debe
considerar el sistema de cálculo que se describe en el anterior enlace. El
alumno deberá explicar de qué modo valora cada una de las dimensiones que
conforman la métrica de temporalidad. El resultado de esta métrica podría
ser:
• Availability of exploit (Exploitability): High
• Type of fix available (RemediationLevel): Official fix
• Level of verification that vulnerability exists (ReportConfidence):
Confirmed
En esta valoración sólo es discutible en nivel de disponibilidad del exploit,
aunque claramente existe un exploit totalmente funcional disponible (ver
referencias anteriores) para todas las versiones de servidor SMB versión 1 en
sistemas operativos de Windows y además hay evidencias de la existencia de
código que lo explota de manera autónoma (gusanos Wannacry y Peyta).
El resultado de la métrica de entorno, el alumno deberá razonar la elección de

cada una de las dimensiones teniendo en cuenta las tablas del modelo (se
pueden consultar en FIRST o en el sitio web del CSIRT de CISCO, que se ha
indicado anteriormente).
Por lo tanto, una posible valoración podría ser:
• En el entorno de nuestra empresa ficticia, las dimensiones del grupo
básico se modificarían ya podemos considerar que se ha
implementado adecuadamente las reglas de firewall y el puerto
tcp/445 que es necesario para poder explotar la vulnerabilidad NO
está expuesto a internet y por lo tanto sólo es atacable desde red
adyacente. Asimismo, también se puede argumentar que la dimensión
de complejidad varió respecto a la valoración de base ya que hay
pruebas de su explotación autónoma por un malware de tipo gusano y
por existir exploits funcionales para todos los tipos de plataformas
afectadas.
• Respecto a los impactos y también requerimientos de CIA podemos
modificarlos indicando que los impactos de integridad y disponibilidad
son bajos debido a que los equipos potencialmente afectados son
servidores que no tienen que publicar información o servicios hacia el
exterior o estaciones de trabajo y que existen copias de seguridad
disponibles y comprobadas, por lo que si la información se ve afectada
se puede recuperar en tiempos que son adecuados para las
necesidades del negocio. Asimismo, los requerimientos de CIA para el
negocio son siempre altos.
3
La puntación resultante quedaría del siguiente modo:

AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H/E:H/RL:O/RC:C/CR:H/IR:H/AR:H/MAV:A/MAC
:L/MPR:X/MUI:X/MS:X/MC:X/MI:L/MA:L
Ilustración 1 – Puntuación CVSS v3 de la vulnerabilidad CVE-2017-0144 en el contexto del ejercicio
De cualquier modo, la puntación que resulte no es lo determinante para

valorar el ejercicio sino la explicación que se dé a los distintos factores que se
puntúan.
• Cuestión 2 – Informe de Auditoría

En este ejercicio tomáis el papel del auditor jefe a cargo de elaborar el
informe de una auditoría.
Existe un equipo auditor del que sois el responsable y que está compuesto
por vosotros mismo y 1 experto en seguridad informática que ha realizado las
pruebas técnicas de la auditoría que se os ha encargado y se encontraban
detalladas en un plan de auditoría. Aunque no se facilita en este enunciado, el
Plan de Auditoría (se trataría de uno muy similar al presentado en el punto 4.1
del módulo 3 “Auditoría técnica de seguridad”), contendría la siguiente
información básica:
[…]
La pregunta pide que realizar el informe de auditoría a partir de los resultados
que se ofrecen. En el material del curso se presenta la estructura
recomendada para un informe técnico de auditoría de seguridad.
El alumno que desee optar por la nota máxima se propone completar las
pruebas técnicas sobre la aplicación y mostrar otras vulnerabilidades que el
experto no ha localizado manualmente y documentado. Asimismo NO se pide
en este caso que se obtengan TODAS las vulnerabilidades de la aplicación ya
que son muchas y el informe resultante sería excesivamente largo. Por lo
tanto, en este caso se propone realizar las pruebas para identificar 1
vulnerabilidad de XSS (Cross Site Scripting) y 1 vulnerabilidad de inyección
de código PHP. Para ello, el alumno debe seguir los pasos descritos en el
ANEXO-3 para desplegar el laboratorio que contiene la aplicación a auditar
4

Punto 4.3 Reporting de la auditoria
Módulo 4 – Técnicas de auditoría
Punto 4 Pruebas técnicas de sistemas de información comunicaciones
Punto 4.6 Técnicas de análisis de vulnerabilidades de red o de sistemas
Punto 4.8 Técnicas de análisis de vulnerabilidades de aplicaciones web.
Este punto es totalmente práctico y se podría dar diversos ejemplos. Pero en

líneas generales el alumno debe organizar el informe de modo que se ajuste
o se trate en él los puntos recomendados en el material del curso. Por lo que
se espera encontrar:
• Un resumen ejecutivo que sea lo más autocontenido posible, tratando
de resumir tanto lo que se ha realizado, lo que se ha identificado, que
importancia se les da a los hallazgos y también las recomendaciones
que se dan. Su redacción debería de tener en cuenta que los
potenciales lectores de este apartado NO tienen porqué ser técnicos y
por lo tanto las explicaciones no deberían de ahondar en aspectos
técnicos.
• Metodología y herramientas empleadas: se debe transmitir las
distintas fases por las que se ha desarrollado la auditoría, los
mecanismos empleados para realizar la asignación de auditoría (tipos
de pruebas, técnicas, herramientas, etc), aunque sin entrar en un nivel
de detalle elevado y sobre todo sin dar los resultados, aunque se
puede hacer referencia a ellos señalando el anexo en el que se
encuentran. Ha de servir para respaldar el informe con una forma de
trabajar más o menos estandarizada o repetible. También es
interesante incorporar en este punto una explicación de cómo se
puntuarán o clasificará la importancia de cada hallazgo.
• El listado de hallazgos obtenidos con una explicación (sin necesidad
de entrar en los detalles técnicos de cómo se ha identificado) de modo
que se entienda bien en qué consiste el problema, dónde se
encuentra, qué se debería de hacer para resolverlo (aunque en este
punto no se debe entrar en temas de implementación sino quedarse
en el nivel de recomendación de acuerdo a lo más extendido en el
mercado/industria), y que valoración o clasificación se le da a su
importancia o relevancia, de modo que ayude al auditado a priorizar
las acciones.
Hay varias formas de afrontar este apartado, pero lo idóneo es
realizarlo de manera que sea informativo y claro, y que no sea una
5
transcripción íntegra de los resultados de las pruebas del plan de

prueba, sino que recoja sus resultados.
Si se detallaran muchos hallazgos puede ser interesante disponer de
un pequeño apartado introductorio en el que a modo de resumen se
expongan todos los hallazgos realizados, por ejemplo en una tabla
que las dé un identificador a cada una, un título bastante esclarecedor
y un nivel de importancia o criticidad (según un esquema diseñado
para la ocasión y entonces explicado en el apartado de metodología, o
su puntuación base según el CVSS si somos capaces de dar la puesto
que puede que el hallazgo no sea puramente técnica con la cual
CVSS no muy aplicable).
En este listado de hallazgos es interesante que el alumno NO se limite
a enumerar todos los resultados de las pruebas realizadas por el
experto puesto que algunas de las pruebas arrojan resultados
similares. En concreto los escaneos con NESSUS arrojan información
duplicada en los escaneos de red interno y externo, y el escaneo de
NESSUS específico para aplicaciones web proporciona unos
resultados los cuales a continuación son verificados por el experto de
manera manual. Por lo tanto, los hallazgos deben de ser bien
identificados y no repetirse. Por ejemplo, con NESSUS ya se
identifican vulnerabilidades en la aplicación web, y luego el experto las
verifica manualmente (algunas), por lo tanto, no tiene sentido
introducir como hallazgos independientes los resultados de NESSUS y
los de las pruebas manuales para un mismo tipo de vulnerabilidad.
Otro ejemplo muy claro son las vulnerabilidades de inyección de
código SQL. La herramienta NESSUS las detecta de 2 modos, con la
técnica denominada “Blind SQL injection”1 y con “Blind time based
SQL injection”, y adicionalmente, el experto de manera manual la
vuelve a verificar. En este caso la vulnerabilidad es únicamente 1 y es
que la capa de lógica de negocio de la aplicación falla en la validación
de los datos de entrada que son empleados para preparar una
consulta SQL contra el backend de base de datos. En el informe sólo
debería de aparecer 1 única vez indicando los distintos scripts y
1
https://www.owasp.org/index.php/Blind_SQL_Injection, OWASP considera que ambas
técnicas son la misma, con la única diferencia que para identificar si la inyección ha
funcionado, nos fijaremos si el contenido que el servidor devuelve es diferente en caso de
interpretar la sentencia booleana (la inyección tradcional “blinq SQLi”) o bien si el teimpo de
respuesta varia (la inyección “time based blind SQLi”)
6
variables en que se ha detectado, y adicionalmente luego podemos

explicar que se ha detectado de distintos modos.
• Adicionalmente en los anexos se puede incluir todos los detalles
técnicos que se deseen para ilustrar los hallazgos y los métodos que
se emplearon para descubrirlos.
Por otro lado, los puntos anteriores no tienen porqué tomarse como un índice
del informe, sino como los contenidos mínimos que se deben considerar. De
hecho un informe que se limitara a exponer estos puntos en su índice no será
erróneo pero desde luego no será todo lo completo que un informe real podría
ser.
7
Técnicas de auditoría
01 Presentación
02 Técnicas de auditorías
-1-
Universitat Oberta
de Catalunya
Aula
Módulo 5 - Técnicas de auditoría
Inicio: Fin:
02/05/22 15/05/22
00:00h 24:00h
Materiales
Técnicas de auditorías
Audiolibro
ePub
Mobipocket
html5
Pdf
Técnicas de
auditorías
PID_00285946

© FUOC • PID_00285946 Técnicas de auditorías



Producción: FUOC
© FUOC • PID_00285946 Técnicas de auditorías
Índice
Introducción............................................................................................... 5
1. Revisión de documentación............................................................ 7
2. Entrevistas............................................................................................ 10
2.1. Planificación de las entrevistas ................................................... 10
2.2. Selección de los interlocutores ................................................... 11
2.3. Tipos de entrevista ...................................................................... 16
2.3.1. Uso de cuestionarios abiertos ........................................ 16
2.3.2. Cuestionarios cerrados ................................................... 17
2.3.3. Desarrollo de las entrevistas .......................................... 17
2.3.4. Cuestionarios de autoevaluación .................................. 18
3. Visitas de auditoría........................................................................... 24
4. Pruebas técnicas de sistemas de información y

comunicaciones................................................................................... 27
4.1. Auditoría de los mecanismos de control de los riesgos físicos .... 27
4.2. Auditoría técnica de sistemas, comunicaciones y aplicaciones .. 28
4.3. Muestreo en las pruebas de auditorías técnicas a sistemas TIC ... 30
4.4. Valoración de las vulnerabilidades de los sistemas TIC .............. 31
4.4.1. CVSS (common vulnerability scoring system) .................... 32
4.5. Auditoría técnica de sistemas y gestión de TIC .......................... 37
4.6. Técnicas de análisis de vulnerabilidades de red o de sistemas .... 38
4.6.1. Enumeración e identificación de redes y sistemas ........ 40
4.6.2. Escaneo de direcciones IP y puertos .............................. 46
4.6.3. Investigación de vulnerabilidades ................................. 55
4.7. Revisión de seguridad en redes inalámbricas 802.11 .................. 62
4.7.1. Riesgos de las redes inalámbricas 802.11 ...................... 62
4.7.2. Política corporativa de seguridad para las redes
inalámbricas ................................................................... 64
4.7.3. Pruebas de auditoría para la revisión de redes
inalámbricas ................................................................... 65
4.8. Técnicas de análisis de vulnerabilidades de aplicación ............... 67
4.8.1. Análisis estático ............................................................. 67
4.8.2. Análisis dinámico: análisis de aplicaciones web ............ 70
4.8.3. Diferencias entre SAST y DAST ...................................... 84
4.8.4. Análisis de la configuración / parametrización de los
sistemas .......................................................................... 86
© FUOC • PID_00285946 5 Técnicas de auditorías
Introducción
En los módulos anteriores, se han tratado aspectos más generales del proceso
de auditoría: cómo son sus fases y los distintos marcos de trabajo que el equipo
auditor puede tomar como referencia, etc. También es interesante destacar
que hemos partido de las auditorías de certificación más formales, para luego
ir centrándonos en las de primera parte y de seguridad. En estas últimas, el
cliente de la auditoría es al mismo tiempo el auditado, y el alcance se limita
no a la totalidad de la gestión de la información, sino al tratamiento de esta
información en sistemas informáticos en red. Es lo que hemos denominado
auditorías técnicas de seguridad.
Las auditorías de seguridad, como se ha dicho en anteriores módulos, tienen

una casuística particular y, por lo tanto, el conjunto de pruebas que se deben
realizar son variadas. Es decir, el tipo de pruebas de auditoría a realizar deben
de ser diferentes para recopilar todas las evidencias de auditoría que sean rele-
vantes y útiles a la hora de obtener una conclusión. Por lo tanto, precisamen-
te por esta diversidad de situaciones a auditar, no es posible indicar a priori
qué técnicas de auditoría se deberán emplear en una asignación específica de
auditoría sin antes realizar un análisis del alcance y objetivo de la auditoría.
Sin embargo, se puede constatar que las técnicas o herramientas a disposición
del auditor se pueden agrupar en distintas categorías:
• Revisión de documentación.
• Entrevistas.
• Visitas a instalaciones del auditado y observación de la operativa habitual.
• Pruebas técnicas sobre los sistemas de información y comunicaciones.
Además, se debe tener claro que la elección de las técnicas depende de muchos
factores como:
• Alcance de la auditoría.
• Recursos dispuestos para realizar la auditoría.
• Experiencia del equipo auditor.
• Sistemas de información involucrados.
• etc.
La decisión sobre las técnicas de auditoría a emplear queda reflejada en el plan Plan de auditoría
de auditoría. Este documento refleja el plan de pruebas previsto, y debería in-
En el módulo 3 ("Auditoría de
dicar el tipo de pruebas que se van a realizar y sobre qué personal, documen- seguridad técnica") se expli-
tación, instalación y sistema de información. can las distintas fases en que se
descompone el proceso y los
documentos que las acompa-
ñan.
Por último, hay que destacar que las técnicas de auditoría a sistemas de infor-
mación se encuentran más definidas en un amplio número de libros, artículos
técnicos (whitepapers) y sitios web (algunos incluidos en la bibliografía de este
curso), y es posible ahondar más en su estudio previo. Por lo tanto, en este
apartado se hará más hincapié en técnicas aplicables a las auditorías de red y de
aplicaciones, por su especial importancia como vehículo de amenazas exter-
nas. Concretamente, las técnicas que se revisarán en este módulo se encuen-
tran alineadas con los métodos recogidos en el documento "NIST-SP 800-53A
Guide for Assessing the Security Controls in Federal Information Systems" y el
documento "NIST-SP 800-115 Technical guide to information security testing
and assessment". En ellos, las técnicas que se contemplan se agrupan en tres
categorías: examinar (examine), entrevistar (interview) y probar (test). Además,
los métodos de auditoría se clasifican en este documento a partir de tres ni-
veles según su profundidad (depth) y alcance (coverage). Para cada uno de los
métodos y sus distintos niveles, se dan indicaciones sobre las características de
la prueba a realizar, por lo que es recomendable la revisión de este documento.
Aunque vayamos a reflejar algunas técnicas de auditoría, especialmente las

más aplicadas, debemos reconocer que las técnicas de auditoría (especialmen-
te, de aspectos técnicos) son muy amplias y es difícil recogerlas en un úni-
co documento. Igualmente, un auditor de sistemas de información ha de ser
consciente de la dificultad de dominar todas las técnicas de auditoría, sobre
todo en un ambiente profesional tan cambiante como el de las tecnologías de
la información y las comunicaciones. Por lo tanto, tenemos que insistir en que
el auditor deberá mejorar de forma continua su dominio sobre las distintas
técnicas de auditoría, e ir desarrollando sus propias herramientas de ayuda a
la realización de pruebas. Además, tendrá que recurrir a los expertos que sean
necesarios, en las ocasiones en las que le sea imposible afrontar la asignación
de auditoría, con las garantías de éxito suficiente por falta de pericia técnica.
Resumiendo, en este módulo trataremos las distintas técnicas más comunes a

disposición de un equipo auditor para construir su plan de auditoría.
1. Revisión de documentación
Toda auditoría contrasta la realidad de una organización con una normativa

para obtener sus conclusiones. En los casos de auditorías de segundas o terce-
ras partes, esta normativa es siempre algo externo a las normas internas de
la organización auditada, ya sea un pliego de condiciones o requerimientos
contractuales, en el primer caso, o un estándar, en el segundo. Sin embargo, en
las auditorías de primera parte, esta normativa puede ser tanto externa como
interna. El objeto de la auditoría será comprobar si los controles se encuentran
implantados con arreglo a las mejoras prácticas del sector, así como comprobar
si se han implantado como indica la documentación de los controles genera-
da por el auditado. Este último punto hace que sea necesario que el auditor
conozca la documentación interna relevante para el alcance de la auditoría.
Por consiguiente, uno de los aspectos que el auditor revisará inicialmente será
las políticas y demás normativas que se derivan de ellas, tanto internas como
externas al auditado, y que estén bajo el alcance de la auditoría.
Por otra parte, tampoco hay que olvidar que, en ocasiones, muchos contro-
les son implementados esencialmente mediante un soporte documental. Será,
por ejemplo, el caso de los aspectos relativos a la subcontratación de servicios
de TI. Una parte esencial de la seguridad en este tipo de controles es que exis-
ta un contrato donde se encuentren documentados aspectos como el modo
en que se realiza el servicio o el modo en que es medido el nivel de servicio.
Estos contratos son conocidos como "acuerdos de nivel de servicio" o service
level agreement (SLA). Los acuerdos de nivel de servicio deben indicar, median-
te métricas claramente establecidas, los parámetros para poder medir la cali-
dad del servicio ofrecido. Cuando se audita la implantación de este control, se
tendrá que examinar y revisar la documentación y contrastarla con el conte-
nido mínimo exigible. Posteriormente, si la inspección de la documentación
ha sido satisfactoria, puede ser relevante realizar alguna entrevista para corro-
borar algún otro aspecto, como el modo en que se realiza el seguimiento de
los acuerdos de nivel de servicio.
La lista de documentación a revisar depende directamente de los controles de

seguridad a comprobar. En este sentido, según el tipo de control, habrá más
o menos documentación a revisar, o incluso ninguna. En este último caso,
el auditor tomará como referencia los catálogos de controles y determinar el
modo en que éstos se implementan respeto a un marco de referencia.
(1)
Para determinar qué documentación se debe revisar, es destacable la aporta- Hasta la fecha de elaboración de
este material, en su versión deno-
ción de la ISACA y el ITG, IT Governance Institute (ved el módulo 4). La ISACA
minada Cobit 2019.
y el ITG, junto con el propio catálogo COBIT1, han publicado un manual con
(2)
las directrices para la comprobación o auditoría2 del grado de cumplimiento ITAF - IT Assurance Framework
del marco COBIT.
(3)
Para cada uno de los procesos COBIT, se facilita unas directrices para crear un Si se es miembro de ISACA se
3 pueden obtener en la URL: http://
programa de evaluación y auditoría de cada uno de esos procesos . Dentro de www.isaca.org/knowledge-cen-
esas directrices, que incluyen gran número de detalles, en ciertos puntos se ter/research/pages/audit-assuran-
ce-programs.aspx.
facilitan algunas listas de información y documentos que el auditor deberá re-
copilar. Las directrices plantean obtener esta documentación mediante entre-
vistas con el personal, pero puede también obtenerse directamente mediante
la organización. Es decir, el auditor puede entregar el listado de documentos
necesarios a la organización para que sea ésta la que recopile la información
y la facilite al auditor. En este caso, se observa la clara relación entre los dos
tipos de pruebas: entrevistas (que se tratarán más adelante) y revisión de do-
cumentación.
Pongamos, por ejemplo, en un proceso de auditoría de certificación ISO 27001, en su

fase inicial, las pruebas de auditoría son eminentemente documentales, y el auditor re-
pasará todas aquellas evidencias documentales que el auditado facilite para mostrar la
implementación de los requerimientos de la norma y también para mostrar cómo man-
tiene las evidencias documentales requeridas explícitamente por la norma y reflejadas
en ésta bajo el nombre de “información documentada”. Este listado de documentación
obligatoria que debe existir es a ciencia cierta el mínimo de documentación que el audi-
tor deberá repasar, a saber:
• El alcance del sistema de gestión de seguridad de la información (cláusula 4.3)

• Política de seguridad de la información y objetivos (cláusulas 5.2 y 6.2)
• Metodología de evaluación y tratamiento de riesgos (cláusula 6.1.2)
• Declaración de aplicabilidad (cláusula 6.1.3 d)
• Plan de tratamiento de riesgo (cláusula 6.1.3 e y 6.2)
• Informe sobre evaluación de riesgos (cláusula 8.2)
• Registros de formación, habilidades, experiencia y calificaciones (cláusula 7.2)
• Seguimiento y resultados de medición (cláusula 9.1)
• Programa de auditoría interna (cláusula 9.2)
• Resultados de auditorías internas (cláusula 9.2)
• Resultados de la revisión por dirección (cláusula 9.3)
• Resultados de acciones correctivas (cláusula 10.1)
Adicionalmente, y según los controles que puedan ser de aplicación (descritos en la “De-
claración de aplicabilidad”) podría ser conveniente (aunque no obligatorio) que la enti-
dad facilite y el auditor revise los siguientes documentos:
• Política BYOD (Bring Your Own Device = Trae tu propio dispositivo) (cláusula A.6.2.1)
• Definición de roles y responsabilidades de seguridad (cláusulas A.7.1.2 y A.13.2.4)
• Política de dispositivo sobre dispositivos móviles y teletrabajo (cláusula A.6.2.1)
• Inventario de activos (cláusula A.8.1.1)
• Uso aceptable de los activos (cláusula A.8.1.3)
• Política de clasificación de la información (cláusulas A.8.2.1, A.8.2.2 y A.8.2.3)
• Política de eliminación y destrucción de activos (cláusulas A.8.3.2 y A.11.2.7)
• Política de control de acceso (cláusula A.9.1.1)
• Política de claves (cláusulas A.9.2.1, A.9.2.2, A.9.2.4, A.9.3.1 y A.9.4.3)
• Procedimientos para trabajo en áreas seguras (cláusula A.11.1.5)
• Política de pantalla y escritorio limpios (cláusula A.11.2.9)
• Procedimientos de operación para gestión de TI (cláusula A.12.1.1)
• Política de gestión de cambios (cláusulas A.12.1.2 y A.14.2.4)
• Política de copias de seguridad (cláusula A.12.3.1)
• Registros de las actividades de usuario, excepciones y eventos de seguridad (cláusulas
A.12.4.1 y A.12.4.3)
• Política de transferencia de información (cláusulas A.13.2.1, A.13.2.2 y A.13.2.3)
• Principios de ingeniería de sistemas seguros (cláusula A.14.2.5)
• Política de seguridad para proveedores (cláusula A.15.1.1)

• Procedimiento para gestión de incidentes (cláusula A.16.1.5)
• Análisis de impacto en el negocio (BIA) (cláusula A.17.1.1)
• Estrategia de continuidad de negocio (cláusula A.17.2.1)
• Procedimientos de continuidad de negocio (cláusula A.17.1.2)
• Plan de mantenimiento y revisión (cláusula 17.1.3)
• Plan de pruebas y verificación (cláusula A.17.1.3)
• Requerimientos legales, regulatorios y contractuales (cláusula A.18.1.1)
La lista se puede considerar bastante exhaustiva, pero debe tomarse sólo como
una referencia, puesto que podemos considerar que existen documentos que
serían también relevantes, como por ejemplo: inventario de hardware, inven-
tario de software completo (no únicamente el de control de acceso), planos
de arquitectura de sistemas y comunicaciones, entre otros. La experiencia del
equipo auditor es esencial a la hora de realizar este tipo de pruebas. El cono-
cimiento del modo más habitual en que las organizaciones implementan este
tipo de controles determinará la documentación que deberá solicitar el audi-
tor. Igualmente, a lo largo de las revisiones, irán surgiendo nuevas peticiones
de documentación a revisar.
El nivel de detalle al que llegue el auditor, a la hora de revisar la documenta-

ción, dependerá del objetivo de la revisión o del tipo de documentación revi-
sada. Por ejemplo, si la documentación forma parte de la implementación de
un control, ésta requerirá una revisión más a fondo. El auditor determinará el
nivel de profundidad o detalle con que realizará la revisión en función de los
recursos de la auditoría, el objetivo de la revisión, el tipo de documentación,
la documentación de apoyo a la implantación de un control, etc. En cualquier
caso, la elección del nivel de detalle no deberá comprometer los objetivos de
la auditoría.
2. Entrevistas
Para comprobar la seguridad de los sistemas de información de una determi-

nada organización, el auditor tendrá que realizar pruebas de auditoría que no
están relacionadas con aspectos puramente técnicos, sino más bien organiza-
tivos.
A modo de ejemplo, si tomamos como referencia los controles definidos por la Norma
ISO/IEC 27002 para el control de acceso, veremos que los aspectos técnicos tienen mu-
cho peso. Sin embargo, esta norma incluye también pruebas de auditoría relacionadas
con aspectos puramente organizativos, como por ejemplo: ¿qué política de control de
acceso existe?, ¿cómo y cuándo se comunica ésta a los usuarios?, ¿con qué frecuencia y
de qué modo se realizan revisiones de la asignación de permisos?, ¿a quién se informa
de estas revisiones?, ¿existen pruebas de todo ello? La revisión de aspectos organizativos
debe afrontarse con pruebas no únicamente técnicas, sino también por medio de con-
versaciones con los responsables organizativos.
En la mayoría de ocasiones, el auditor deberá solicitar a los entrevistados un

soporte documental que evidencie las afirmaciones que se realicen en la en-
trevista. De otro modo, al no existir más evidencia que el resultado de una
entrevista, las conclusiones de auditoría serán más débiles. En este caso, el au-
ditor considerará la posibilidad de determinar que el control no se encuentra
correctamente implementado, al no existir ninguna evidencia suficiente que
lo demuestre.
A continuación, repasaremos las entrevistas como una de las técnicas de au-

ditoría más habituales.
2.1. Planificación de las entrevistas
Como cualquier otra prueba de auditoría, las entrevistas deben ser planificadas
de antemano. La razón no es únicamente de orden logístico o de coordinación
de agendas entre entrevistados y auditores, sino que la planificación tiene por
objeto ajustar los objetivos de la prueba a realizar.
Para planificar correctamente estas pruebas, se tendrá que determinar:
• El objetivo de la entrevista. Las entrevistas se deben planear con un obje-

tivo claro y específico. Si éste no está claro, el resultado de la prueba será
insuficiente. Por lo tanto, se tiene que determinar qué es lo que se preten-
de obtener o comprobar mediante la realización de la entrevista.
• Los interlocutores más adecuados. Según el objetivo, existirán varios can-

didatos a ser entrevistados. El número de interlocutores puede ser amplio
y, en estos casos, se hará necesario un muestreo de interlocutores. Asimis-
mo, tener varios interlocutores servirá para obtener puntos de vista con-
trastables sobre una temática, sobre todo en situaciones en que no se dis-

pone de otros elementos objetivos o demostrativos (por ejemplo, docu-
mentos oficiales).
• Tipo de entrevista a realizar. Como más adelante veremos, existe la posi-

bilidad de recoger la información de maneras diferentes: entrevistas sin
guión, con cuestionario, autoevaluaciones, etc.
• Número de entrevistas a realizar. El número de entrevistas depende total-

mente de los recursos de auditoría que se vayan a dedicar, del alcance de
la auditoría y de la modalidad de las entrevistas. En cualquier caso, ha de
planificarse un número de entrevistas que asegure que se alcanzan los ob-
jetivos de auditoría.
Para planificar las entrevistas necesarias, el auditor deberá conocer el equipo

auditado y el alcance de la auditoría. Además, el auditor se basará también en
su propia experiencia y su conocimiento de las estructuras organizativas más
usuales. A este respecto, pocas metodologías indican qué entrevistas se han de
realizar y quiénes son los interlocutores más adecuados.
2.2. Selección de los interlocutores
Respecto a la selección de los interlocutores, es difícil determinar a priori cuá-

les serán los más adecuados. Obviamente, se seleccionará al personal más ade-
cuado teniendo en cuenta:
• Su nivel de responsabilidad en la organización y en el área de interés de

la auditoría.
• Su grado de conocimiento del área de interés, aunque no tenga una res-

ponsabilidad en la misma.
• Su participación en las actividades de un área, aunque sólo sea por su ca-

lidad de usuario. Los usuarios servirán para contrastar o comprobar cómo
se realizan ciertas actividades o acciones.
Aunque todas las organizaciones no disponen de unidades específicamente

dedicadas a la gestión de los aspectos relevantes en la administración, opera-
ción y mantenimiento de los sistemas de información (más adelante detalla-
remos algunos que serían relevantes para ser entrevistados), sí podemos afir-
mar que todas estas áreas deben tenerse en cuenta a la hora de realizar una
auditoría técnica de seguridad. Por lo tanto, una de las tareas previas a la rea-
lización de la fase de entrevistas será identificar al personal adecuado. Para
ello, es necesario un conocimiento sobre la organización interna de la entidad
auditada, que puede que el auditor no disponga. Cuando el auditor no tenga
un conocimiento previo suficiente sobre la organización, deberá haber una

persona en la entidad auditada que sirva de enlace y permita resolver este tipo
de cuestiones. Este enlace ha de tener:
• Buen conocimiento sobre la organización (unidades, funciones, áreas im-

portantes para el negocio, flujo de la información, etc.).
• Cierto nivel de responsabilidad o autoridad en la organización, para poder

convocar a los interlocutores adecuados.
Podemos afirmar que, si un auditor externo no cuenta con la colaboración de

una persona de enlace con estas características, las labores de auditoría resul-
tarán poco eficientes. Ello vendrá motivado por el conocimiento limitado de
la organización y el escaso o nulo poder de convocatoria.
A la hora de seleccionar el personal a entrevistar, probablemente con la ayuda

de la persona o equipo comentado anteriormente, podemos organizar a los
potenciales interlocutores en alguna de las siguientes categorías:
• Dirección. La dirección determina los objetivos de seguridad de la orga-

nización y su alineación con los objetivos de negocio. Por lo tanto, será
interesante entrevistar a miembros de la dirección (dirección de TIC, por
ejemplo) para determinar el modo en que se gestionan los recursos dedi-
cados a la seguridad de los sistemas de información.
• Área de seguridad. La organización no está muy concienciada; el personal

del área de seguridad suele estar dedicado únicamente a la seguridad física.
Por otro lado, en organizaciones con elevada concienciación en materia
de seguridad, este personal tendrá en cuenta todas las facetas de la seguri-
dad de la información. Es habitual que la asignación de auditoria esté ges-
tionada desde esta área, y que su personal sirva de enlace entre el equipo
auditor y el resto de la organización.
La participación del área de seguridad en las entrevistas será intensa, pues-
to que gran parte de la gestión de los controles recaerá en sus manos. Nor-
malmente, este personal es el interlocutor adecuado para tratar los aspec-
tos relacionados con la seguridad física, al menos en lo referente a los con-
troles de acceso, aunque estos aspectos pueden ser gestionados desde otra
área de la organización.
• Recursos humanos y gestión de usuarios. El proceso de selección, contra-

tación y baja del personal, así como su relación con la gestión de cuentas
de usuario y asignación de recursos informáticos, tiene impacto sobre los
controles de acceso técnicos que se hayan implantado. Por ello, en primer
lugar, puede resultar interesante contar con la visión del área de RRHH
para comprobar su coordinación con el área IT al gestionar las cuentas de
usuario. En segundo lugar, puede resultar interesante contar con la visión

del área TIC encargada de gestionar el alta, baja o modificación de los de-
rechos de acceso de usuario.
Otros aspectos que también podrán ser tratados con RRHH serán aquellos
relativos a la formación y concienciación de los usuarios, aunque puede
que esta responsabilidad esté repartida con el área de seguridad.
• Gestión de relaciones con contratistas externos. La gestión de ciertas par-

tes de los sistemas de información puede estar externalizada en contratis-
tas externos (alojamiento de sistemas, desarrollos, operación de los siste-
mas de información, etc.). Por ello, es interesante verificar la selección y
el control del personal externo que accede a los sistemas de información.
Además, puede ser aconsejable verificar el modo en que se definen los
contratos, los niveles de acuerdo de servicio (SLA, service level agreement),
el seguimiento y la auditoría de las acciones de estos externos.
• Sistemas de información centrales y comunicaciones de datos. Será nece-

sario contar con el personal que se encarga de los sistemas de informa-
ción centrales (servicios en modo SaaS - Software as a Service, servicios de
computación en la nube, ya sea ésta pública o privada, entornos de virtua-
lización, servidores, aplicaciones corporativas, servicios de correo electró-
nico, web, etc.), para verificar la seguridad en su arquitectura, configura-
ción, operación y mantenimiento. Con este personal, podrán verificarse
también aspectos de la seguridad física relacionados con la protección de
las condiciones operativas de los sistemas de información (temperatura,
humedad, alimentación eléctrica, control de acceso, etc.).
También es posible que, en esta misma área, se encuentren las activida-
des de desarrollo de nuevos sistemas de información. Estas actividades son
también relevantes en las auditorías técnicas de seguridad y, por lo tanto,
el personal asociado será también candidato a ser entrevistado. Es habitual
que las labores de desarrollo de nuevos sistemas se encuentren externali-
zadas, por lo que se deberá contar de nuevo, en ese caso, con las áreas
externas.
• Sistemas de control de procesos. En las organizaciones en que exista un

proceso productivo controlado mediante sistemas de información, será re-
levante tratar aspectos de seguridad como el control de acceso, la segre-
gación de funciones, la administración de operaciones, el mantenimien-
to, etc. Estos procesos productivos no tienen por qué ser exclusivamente
industriales; podrían tratarse, por ejemplo, de los terminales financieros
usados por los empleados de un banco.
• Infraestructuras de usuario. Entendemos esta área como la relacionada con

la gestión de los equipos de trabajo de usuario (PC de usuario, portátiles,
smartphones, PDA, etc.), incluyendo también, si existe, el servicio de aten-
ción al usuario (helpdesk). Su relevancia para las auditorías técnicas radica
tanto en los controles aplicados en estos sistemas como en los procesos

de soporte a usuario, en tanto que pueden ser víctimas de un ataque de
ingeniería social.
• Gestión de incidentes y de recuperación ante desastres. En ciertas ocasio-

nes, las organizaciones cuentan con áreas dedicadas a la gestión de inci-
dentes y a garantizar la continuidad del negocio (equipos de recuperación
ante desastres, o de continuidad). En estas organizaciones, la seguridad es
un aspecto maduro, y será interesante la participación del personal de esta
área en las entrevistas.
Para realizar la selección de interlocutores, es destacable de nuevo la aporta-

ción de la ISACA y el ITG. En la propia definición de los controles COBIT, a
partir de la versión 4, se ha definido un diagrama RACI para cada proceso. Este
diagrama recoge las distintas tareas o actividades de un control y las relaciona
con cada una de las áreas de una organización, asignando a cada área un tipo
de responsabilidad:
• Responsable. Responsable de realizarlo.

• Accountable. Responsable funcional de que se realice la actividad, es decir,
quien rinde cuentas ante sus superiores.
• Consulted. Consultado.
• Informed. Informado.
Proceso de control DS-5: Garantizar la seguridad de los sistemas
Tomemos, por ejemplo, dentro del dominio DSS (delivery, service and support, 'entrega
de servicios, operación de servicio y soporte'), el proceso de control DSS-05: Gestionar
los servicios de seguridad. Este proceso incluye varias actividades claramente relevantes
cuando se está realizando una auditoría técnica de seguridad:
• DSS05.01. Proteger contra software malicioso (malware).

• DSS05.02. Gestionar la seguridad de la red y las conexiones.
• DSS05.03. Gestionar la seguridad de los puestos de usuario final.
• DSS05.04. Gestionar la identidad del usuario y el acceso lógico.
• DSS05.05. Gestionar el acceso físico a los activos de TI.
• DSS05.06. Gestionar documentos sensibles y dispositivos de salida.
• DSS05.07. Supervisar la infraestructura para detectar eventos relacionados con la se-
guridad.
El diagrama RACI de este proceso es el siguiente:

Matriz RACI DSS05
Práctica�Clave�de�Gobierno
Director�de�Seguridad�de�la�Información�(CISO)
Comité�Estratégico�(Desarrollo�de�proyectos)
Cumplimiento�Normativo�(Compliance)
Propietarios�de�los�procesos�de�negocio
Gestor�de�Privacidad�de�la�Información
Consejo�de�Arquitectura�de�la�Empresa
Gestor�de�Seguridad�de�la�Información
Gestor�de�Servicios�(Service�Manager)
Gestor�de�Continuidad�de�Negocio
Director�General�Financiero�(CFO)
Director�de�Informática�/Sistemas
Director�General�Ejecutivo�(CEO)
Jefe�de�Arquitectura�del�Negocio
Comité�de�Riesgos�Corporativos
Oficina�de�Gestión�de�Proyectos
Director�de�Operaciones�(COO)
Comité�Ejecutivo�Estratégico
Oficina�de�Gestión�del�Valor
Consejo�de�administración
Jefe�de�Recursos�Humanos
Director�de�Riesgos�(CRO)
Jefe�de�Administración�TI
Jefe�de�Operaciones�TI
Ejecutivos�de�negocio
Jefe�de�Desarrollo
Auditoría
DSS05.01 R I C A R C C C I R R I R
Proteger contra software mali-
cioso (malware).
DSS05.02 I C A C C C I R R I R
Gestionar la seguridad de la
red y las conexiones.
DSS05.03 I C A C C C I R R I R
Gestionar la seguridad de los
puestos de usuario final.
DSS05.04 R C A I C C C I C R I R C
Gestionar la identidad del
usuario y el acceso lógico.
DSS05.05 I C A C C C I C R I R I
Gestionar el acceso físico a los
activos de TI.
DSS05.06 I C C A R
Gestionar documentos sensi-
bles y dispositivos de salida.
DSS05.07 I C I A C C C I C R I R I I
Supervisar la infraestructura
para detectar eventos relacio-
nados con la seguridad.
Diagrama RACI del proceso COBIT 5 – DSS05. Fuente: ISACA - COBITS
A partir de este diagrama, podemos identificar fácilmente unos cuantos can-

didatos a ser entrevistados para el grado de implantación de los controles in-
cluidos en este proceso.
Por otra parte, las directrices de auditoría también proporcionan guías sobre
cómo evaluar la implantación de los procesos de control de COBIT y, además,
se facilitan indicaciones sobre qué interlocutores se deben entrevistar.
Volviendo a nuestro ejemplo, las directrices de auditoría de ISACA indican

que, para comprobar el proceso de control DSS-5, se recomienda entrevistar a:
• Propietarios de los procesos de negocio.

• Oficial de seguridad senior de la organización (máximo responsable de la
gestión de la seguridad en la organización).
• Dirección de Recursos Humanos.
• Dirección de TI.
• Responsable/s de Desarrollo.
• Responsable/s de Operaciones de TI.
• Personal relevante en la dirección de la gestión de la seguridad de TI.
• Personal relevante administrador de bases de datos de TI.
• Personal relevante administrador técnico de la seguridad de TI.
• Personal relevante en la dirección del desarrollo de aplicaciones de TI.
Además, esta misma metodología indica los objetivos de las entrevistas y la

información que se debe recabar de este conjunto de interlocutores. A partir
de aquí, el siguiente paso del auditor es definir los distintos tipos de entrevistas
y el contenido de los cuestionarios.
2.3. Tipos de entrevista
De manera básica, podemos catalogar las entrevistas en función del tipo de

cuestionario que se utilice:
• Cuestionarios abiertos, guiados por el propio auditor.

• Cuestionarios cerrados.
• Cuestionarios de autoevaluación.
Evidentemente, el uso de un tipo de cuestionario u otro dependerá de la ca-

pacidad del auditor y, en gran medida, de los recursos de auditoría que se dis-
pongan (número de auditores, conocimientos y marco temporal). La calidad
de los resultados obtenidos puede variar de forma notable en función del tipo
escogido. Nuevamente, el equipo auditor sopesará los pros y los contras, esti-
mará sus capacidades y, a partir de aquí, determinará el tipo de entrevistas.
2.3.1. Uso de cuestionarios abiertos
El primer tipo de entrevistas son aquellas en las que se realiza una conversa-
ción abierta con el auditado. En estos casos, los resultados de la entrevista de-
penderán de la habilidad del auditor y su experiencia para ir guiando la con-
versación hacia los aspectos más relevantes. Un auditor con experiencia podrá
obtener mejores resultados con una entrevista guiada que con otros tipos de
entrevistas.
Al tratarse de una entrevista no dirigida mediante un cuestionario cerrado,

tanto el auditor como el auditado tienen la libertad de profundizar en los as-
pectos que, a lo largo de la prueba, se consideren más interesantes. Sin embar-
go, el auditor no debe olvidar el objetivo de la prueba y, por lo tanto, tendrá
que organizar mínimamente el plan de la entrevista para asegurarse de que se
tratan los puntos que interesan.
2.3.2. Cuestionarios cerrados
Cuestionarios cerrados. Estas entrevistas son la evolución natural de una labor

de auditoría eficiente. El equipo auditor puede preparar previamente el detalle
de las cuestiones a tratar si conoce bien cuál es el objetivo de la prueba.
En este tipo de entrevistas, el auditor debe ser lo suficientemente flexible para

poder explorar aspectos que queden fuera el contenido de su cuestionario. Al
fin y al cabo, se trata de una prueba en la que el auditado proporciona la infor-
mación relevante, y es posible que no sea posible obtener las evidencias desea-
das mediante un cuestionario absolutamente cerrado. Por otro lado, este tipo
de pruebas pueden ser realizadas por personal auditor con poca experiencia.
En cualquiera de los dos casos, el equipo auditor no debe olvidar en ningún

momento que la prueba tiene como objeto el descubrimiento de evidencias de
auditoría relevantes. En ningún caso, las entrevistas deben tomar un carácter
acusatorio o comprometedor para el entrevistado. Siempre se debe mantener
un buen grado de colaboración para que la información recogida sea confiable.
Por otra parte, siempre que sea posible, el auditor deberá obtener evidencias
que corroboren lo expuesto por el entrevistado. En caso contrario, la única
evidencia la constituirá el propio contenido de la entrevista. Esto último es
el motivo por el cual se recomienda elaborar actas de todas las reuniones, y
mantenerlas como evidencia.
2.3.3. Desarrollo de las entrevistas
De manera general, el desarrollo de una entrevista de cualquiera de los tipos

sería:
• Preparar la reunión:
– Si se trata de una entrevista con un cuestionario cerrado, preparar el
cuestionario o seleccionarlo si es que se dispone de él previamente.
– Preparar una agenda de los puntos a tratar a grandes rasgos y el tiempo

estimado de duración (se recomienda no exceder la hora, o dos horas
como máximo).
• Comunicar la agenda al auditado y concertar los aspectos logísticos de la

entrevista.
• Realizar la entrevista tomando nota de todo lo desarrollado en la misma

y recogiendo toda la información que el auditado pueda proporcionar. Es
interesante notar que existe la posibilidad de grabar el contenido de la en-
trevista. Suele ser muy poco habitual y, en todo caso, siempre deberá estar
explícitamente declarado y acordado con anterioridad, y reflejado en el
plan de auditoría y en el acuerdo de confidencialidad firmado entre audi-
tor y auditado, indicando la finalidad y el tratamiento que se dará a esos
contenidos de audio o vídeo. Igualmente, en la actualidad existen medios
técnicos para que las entrevistas no tengan que ser realizadas de manera
presencial, medios que emplean recursos tecnológicos de videoconferen-
cia. Estos medios permiten, además de la reunión remota, compartir recur-
sos informáticos, realizar demostraciones, revisiones o consultas de docu-
mentos ofimáticos durante la reunión y, en algunos casos, grabar la sesión.
Estas grabaciones deben ser tratadas del mismo modo que las grabaciones
de audio comentadas anteriormente.
• Elaborar un acta y obtener la aprobación documentada por parte del en-
trevistado.
2.3.4. Cuestionarios de autoevaluación
Es interesante notar que, en el caso de emplear cuestionarios cerrados, existe

la posibilidad de preparar el contenido de la entrevista de tal manera que ésta
pueda ser respondida autónomamente por el entrevistado.
Los cuestionarios de autoevaluación pueden utilizarse si el equipo auditor co-

noce bien cuál es el objetivo de la prueba, puede preparar previamente el de-
talle de todas las cuestiones a tratar, y puede preparar el modo de recogida de
la información. De esta manera, se realizan más pruebas simultáneamente con
unos recursos de auditoría menores. Sin embargo, se tienen que contrastar los
resultados de los cuestionarios para garantizar la calidad de la información re-
cogida. Por lo tanto, es responsabilidad del auditor jefe el hecho de determinar
el uso o no de este tipo de pruebas, documentar las razones que posibilitan su
uso y describir el modo en que se desarrollará la prueba.
Es interesante apuntar que, en la comunidad auditora de sistemas de infor-

mación, existen cuestionarios de autoevaluación para distintas temáticas. Por
ejemplo, cabe destacar el SANS Institute, que facilitaba un cuestionario de au-
tocomprobación del nivel de implantación de los controles de las normas ISO/
IEC 27002, pero de su versión de 2005. Hoy por hoy no ha sido actualizado,
pero es una buena referencia para este tipo de documentos. Sin embargo, el
equipo auditor debe conocer y estudiar muy bien estas herramientas antes de
aplicarlas de manera directa. Se requiere un estudio previo y una adaptación
a las necesidades de la asignación de auditoría, y siempre es deseable que el
equipo auditor prepare sus propios cuestionarios en base a su experiencia.
Por otra parte, se ha de tener en cuenta que, en algunas circunstancias, las

organizaciones auditoras no permiten el uso de esta técnica. Esto es debido al
hecho de que la parte auditada puede carecer de la suficiente independencia a
la hora de responder a ciertas cuestiones, y el auditor no tiene posibilidad de
realizar otro tipo de preguntas para contrastar la veracidad de la respuesta. Por
tanto, esta técnica puede ir en contra de los principios de auditoría de "debido
cuidado profesional" o de "conducta ética".
Cabe mencionar que distintas organizaciones han preparado cuestionarios pa-

ra que las entidades puedan realizar un ejercicio de autoevaluación propio. Es-
te ejercicio puede tener validez de manera interna a la organización. En otras
ocasiones, las organizaciones auditoras han empleado estos cuestionarios co-
mo un elemento para la promoción de la labor de auditoría, como apoyo a
la función de auditoría interna, y también como herramienta para mejorar la
concienciación en materia de seguridad de la información.
Cuestionarios de autoevaluación del PCI Security Standards

Ved también
Council
Este tema se trata también en
el módulo 4.
En este apartado, veremos un ejemplo de aplicación de los cuestionarios de
autoevaluación en la auditoría de sistemas de información en entidades que
se encuentran sujetas al cumplimiento del PCI DSS. Nota
El PCI-SS Council recomienda

El PCI DSS Council creó en 2008 la posibilidad de que las auditorías de PCI se que el acompañamiento para
la cumplimentación del SAQ
realicen de manera interna, mediante la cumplimentación de un cuestiona-
y del AoC sea por un “ISA - In-
rio de autoevaluación. De este modo, aquellos comercios (denominados mer- ternal Security Assessor” o un
“QSA - Qualified Security Audi-
chants) y proveedores de servicio que hayan sido autorizados por los emisores tor”.
de tarjetas (las grandes corporaciones de la industria de las tarjetas de crédito)
no necesitarán realizar una auditoría de cumplimiento del PCI-DSS in situ en
sus instalaciones; podrán realizar la evaluación ellos mismos. A pesar de que
es posible que estos cuestionarios sean seguidos y completados por el propio
auditado, el PCI-DSS Council recomienda que se cuente con la asistencia de
asesores, por lo que la labor de un auditor también puede ser requerida en
estos casos. Junto con el resultado del ejercicio de autoevaluación, la entidad
autoauditada debe cumplimentar una declaración de cumplimiento (llamado
AoC - Attestation of Compliance). Este documento deberá facilitarse a otras
entidades que, legítimamente, le pudieran exigir el cumplimiento con el es-
tándar PCI-DSS.
Existen diferentes tipos de documentos relacionados con el mercado de las

tarjetas de crédito para realizar las auditorías. Entre ellos, encontramos los de-
nominados PCI SSC self-assessment questionnaire (SAQ). El PCI-SS Council ha
identificado que, a lo largo de la vida del estándar, existen diversas situaciones
en los merchants y también en los proveedores de servicios. Por esta razón,
existen distintos tipos de cuestionarios SAQ, los cuales se corresponden con
los distintos tipos de participantes en el mercado y el tratamiento que éstos
realizan con los datos de las tarjetas. Cada entidad que esté obligada al cum-
plimiento del PCI-DSS deberá determinar si es elegible para realizar el ejerci-

cio SAQ. En caso afirmativo, la entidad deberá cumplimentar el cuestionario
y el documento de declaración de cumplimiento. Siempre es recomendable
dirigirse al sitio oficial de PCI-SS Council (en su sección de documentación) y
revisar las últimas directrices publicadas y los distintos tipos de SAQ existen-
tes, así como contar con un asesor PCI que ayude a determinar cuál es el más
adecuado por la actividad que se realiza. Hasta la fecha de publicación de este
material, se han definido tipos distintos:
1) A - Comercios que han delegado todas las funciones relacionadas con tarje-
tas de pago en un tercero validado por la PCI DSS, de tal forma que el comercio
en cuestión únicamente almacena reportes o recibos en papel con datos de
tarjetas. Es decir, todos aquellos que gestionan transacciones no presenciales
(comercio electrónico y/o pagos por teléfono o correo) y que no almacenan,
procesan o transmiten ningún dato de tarjeta de pago en formato electrónico
en sus sistemas o instalaciones. No es aplicable a los canales presenciales.
2) A-EP - Aplicables a organizaciones que utilizan el comercio electrónico co-

mo canal de pago y cuyo sitio web no recibe datos de tarjetas de pago, pero
puede afectar la seguridad de la transacción y/o la integridad de la página que
acepta los datos de tarjeta de pago provenientes del cliente. Es decir, aquellos
comercios que han delegado de forma parcial su canal de pago vía comercio
electrónico a un tercero certificado por la PCI DSS y que, en sus sistemas o ins-
talaciones, no almacenan de forma electrónica, procesan o transmiten ningún
dato de tarjeta de pago. Es únicamente para entidades que hacen comercio
electrónico.
3) B - Comercios que procesan datos de tarjetas de pago únicamente por me-

dio de máquinas impresoras o terminales independientes que conectan por
vía telefónica (no conectada a redes de datos) para hacer las operaciones de
validación. Pueden ser comercios que procesen transacciones presenciales o
pagos por teléfono o correo (tarjeta no presente) y que no almacenen datos
de tarjetas de pago en ningún sistema informático. No es aplicable a comercio
electrónico.
4) B-IP - Comercios como los anteriores, pero en estos casos el terminal de

punto de venta validado por la PCI-DSS conecta a través de tecnologías IP.
Tampoco es válido para comercio electrónico.
5) C - Comercios cuya aplicación de pago (por ejemplo, un sistema de pun-

to de venta) está conectada a Internet (por ejemplo, a través de DSL, cable
módem, etc.). Los comercios que reporten el cumplimiento usando el SAQ C
certifican que procesan datos de tarjeta de pago empleando un terminal de
punto de venta (TPV/POS) u otros sistemas de aplicación para pagos conecta-
dos a Internet. Pueden ser comercios que procesen transacciones presenciales

o pagos por teléfono o correo (tarjeta no presente) y que no almacenen datos
de tarjetas de pago en ningún sistema informático.
6) C-VT - Comercios que introducen los datos, transacción a transacción, en

una aplicación vía Internet facilitada por un tercer proveedor validado por
la PCI DSS, y no almacenan los datos de la tarjeta. Tampoco es válido para
comercio electrónico.
7) P2PE - Comercios que están empleando terminales de pago de hardware in-

cluidos y gestionados por un proveedor certificado P2PE, sin almacenamiento
electrónico de datos de tarjetas de pago.
8) D - Dentro de este tipo se distingue:
• D - Merchant: comercios elegibles que no concuerdan con ninguno de los

criterios de elección descritos en los anteriores tipos de SAQ.
• D - Service provider: proveedores de servicio definidos por las marcas de

pago como elegibles para reportar su cumplimiento empleando un SAQ.
A continuación, se presentan de forma resumida las preguntas más específicas

de auditoría incluidas en el cuestionario (tomado del SAQ-D Merchant). Como
se puede observar, algunas preguntas pueden tener un carácter más técnico y
otras uno más organizativo. Por otro lado, algunas preguntas son más sencillas
de responder que otras, aunque requieran algún tipo de comprobación técni-
ca. Las preguntas más difíciles requieren un conocimiento de la Norma PCI-
DSS, de su interpretación y de su implementación. La siguiente tabla muestra
preguntas con un carácter técnico.
Preguntas del PCI-DSS SAQ - D para el requerimiento 1

La siguiente tabla muestra preguntas con un carácter más organizativo:
Preguntas del PCI-DSS SAQ - D para el requerimiento 12
En los casos en los que el requerimiento 11.2 aplica además del ejercicio de
autoevaluación, se exige la realización de algún tipo de auditoría técnica de
vulnerabilidades por parte de un tercero. Este análisis debe solicitarse a un
proveedor de escaneo de vulnerabilidades aprobado por el PCI-DSS Council,
denominado ASV - Approved Security Vendor. Estos proveedores se encuentran
listados en el sitio web del PCI-DSS Council y son los únicos que pueden rea-
lizar y emitir un informe de escaneo. Estos escaneos se realizan sobre la super-
ficie del CDE (card holder environment) expuesta a Internet y también aquellos
sistemas que no forman parte directa pero que podrían dar acceso al CDE (por
ejemplo, servicios de VPN). Hay que notar que es un requerimiento para un
escaneo oficial de un ASV que no haya ningún sistema de seguridad que de
manera activa bloquee posibles ataques. Esto significa que se deben desactivar
sistemas como IDS/IPS (Intrusion Detection/Prevention System) o bien firewall
de aplicación como WAF (Web-application firewall) u otros de cualquier otro
tipo. Respecto a las pruebas que se realizan, son fundamentalmente análisis de
vulnerabilidades conocidas (ver más adelante en este módulo) y no incluyen
pruebas manuales ni tampoco comprobaciones de explotación de las vulne-
rabilidades ni de escaladas de privilegios o movimientos laterales. Son básica-
mente pruebas automatizadas que buscan identificar todas las posibles vulne-
rabilidades conocidas. No se hace búsqueda de posibles vulnerabilidades no
conocidas (llamadas 0-day) en productos comerciales ni tampoco búsqueda de
vulnerabilidades introducidas en aplicaciones propietarias.
En el caso de ser aplicable el tipo de cuestionario D, se está obligado a solicitar un análisis

de vulnerabilidad de los sistemas intervinientes en el procesado de los datos de las tarjetas
de crédito ya que el requerimiento 11.2 aplica.
Por lo tanto, en el caso de las auditorías de cumplimiento de PCI-DSS, pode-

mos decir que las entidades están autorizadas oficialmente a realizar auditorías
internas con validez como auditorías de terceras partes. Sin embargo, este es
un caso poco habitual.
3. Visitas de auditoría
Otra faceta de las pruebas de auditoría que no comporta una gran componen-
te técnica es la realización de visitas de auditoría. Además de las visitas perti-
nentes y necesarias para el desarrollo de entrevistas o ejecuciones de pruebas
técnicas sobre sistemas TIC, el auditor puede realizar también "visitas de audi-
toría". Éstas se realizan para hacer observaciones directas sobre circunstancias
físicas relevantes en distintas dependencias de la instalación del auditado (por
ejemplo, CPD), o comprobaciones sobre el modo de trabajar del personal. Es
habitual también que, en este tipo de visitas en las que se observa al personal
en sus tareas profesionales, se hagan breves entrevistas con el objeto de clari-
ficar aspectos observados o solicitar algún tipo de demostración; del mismo
modo que en el caso de las entrevistas, cuando el auditor hace uso de las vi-
sitas de auditorías, emplea también una lista de comprobaciones preparadas
con antelación.
Eludiendo el hecho de que las visitas a las instalaciones del auditado son ne-
cesarias para la realización de otras pruebas (entrevistas, ejecución de pruebas
técnicas, etc.), el objetivo de estas visitas puede incluir:
• Pruebas� de� cumplimientos� de� controles. Pruebas de cumplimiento de

controles. Se trata de revisar la implantación real y efectiva de controles
que afectan a aspectos técnicos de las instalaciones del cliente:
– Controles de acceso físico a las instalaciones.
– Condiciones de las salas de procesado de datos o datacenters, teniendo

en cuenta el control de acceso, la protección contra incendios, la pro-
tección del suministro eléctrico, alarmas, etc. Asimismo, la revisión de
las medidas de protección de otros elementos de la infraestructura de
TIC, como puede ser el cableado estructurado del edificio.
– Seguimiento por parte de los empleados de las normativas de seguri-

dad.
– Ejecución de los procedimientos operativos que se hayan descrito en

relación a la operación, gestión y mantenimiento de los sistemas de
información y comunicaciones.
Las pruebas de cumplimiento de controles consistirán en una combi-
nación de visitas (que pueden ser guiadas o no) en las que el auditor
se desplazará libremente por las instalaciones, tomando anotaciones y
realizando breves entrevistas con el personal.
La política de mesas limpias, o el uso correcto de los mecanismos de identificación de

personas, etc.
• Complementar�auditorías�técnicas. Las visitas de auditoría pueden tener

también por objetivo detectar y evidenciar problemas o vulnerabilidades
en los procesos organizativos. Estas visitas harán especial hincapié en los
problemas relacionados con el acceso físico y la introducción de equipa-
miento no autorizado en instalaciones técnicas (las salas de procesado de
datos, pero también las instalaciones de usuario). Por otro lado, la realiza-
ción de ciertas pruebas técnicas requerirá también visitar las instalaciones
del auditado y trabajar desde ellas.
• Complementar�aspectos�tratados�en�una�entrevista. Complementar as-

pectos tratados en una entrevista. La entrevista proporciona al auditor un
entendimiento rápido de una determinada situación. Sin embargo, la in-
formación que se obtiene puede estar sesgada, puesto que el interlocutor
puede estar involucrado en el hecho en cuestión. Asimismo, es posible que
se hayan empleado cuestionarios para agilizar el proceso de auditoría, pe-
ro que la información obtenida a partir de éstos sea parcialmente errónea.
Esto puede suceder por errores involuntarios o por la ocultación intencio-
nada de algunos elementos desfavorables para el auditado.
Para reducir el riesgo de obtener información equivocada, existe la posibi-
lidad de realizar una segunda ronda de entrevistas. Éstas requerirán menos
esfuerzo que el necesario en una primera ronda, y permitirán comprobar
puntos que no hayan quedado claros.
En cualquier caso, es necesario contrastar los aspectos declarados por los
interlocutores en visitas e inspecciones. Tal cosa permite corroborar y res-
paldar la información obtenida con evidencias más objetivas (por ejem-
plo, registros de funcionamiento, actas, documentos firmados, etc.). Estas
evidencias se podrán considerar hallazgos de auditoría.
En resumen, podemos afirmar que la realización de visitas de auditoría es una

técnica complementaria a las entrevistas, que permite inspeccionar de forma
efectiva el modo en que se ejecutan y organizan ciertas tareas.
Las características, en términos de suficiencia, validez, confiabilidad y relevan-

cia de las evidencias que se obtengan, a partir de una visita de auditoría, de-
penderán del grado de detalle con el que se realice la visita. En este sentido,
podemos distinguir tres niveles de visitas:
• Pruebas de observación. Consisten en la observación de la ejecución de

una actividad, proceso o implantación de un control (en oposición a la
lectura de la documentación sobre el control producida por la propia or-
ganización auditada). Esta prueba tiene por objetivo determinar si la ac-
tividad o el control funciona según lo previsto (o se configura según lo

previsto), y si hay errores, omisiones o inconsistencias en la operación o
configuración.
• Pruebas de inspección. Este tipo de prueba complementa la prueba de ob-

servación con una investigación activa para obtener otros argumentos,
con el objetivo de mejorar la confianza en la conclusión. Este tipo de prue-
ba implica la obtención de evidencias más objetivas que las simples obser-
vaciones del auditor.
• Pruebas de análisis. Como complemento final de las pruebas de inspec-

ción y observación, esta prueba incluye el análisis cuidadoso y detallado
de la información recopilada durante la inspección. El objetivo es nueva-
mente mejorar la confianza en las conclusiones. Las pruebas de análisis se
realizan mediante un proceso realimentado de inspección, observación y
análisis de los resultados, hasta obtener evidencias válidas como hallazgo
de auditoría.
El esfuerzo requerido por el equipo auditor será mayor cuanto más minuciosa
sea la revisión que se realice en la visita. Por tanto, la elección del tipo de acti-
vidades a desarrollar será una decisión del auditor jefe que deberá estar refle-
jada en su informe. Aunque esté basada en aspectos de eficiencia económica,
esta decisión no debe comprometer la consecución del objetivo de la auditoría
según los niveles de calidad y profesionalidad exigibles.
4. Pruebas técnicas de sistemas de información y

comunicaciones
Finalmente, en esta sección trataremos las técnicas de auditoría que tienen un

componente más técnico y que se aplican sobre los sistemas de información.
Hasta el momento, las técnicas que se han repasado permiten evaluar la efica-
cia de controles con una componente más organizativa. Se han tratado con-
troles relacionados con políticas, normas y procesos aplicados para controlar
especialmente el modo en que se operan, gestionan y mantienen los sistemas
TIC. Sin embargo, gran parte de estos controles tienen una parte de su imple-
mentación puramente técnica. Aquí es donde entra, por tanto, la auditoría
técnica de los sistemas TIC.
El conjunto de pruebas asociado a una auditoría técnica es muy heterogéneo,

puesto que incluye toda acción que suponga la ejecución de alguna compro-
bación sobre algún tipo de sistema técnico del control de seguridad.
Por otra parte, es interesante constatar que, en ocasiones, las organizaciones

solicitan a los auditores la realización de este tipo de pruebas sin enmarcarlas,
específicamente, en un programa de auditoría de un SGSI. Las pruebas suelen
limitarse a infraestructuras expuestas a Internet, o a redes corporativas muy
grandes, y tienen como objetivo determinar la seguridad de las mismas y el
modo en que se encuentran preparadas para afrontar ataques externos.
4.1. Auditoría de los mecanismos de control de los riesgos físicos
La mayoría de las pruebas técnicas se realizan sobre los sistemas de informa-

ción y comunicaciones. Sin embargo, si los recursos de una auditoría o su ob-
jetivo lo justifican, también pueden incluirse pruebas técnicas sobre sistemas
como:
• Mecanismos de control de acceso físico.
Barreras de acceso, sistemas de apertura de los accesos físicos, mecanismos para la trazabi-
lidad de los accesos (cámaras, registros de actividad, etc.). En general, cualquier elemento
que participe en el control de los accesos físicos a las instalaciones.
• Suministro eléctrico.
Suministro de los proveedores, dispositivos de redundancia, sistemas de alimentación

ininterrumpida, generadores eléctricos diesel, etc.
• Sistemas de control de temperatura y humedad.
Redundancia de los sistemas de ventilación, sistemas de monitorización de temperatura

y humedad, etc.
• Sistemas de detección y extinción de incendios.
• Sistemas de videovigilancia y alarmas contra intrusiones físicas.
Las pruebas técnicas a realizar sobre este grupo de sistemas verificarán que se
cumplen los objetivos y que se respetan los marcos regulatorios, especialmente
aquellos relacionados con sistemas de extinción de incendios o de suministro
de energía eléctrica. Por lo tanto, la realización de pruebas técnicas sobre estos
sistemas requerirá unos conocimientos muy especializados en áreas diferentes
(electrotecnia, sistemas de climatización y control de condiciones de hume-
dad, alarmas, etc.). Puede que el auditor carezca de estos conocimientos, por
lo que será necesario, en estas ocasiones, contar con expertos que realicen las
pruebas. Sin embargo, será el equipo auditor quien decidirá en último caso
sobre sus objetivos.
Por otra parte, es interesante destacar que los sistemas industriales convergen
cada vez más con los sistemas de información y comparten algunos subsiste-
mas. Esto abre toda una nueva área para la auditoría de sistemas relacionada
con la seguridad de los sistemas de control industrial. Las técnicas que se em-
plearán para auditar el uso de las TIC, en los sistemas de control industrial,
serán muy similares a las que se examinarán en el resto del módulo. No obs-
tante, se requieren ciertos ajustes para tener en cuenta las circunstancias espe-
cíficas de estos sistemas.
4.2. Auditoría técnica de sistemas, comunicaciones y

aplicaciones
En el resto del módulo, nos centraremos en las pruebas para la revisión de la

implantación de controles técnicos aplicados sobre sistemas de información
y redes de comunicaciones.
Cuando se trata de revisar la implantación de controles en sistemas de infor-

mación, habitualmente se habla de auditorías técnicas o análisis de vulnera-
bilidades de sistemas. Aunque el alcance de las pruebas que un auditor podrá
realizar es muy amplio, podemos realizar la siguiente división muy general:
• Análisis de vulnerabilidades de sistemas o redes.

• Análisis de vulnerabilidades de hosts.
• Auditoría de aplicaciones.
Esta separación se basa en que los controles técnicos se aplican a distinto nivel
en la infraestructura de TIC. Un gran número de controles se implementan en
partes de la infraestructura general, compartida por muchos servicios, mien-
tras que otros controles son específicamente diseñados e implementados en
un sistema o aplicación concreta. De este modo, podemos decir que existen,
en primer lugar, pruebas más orientadas a obtener una visión general del esta-
do de la infraestructura y de los elementos críticos comunes a varios servicios.
Ejemplos de estos elementos pueden ser: servidores de nombres (DNS), elementos de

conmutación, enrutamiento y filtrado de paquetes (switches, routers y firewalls), filtros de
aplicación (proxys SOCK, aplicaciones específicas o proxys web), entre otros.
La revisión de este tipo de infraestructura se denomina "análisis de vulnera-

bilidades de sistemas o redes". En segundo lugar, existen pruebas que buscan
examinar cómo se implementan los controles en un sistema, entorno o apli-
cación concretos.
Por otra parte, la diferencia entre el análisis de vulnerabilidades de sistemas

o redes y el análisis de hosts se traduce, básicamente, en el punto desde don-
de se realiza el análisis. En el análisis de sistemas o redes, las vulnerabilidades
se buscan desde fuera del sistema, mediante la red de comunicación. En cam-
bio, en el análisis de hosts, las vulnerabilidades se buscan desde la máquina
en cuestión, teniendo acceso local a la misma. Con este tipo de análisis, pode-
mos realizar comprobaciones más exhaustivas. Los resultados serán similares
a aquellos obtenidos por medio del análisis de vulnerabilidades de sistemas o
redes. Sin embargo, en el primer caso se obtendrán resultados más ampliados,
gracias a las comprobaciones que sólo pueden hacerse con un acceso local al
sistema: errores en la configuración de los permisos de acceso a ficheros, con-
figuraciones contrarias a las políticas de seguridad, software malicioso, etc.
En este sentido, también es interesante destacar que el objetivo es la búsqueda

de vulnerabilidades en los sistemas TIC. La pregunta que podríamos hacernos
ahora es: ¿qué se entiende por vulnerabilidad en el contexto de una prueba
técnica de auditoría?
Vulnerabilidades en el contexto de una prueba de auditoría
De un modo general, en el ámbito del análisis de riesgos, se entiende por

vulnerabilidad cualquier problema en la organización que pudiera ser
aprovechado por un atacante para materializar un impacto sobre los ac-
tivos de la organización. En nuestro contexto, una vulnerabilidad ten-
drá la misma definición desde una visión de alto nivel, pero podemos
concretar más la definición desde una perspectiva más próxima al pro-
blema que nos concierne. Entenderemos por vulnerabilidad cualquier
problema o error en la programación, configuración o especificación
(en los casos más graves) en un componente del sistema de información.
Ejemplos de vulnerabilidades
Pueden ser: errores en un protocolo, contraseñas débiles, sistemas no actualizados con

los últimos parches de seguridad, servicios de red con puertos abiertos y sin conocimien-
to por parte del equipo de operación y mantenimiento, uso de servicios peer-to-peer no
autorizados, recursos compartidos no autorizados, instalaciones de accesos remotos no
autorizados (por ejemplo, VNC o Terminal Server de Microsoft), entre otros.
Un análisis de vulnerabilidades consistirá en el proceso de localizar y reportar,

en un informe, las vulnerabilidades existentes en los sistemas que están bajo
el alcance de la auditoría. Es importante remarcar que el análisis no examinará
aquellos controles que se aplican internamente en las aplicaciones de negocio,
que tratan finalmente la información y son específicas de las necesidades de
negocio de la organización. El análisis de vulnerabilidades estudiará sólo la
implantación de los controles técnicos de seguridad que afectan a las infraes-
tructuras de comunicaciones y de los sistemas en sus partes más básicas (siste-
mas operativos, configuración de aplicaciones proporcionadas por un tercero,
etc.).
4.3. Muestreo en las pruebas de auditorías técnicas a sistemas

TIC
La importancia de identificar, correctamente, los problemas de implantación

de los controles técnicos no es tan sólo por el simple hecho de realizar una
labor de auditoría con una elevada excelencia profesional, sino que tiene un
valor intrínseco y conlleva beneficios para el auditado.
En una auditoría de segunda o tercera parte, el objetivo principal de la audi-

toría es responder si el objeto auditado se ajusta al marco de referencia. El au-
ditor realizará un muestreo de pruebas de manera que se minimice el riesgo de
auditoría; estas pruebas se ejecutarán para determinar la conformidad con el
marco de referencia. Este proceso se detendrá cuando el auditor haya encon-
trado un número significativo de no conformidades, y la auditoría se conside-
rará terminada. En estos tipos de auditoría, el resultado tiene valor tanto para
el auditado como para el cliente de la auditoría.
Por otro lado, tal y como se ha dicho anteriormente, las auditorías técnicas
sobre los sistemas TIC suelen ser, en la mayoría de casos, auditorías de primera
parte, donde el auditado y el cliente de auditoría son la misma entidad. En
este caso, el cliente de la auditoría, al ser el objeto auditado, no está interesado
únicamente en determinar el grado de conformidad con el marco de referen-
cia, sino en el propio resultado de las pruebas, debido al beneficio que conlleva
de cara a aplicar mejoras en sus sistemas TIC. Por lo tanto, en las auditorías de
primera parte puramente técnicas, el auditado no busca realizar un muestreo
de pruebas, sino que desea que se analice toda la infraestructura que queda
bajo el alcance de la auditoría. Si el auditado ha de ajustarse a unos determi-
nados recursos, deberá renegociar el alcance.
4.4. Valoración de las vulnerabilidades de los sistemas TIC
Como resultado de las pruebas técnicas sobre los sistemas TIC, el auditor de-
tectará vulnerabilidades en la infraestructura de los mismos. El beneficio que
el cliente de la auditoría obtiene de la determinación de estas vulnerabilidades
se obtiene cuando se evalúa el riesgo que éstas conllevan.
A continuación, mostramos un diagrama ya presentado para repasar los dis-

tintos factores que determinan el riesgo de una vulnerabilidad.
Factores que determinan el riesgo
Es habitual valorar el riesgo en función de:
• Valor del activo amenazado.

• Vulnerabilidades que podrían ser aprovechadas en un ataque.
• Probabilidad de que se materialice la amenaza.
• Valor del daño que provocaría la materialización de la amenaza.
Para valorar el riesgo que conlleva una vulnerabilidad, debe evaluarse una se-
rie de factores que están fuera del alcance del auditor. El auditor no está en
disposición de valorar correctamente la criticidad y el aporte a la cadena de
valor que puede tener el activo en cuestión. Sin embargo, sí que está en con-
diciones de facilitar una visión de las características de la vulnerabilidad, la
cual permitirá al auditado determinar:
• Qué tipo de ataque podría llegar a explotar la vulnerabilidad.

• En qué condiciones podría explotarse.
• Con qué facilidad podría explotarse.
• Qué tipo de impacto provocaría su explotación (aunque el auditor no pue-
de valorar este impacto).
Teniendo en cuenta estos parámetros, el auditor puede ofrecer una valoración

de la gravedad de la vulnerabilidad como valor añadido a su trabajo. Por su
parte, el auditado aportará el conocimiento de la valoración del activo y la
estimación del impacto.
A partir de la valoración de la vulnerabilidad, que representa la probabilidad de

ocurrencia de la amenaza en cierto modo, puede determinarse finalmente el
riesgo. La asignación de auditoría no incluye habitualmente todo el proceso de
determinación del riesgo, pero sí, al menos, la valoración de la gravedad de la
vulnerabilidad. Incluso si el auditado no llegara a evaluar el riesgo resultante,
esta valoración le permitirá priorizar las acciones correctoras resultantes de la
auditoría.
La labor de valorar una amenaza no es sencilla. Con la gran cantidad de tipos

de hardware, aplicaciones, interrelaciones entre sistemas, etc., es muy difícil
armonizar los métodos de valoración de una vulnerabilidad. Diferentes pro-
veedores de servicios de avisos de vulnerabilidades emplean sistemas de pun-
tación propios, pero pocos son aplicables de manera general en cualquier si-
tuación. Además, sus mecanismos de puntación no son públicos y revisados
por una comunidad abierta de especialistas. Por ello, para facilitar la labor de
valoración de las amenazas, se ha desarrollado un sistema de puntación cohe-
rente y sistemática de vulnerabilidades: el CVSS (common vulnerability scoring
system).
4.4.1. CVSS (common vulnerability scoring system)
(4)
El CVSS4 fue desarrollado inicialmente por un organismo estadounidense: el A fecha de realización de este
material, la versión publicada es la
5
NIAC (National Infrastructure Advisory Council ). Sin embargo, éste designó 3, pero está en preparación la ver-
sión 4 que contendrá modificacio-
a la comunidad internacional de Equipos de Respuestas ante Incidentes de Se- nes sustanciales.
guridad, representados en el FIRST (Forum of Incident Response and Security
Teams), como la institución que ha de continuar su desarrollo y promoción. (5)
National Infrastructure Advisory
El sistema ofrece como mayor beneficio la estandarización del mecanismo de Council, entidad parte del Depar-
tamento de Seguridad de la Na-
puntación de las vulnerabilidades. Este sistema permite a una organización ción (Department of Homeland Se-
curity) dedicada a ofrecer conse-
avanzar en el camino de normalizar la política de solución de problemas y res- jo al presidente de Estados Unidos
puesta a las vulnerabilidades. Una vez se obtiene una puntuación normalizada sobre la seguridad de los sistemas
críticos del país y de los sistemas
de las vulnerabilidades, pueden implementarse otros sistemas que establezcan de información que les dan sopor-
el tiempo en que debe darse respuesta a cada vulnerabilidad. te.
Enlace recomendado
El sistema de valoración CVSS está organizado en tres grupos de métricas que
reflejan tres aspectos alrededor de la evaluación del riesgo que conlleva una La especificación del siste-
vulnerabilidad. Estos grupos, junto con sus métricas se muestran en el siguien- ma de puntuación, así como
otros materiales interesan-
te diagrama. tes como ejemplos y calcu-
ladoras, puede encontrarse
en la página oficial: https://
www.first.org/cvss
Métricas de CVSS. Fuente: Especificaciones oficiales de CVSS versión 3, versión en inglés
Cada métrica recoge factores (o aspectos) comunes de una vulnerabilidad, y

facilita una visión de conjunto de las distintas facetas a considerar para ges-
tionar la vulnerabilidad. El método de puntuación consiste, básicamente, en
valorar cada uno de estos factores. La valoración no se realiza numéricamente,
sino mediante la selección de un calificativo (por ejemplo: ALTO, BAJO, EN
RED, LOCAL, MÚLTIPLE, SENCILLO, etc.). Estos calificativos se encuentran
descritos en la metodología.
El grupo de métricas básicas proporciona la información más técnica sobre las

condiciones de la vulnerabilidad. Las métricas de temporalidad y de entorno
tienen como objetivo contextualizar la vulnerabilidad. A lo largo del tiempo,
se dan circunstancias que hacen variar la valoración. Del mismo modo, la va-
riación de las circunstancias de cada entorno en que se evalúa la gravedad
también hace variar la valoración.
El grupo de métrica básica es el único requerido por el sistema de valoración

CVSS. Habitualmente, el equipo auditor evalúa esta métrica cuando se detecta
una vulnerabilidad. El sistema reconoce los siguientes grupos como opciona-
les y proporciona más refinamiento al mecanismo de evaluación. El grupo de
métrica de la temporalidad requiere un seguimiento en el tiempo de las cir-
cunstancias que acompañan a la vulnerabilidad, y suele ser facilitado y man-
tenido por proveedores del servicio de vulnerabilidades. Finalmente, el grupo
de métrica del entorno se somete a la valoración de los usuarios finales del
CVSS. El método descrito por el CVSS da varias indicaciones o consejos sobre
cómo realizar la valoración de cada uno de los factores, para ayudar así a uni-
formizar el uso de este sistema de valoración.
La valoración intrínseca de la vulnerabilidad es el grupo de métricas básicas.

Los grupos de temporalidad y de entorno hacen modificar esta valoración bá-
sica, que es inherente a la propia vulnerabilidad. En cada cálculo se obtiene la
valoración de la vulnerabilidad teniendo en cuenta ya sea el grupo básico, el
básico y el temporal o bien los tres.
A cada valoración (bien solo básica, bien básica y temporal, o básica, temporal
y entorno) se le puede otorgar un valor del 0 al 10 para poder así priorizar
el tratamiento de las vulnerabilidades. Existen unas tablas de conversión de
las valoraciones cualitativas de cada métrica a un valor numérico y unas ecua-
ciones para realizar la evaluación numérica final. En cualquier caso, cuando
se realiza una valoración de criticidad de vulnerabilidades con CVSS, se debe
facilitar el valor numérico final, y los usuarios finales del CVSS deben recibir
siempre los calificativos de cada métrica, puesto que son ellos quienes propor-
cionan la información descriptiva y en cierto modo justifican la valoración
numérica.
La puntación final de 0 a 10 puede ser trasladada a una valoración cualitativa

de acuerdo con esta tabla:
Valoración�cualitativa Valor�CVSS
Ninguno 0
Bajo 0.1 - 3.9
Medio 4.0 - 6.9
Alto 7.0 - 8.9
Crítico 9.0 - 10.0
Cada una de las métricas y factores a evaluar tiene la siguiente finalidad:
1)�Métrica�básica. Esta métrica representa las características intrínsecas de la

vulnerabilidad, las cuales no dependen de las circunstancias del entorno ni del
tiempo. Constituye la parte más técnica de la valoración, y es muy objetiva.
Habitualmente, los portales que publican vulnerabilidades facilitan única-

mente la valoración de este grupo de métricas.
Los factores que se han de valorar son (divididos en tres subgrupos):
a) Métricas de explotabilidad: este grupo de métricas hace referencia a las ca-

racterísticas propias del componente que es vulnerable. Se valoran las siguien-
tes métricas:
• Vector de acceso:
– Valores posibles: local / red de área local / red / físico.
– Refleja cómo o desde qué punto de la infraestructura se puede explotar
la vulnerabilidad.
• Complejidad del acceso:

– Valores posibles: alta / baja.
– Mide la complejidad técnica necesaria para que un atacante que dis-

pone del vector de ataque pueda explotar la vulnerabilidad.
• Privilegios de acceso requeridos:

– Valores posibles: ninguno / bajo / alto.
– Nivel de acceso previo que debe tener un atacante para poder explotar
la vulnerabilidad.
• Interacción del usuario:

– Valores posibles: ninguno / requerido.
– Esta métrica mide si el atacante requiere la colaboración (voluntaria

o involuntaria) de un usuario legítimo para poder explotar la vulnera-
bilidad.
b) Métrica de alcance: esta métrica se ha introducido desde la versión 3 del

CVSS. Hace referencia al auge de los entornos virtualizados o sandboxes. Hoy
en día existen vulnerabilidades que pueden permitir al atacante traspasar los
límites de estos entornos de computación donde se está ejecutando el compo-
nente vulnerable. Esta métrica pretende recoger este aspecto.
• Alcance:
– Valores posibles: sin cambio / cambio.
– Refleja si la vulnerabilidad permite cambiar el entorno de compu-

tación o no. Es decir, si permite al atacante traspasar ese entorno y sal-
tar a otro (por ejemplo, en caso de máquinas virtuales, saltar al sistema
operativo del entorno anfitrión de la máquina virtual).
c) Métricas de impacto: estas métricas pretenden recoger de qué manera se

altera la seguridad del entorno.
• Impacto a la confidencialidad, integridad y disponibilidad:

– Valores posibles para cada uno de ellos: bajo / alto.
– Se mide el impacto objetivo que tendría la explotación en cada una

de las dimensiones de la seguridad. La medición se hace por separado,
puesto que pueden no estar afectadas todas las dimensiones en todos
los casos.
2)� Métrica� de� la� temporalidad. Representa las características propias de la

vulnerabilidad (no del entorno en que se presente) que pueden evolucionar
con el tiempo.
Los factores que se han de valorar son los siguientes:
• Madurez del código de explotación:

– Valores posibles: no probado / prueba de concepto / funcional / alta /
sin definir.
– Mide el nivel actual de disponibilidad de técnicas, herramientas o có-
digos para realizar la explotación real de la vulnerabilidad.
• Confianza:
– Valores posibles: desconocido / razonable / confirmado / sin definir.
– Mide alguno de los siguientes aspectos: el grado de confianza que se

tiene en la existencia real de la vulnerabilidad, o la credibilidad de la
fuente que proporciona la información de su existencia.
• Remedio a la vulnerabilidad:
– Valores posibles: solución oficial / parche temporal / solución paliativa
(workaround) / no disponible / sin definir.
– Valora la existencia de una solución definitiva o temporal prorcionada
por el fabricante u otras fuentes.
El valor ''sin definir''
Hay que notar que el valor "sin definir" se ha dispuesto para las situaciones en que no se
desea valorar un determinado parámetro (por falta de información suficiente). Este valor
hace que el factor no se tenga en cuenta en las formulas para el cálculo final.
3)�Métrica�del�entorno. Esta métrica recoge las circunstancias propias de ca-

da entorno en que se esté analizando la vulnerabilidad. Evidentemente, esta
métrica depende totalmente del entorno.
Los factores que se han de valorar se agrupan en dos subgrupos, modificaciones

a las métricas básicas y el impacto real sobre CIA (confidencialidad, integridad
o disponibilidad) en el entorno de la organización:
• Modificación de las métricas básicas: aunque las métricas del grupo básico
son inherentes a las características técnicas propias de vulnerabilidad, es
posible que algún cambio técnico (configuración o arquitectura) pueda
hacer que tenga sentido ajustar alguna de las métricas de este grupo debido
a las circunstancias particulares de la organización.
• Requerimientos de confidencialidad, disponibilidad e integridad:

– Valores posibles: bajo / medio / alto / sin definir.
– Este factor permite particularizar el análisis dependiendo de la impor-

tancia de un determinado activo. Por un lado, la explotación de la
vulnerabilidad puede afectar a alguna de las facetas CID (confidencia-
lidad, integridad o disponibilidad) de la seguridad, y ello está contem-
plado en algunos de los factores de la métrica básica. Pero, en este caso,
lo que se pretende valorar es, para los activos afectados por la vulne-
rabilidad, cuál es la faceta CID de la seguridad que es más importante.
Así, este parámetro nos permitiría afinar el análisis hasta el nivel de
cada uno de los sistemas afectados.
En la actualidad, existen varios proveedores de avisos de vulnerabilidades que

emplean este método para realizar la puntuación. Habitualmente, proporcio-
nan una valoración de las métricas básicas y de temporalidad. Por otro lado,
también es interesante destacar que existen herramientas (en formato web u
hoja de cálculo) que facilitan la aplicación de las fórmulas descritas en el sis-
tema CVSS. Como hemos comentado, este sistema de puntación resulta tam-
bién interesante para los auditores que hagan evaluaciones de seguridad pu-
ramente técnicas de la identificación de vulnerabilidades técnicas, tanto en
infraestructuras como en aplicaciones.
4.5. Auditoría técnica de sistemas y gestión de TIC
Las infraestructuras de sistemas de información, incluso en organizaciones de

tamaño pequeño o mediano, son muy heterogéneas y numerosas. Por tanto,
podemos estimar que el coste de realizar una auditoría detallada de toda la
infraestructura TIC (que incluya los tres tipos de análisis: sistemas, redes, hosts,
y aplicaciones) es demasiado costoso. Incluso en el ámbito de una auditoría
de tercera parte, el equipo auditor reducirá su alcance, ya sea limitando la
profundidad o bien el número de sistemas analizado. Aunque en ocasiones
se solicite al equipo auditor la revisión puntual de algún tipo de elemento de
una infraestructura (o bien él mismo determine la necesidad), realizar todas las
pruebas técnicas en profundidad es inabordable. El enfoque más habitual será
hacer un programa de auditoría que incluya una planificación de los sistemas
y redes a auditar.
En el ámbito de una auditoría de primera parte, el objetivo de la auditoría

sí será probablemente la revisión de la totalidad de la infraestructura. Esta
revisión, sin embargo, se abordará por partes, de una manera planificada. De
esta manera, la auditoría técnica pasa a ser una herramienta más entre las que
se dispone para gestionar los sistemas TIC.
Por otro lado, las técnicas de análisis de vulnerabilidades pueden ser empleadas
para auditar la seguridad de los sistemas en diferentes fases de su implantación
o funcionamiento. A continuación, veremos un posible uso de estas técnicas
para sistemas en desarrollo/despliegue, y otro posible uso para sistemas en
producción.
• Análisis�de�vulnerabilidades�en�sistemas�en�desarrollo�o�despliegue. A
la fase de desarrollo o despliegue de un nuevo sistema puede incorporarse
un proceso de análisis de vulnerabilidades, que se ejecutará de forma sis-
temática antes de la puesta en producción.
• Seguimiento� de� las� vulnerabilidades� en� sistemas� en� producción. So-

meter los sistemas en producción a un análisis de vulnerabilidades puede
conllevar una pérdida de disponibilidad (veremos más adelante cómo esto
es un riesgo cuando se emplean ciertas técnicas). Por ello, en ciertas situa-
ciones puede optarse por una estrategia diferente: vigilancia de las vulne-
rabilidades, que se hace por medio de las siguientes fases:
– Seguimiento de las vulnerabilidades de los sistemas de la organización
a partir de lo publicado por la comunidad de expertos en seguridad.
Existen servicios (algunos gratuitos y otros de pago con distintas cali-
dades y servicios) que informan del descubrimiento de nuevas vulne-
rabilidades.
– Una vez publicada una nueva vulnerabilidad, análisis los sistemas po-
tencialmente vulnerables.
– Aplicación de una política de parcheado de los sistemas vulnerables.

Esta política debería determinar la planificación del despliegue del par-
che en base a su gravedad (empleando, por ejemplo, el sistema CVSS).
– Análisis de vulnerabilidades sobre los sistemas parcheados para su ve-

rificación.
Entre estos servicios, podemos destacar CVE Mitre, Secunia o el servicio del NIST "Na-
tional Vulnerability Database". Algunos de estos servicios permiten filtrar y personalizar
los avisos en función de los activos propios de la organización u ofrecen su información
mediante interfaces públicas para integrar con entornos propios.
4.6. Técnicas de análisis de vulnerabilidades de red o de sistemas
Nos centraremos, a continuación, en las técnicas y herramientas que se pue-

den emplear para realizar un análisis de vulnerabilidades en redes o sistemas.
Asimismo, destacamos que nos centraremos en redes basadas en el protocolo
IP. A pesar de que estas pruebas pueden resultar muy útiles para el auditor, se
ha de tener en cuenta que tienen ciertas limitaciones propias de su enfoque.
Los análisis de vulnerabilidades no serán capaces de detectar ciertos tipos de

puertas traseras, determinados tipos de errores en la configuración de los fire-
walls, o vulnerabilidades explotables únicamente en modo local.
Recordemos que la idea principal sobre este tipo de pruebas es que se reali-
zan desde algunos puntos de la infraestructura (por ejemplo, desde Internet
o desde segmentos de la red corporativa). Es decir, el análisis de la seguridad
no se realiza mirando la configuración de los elementos que componen los
controles, sino que se evalúa utilizando métodos similares a los que utilizaría
un intruso que deseara atacar la infraestructura. Esta es la razón por la que,
para la explicación de las distintas herramientas, emplearemos la misma me-
todología que seguiría un intruso.
Las fases y tareas básicas que componen un análisis de vulnerabilidades de sis-

temas o redes se listan a continuación de forma resumida. Sin embargo, debe
tenerse en cuenta que cada auditor es libre de seguir su propia metodología.
La que se presenta aquí es la más usual y está respaldada por multitud de me-
todologías reconocidas internacionalmente, y es implementada por un gran
número de aplicaciones:
• Enumeración de redes para identificar redes IP y servidores dentro del al-

cance de la auditoría.
• Escaneo masivo de direcciones IP y puertos accesibles desde los distintos
puntos de análisis.
• Análisis automatizado de vulnerabilidades.
• Examen manual de los resultados.
El siguiente gráfico refleja las distintas fases que hemos apuntado para entor-
nos publicados en Internet. En caso de ser sistemas internos, algunas fases po-
drían ser más reducidas.
Fases de un análisis de vulnerabilidades de red
4.6.1. Enumeración e identificación de redes y sistemas
(6)
Esta fase se realizará cuando la organización desee conocer el grado de cono- El término viene del inglés com-
petitive intelligence; la Sociedad de
cimiento de sus infraestructuras, que puede obtenerse desde el exterior. A ve-
Profesionales de Inteligencia Com-
ces, si se tiene la intención de realizar alguna prueba de ingeniería social, esta petitiva (SCIP: www.scip.org), en
Estados Unidos, la define como un
fase se realizará también para conocer el grado de conocimiento de sus infra- proceso ético y sistemático de re-
estructuras que tienen las personas que las operan y mantienen. En esta fase, colección de información, análisis
y diseminación pertinente, precisa,
no se identifican vulnerabilidades del sistema, ya que únicamente se analizan específica, oportuna, predecible y
activa, acerca del ambiente de ne-
fuentes de información pública. A veces, suele denominarse también "análisis
gocios, de los competidores y de la
de inteligencia competitiva6", donde el concepto de "inteligencia" se entiende propia organización.
como la información que se ha obtenido, analizado, comprendido y aprove-

chado.
En esta fase, se emplearán fuentes de información legales y públicas para de-

terminar, lo mejor posible, la estructura TIC bajo el alcance de la auditoría. Se
intentarán identificar
• subredes;
• direcciones IP de hosts;
• funciones que realiza cada sistema;
• nombres de usuarios (inferidos a partir de las direcciones de correo del
personal, por ejemplo);
• teléfonos;
• relaciones entre personas y sistemas;
• información técnica sobre sistemas (sistemas operativos, herramientas em-
pleadas, etc.) que se haya podido filtrar en lugares de información pública
(foros de soporte, por ejemplo);
• etc.
Se tiene que destacar que, en ocasiones, esta fase no es solicitada por los clien-
tes de auditoría, a pesar del indudable beneficio que comporta y, sin duda,
forma parte de cualquier metodología que se emplee para realizar un test de
intrusión desde Internet, sobre todo si es completamente en modo caja ne-
gra. Sin embargo, aunque esta información no resulte relevante al auditado,
sí puede proporcionar al auditor información adicional necesaria para poste-
riores análisis. Por ejemplo, si la auditoría técnica tiene por objetivo determi-
nar la infraestructura de la organización expuesta ante Internet, y el tipo de
auditoría solicitada por el cliente es de "caja negra", la realización de esta fase
será de suma importancia.
Las técnicas más habituales para realizar esta recogida de información son:
Consultas a servidores de nombres de dominio (DNS)
Los servidores de nombres son un elemento crítico para la infraestructura ge-

neral de Internet y para la interna de una organización. Por esta razón, es un
elemento que deberá ser interrogado para realizar esta fase y que, además, pue-
de ser auditado como un elemento más.
El auditor consultará a los DNS para averiguar las direcciones IP de las máqui-
nas, y también para identificar las funciones que estos sistemas hacen, sobre
todo en la parte de la infraestructura que está expuesta en Internet. A partir de
estas consultas, se obtienen las direcciones IP de servidores de correo entrante
(SMTP), servidores web, servidores de nombres, entre otros.
Para interrogar a los servidores de nombres, el auditor puede utilizar distintas

herramientas. En la mayoría de sistemas operativos, se incluyen herramientas
como nslookup, aunque la herramienta dig es más adecuada para este propósito.
Comando�dig
Usage: dig [@global-server] [domain] [q-type] [q-class] {q-opt}

{global-d-opt} host [@local-server] {local-d-opt}
[ host [@local-server] {local-d-opt} [...]]
Where: domain is in the Domain Name System
q-class is one of (in,hs,ch,...) [default: in]
q-type is one of (a,any,mx,ns,soa,hinfo,axfr,txt,...) [default:a]
(Use ixfr=version for type ixfr)
q-opt is one of:
-x dot-notation (shortcut for in-addr lookups)
[. . .]
d-opt is of the form +keyword[=value], where keyword is:
+[no]vc (TCP mode)
[. . .]
global d-opts and servers (before host name) affect all queries.
local d-opts and servers (after host name) affect only that lookup.
-h (print help and exit)
-v (print version and exit)
También existen aplicaciones similares que integran varias herramientas, o

herramientas en línea que permiten realizar consultas DNS con las mismas
facilidades que el comando dig, pero realizado desde otras direcciones IP, dis-
tintas a las empleadas por el auditor, por ejemplo:
• https://www.digwebinterface.com/
• http://www.kloth.net/services/dig.php
• https://www.diggui.com/
En general, existen multitud de aplicaciones similares. Éstas son interesantes

puesto que permiten realizar consultas DNS casi del mismo modo que si se
hicieran con el comando de línea de comandos, por ejemplo, especificando el
servidor DNS contra el que se desea lanzar la petición DNS.
El método más directo, para recopilar información sobre todas las máquinas
contenidas en un DNS, es consultar al propio DNS, lo cual requiere conocer
los nombres de estas máquinas. Para determinar el nombre de una máquina,
pueden realizarse consultas inversas, es decir, solicitar al DNS el nombre de
máquina a partir de su IP. Sin embargo, esto requiere que el DNS tenga intro-
ducido el registro PTR para todas las máquinas, lo que no es muy habitual.
Otro método para determinar el nombre de una máquina es mediante fuerza
bruta. Existen herramientas que permiten automatizar esta consulta masiva y/
o hacer consultas inversas de manera masiva para consultar todo un rango IP.
No obstante, la forma más rápida de obtener los nombres de todas las máqui-
nas sería mediante la realización de una solicitud de "transferencia de zona".
El fichero de DNS zone contiene todos los nombres de máquina para un de-
terminado dominio DNS, incluyendo a veces incluso información acerca de
direccionamientos privados. Las organizaciones, para balancear la carga y me-
jorar la tolerancia a fallos, emplean más de un servidor DNS. Existe, por tanto,
un DNS principal y uno o varios secundarios. Cualquiera de ellos puede ser
consultado, por lo que todos deben tener los ficheros DNS zone sincronizados.
Para sincronizar el contenido de los servidores secundarios con el primario, los
DNS secundarios realizan una solicitud DNS de transferencia de zona. De esta
manera, obtienen una lista completa de los nombres del dominio. Si el DNS
primario no se configura para evitar las transferencias de zona desde cualquier
dirección IP, resulta fácil obtener una lista completa de las máquinas registra-
das en el DNS. Para ello, puede utilizarse el comando ls –d en la herramienta
nslookup, o la opción axfr en el comando dig, o herramientas específicas para
testing de DNS como dnswalk. Es importante notar que el hecho de que un
DNS primario acepte solicitudes de transferencia de zona desde cualquier IP
debería considerarse un error.
Consultas WHOIS a los Network Information Centers (NIC) y a los

Regional Internet Registries (RIR)
Para el correcto funcionamiento de Internet, existen organismos que adminis-

tran las asignaciones de direcciones IP (los RIR) y otros que administran las
asignaciones de nombres de dominio (los NIC).
Ambos tipos de organismos mantienen las bases de datos WHOIS, que alma-
cenan información registrada correspondiente a dominios y segmentos de di-
recciones IP. La gestión de los diferentes segmentos de direcciones IP es luego
delegada a otras entidades: los ISP. Las bases de datos WHOIS son consultables
mediante herramientas en nuestros propios sistemas operativos (por ejemplo,
mediante el comando whois en UNIX/Linux), o bien por medio de aplicacio-
nes web que los NIC y los RIR publican en Internet. De estas consultas se puede
obtener: información de personas de contacto junto con sus cargos, direccio-
nes de correo, direccionamientos IP, direcciones IP de servidores de dominio,
reglas de enrutamiento, etc.
Las fuentes habituales de consulta son:
• American Registry for Internet Numbers (ARIN).

• Asia Pacific Network Information Centre (APNIC).
• Réseaux IP Européens (RIPE).
• El NIC correspondiente al dominio que se encuentre auditando y, espe-
cialmente, los NIC nacionales.
Búsquedas en repositorios públicos de información de Internet
Las anteriores técnicas han sido las tradicionalmente más empleadas, y todavía
lo son. Sin embargo, con el auge del uso de la WWW, los foros de usuarios,
los grupos de noticias, las listas de correo, los buscadores, y demás fuentes de
información pública de Internet, cada día se encuentra más información sobre
las organizaciones en Internet, es decir, en sitios no controlados directamente
por ellas mismas. Mediante la consulta y búsqueda en estas fuentes, se puede
encontrar información que permita inferir aspectos de la arquitectura de la
organización, como nombres de productos, versiones, problemas, nombres de
usuarios, etc.
Estas nuevas fuentes de información están aumentando su importancia cada

día, y existen ya herramientas que permiten automatizar la búsqueda de in-
formación en ellas. Es de destacar la herramienta Maltego, que combina ambos
tipos de búsquedas: las estructuradas en bases de datos como WHOIS y DNS,
y las búsquedas en distintas fuentes de información en Internet, sobre todo
para la búsqueda de información relacionada con personas.
Uso de Maltego para recogida de inteligencia competitiva
La herramienta Maltego también resulta interesante para investigar y obtener

información relevante sobre personas que tengan relación con la entidad au-
ditada. Sin embargo, no todo el potencial de esta herramienta está disponible
en su versión "comunidad".
Dentro del ámbito de las herramientas con una representación gráfica de la

información, queremos destacar también la herramienta web robtex, que per-
mite realizar multitud de consultas a las bases de datos que hemos comentado
anteriormente (WHOIS, consultas a dns).
El empleo de la herramienta robtex
A continuación, mostramos la obtención de cierta información pública sobre el dominio

de la Universitat Oberta de Catalunya, tomando como punto de partida el nombre del
servicio de clases virtuales al que acceden los alumnos: cv.uoc.edu. Se ha empleado la
herramienta robtex, aunque se tiene que entender que lo mismo que esta herramienta
ofrece se podría realizar con herramientas más sencillas, como simplemente el comando
dig.
Consulta DNS del nombre cv.uoc.edu
La consulta nos ha devuelto su dirección IP, y el nombre del servidor de correo entrante. Si
se hace una consulta del nombre de dominio, nos proporcionará la información detallada
sobre los principales registros del dominio: MX y NS.
Consulta DNS del nombre de dominio uoc.edu
Si realizamos una consulta inversa de la dirección IP del servidor de cv.uoc.edu, obten-

dremos más información, como el alias de este servidor y otro dominio que se encuentra
servido por la misma máquina.
Consulta DNS inversa de la dirección IP del servidor de correo
Finalmente, podemos consultar el registro correspondiente a uno de los servidores DNS.
Consulta DNS del nombre del servidor DNS
Como se puede observar, la información obtenida sobre la infraestructura con unos pocos
clics es abundante. Sin embargo, no debemos sorprendernos, porque no hay que olvidar
que se trata de información pública.
Por último, merece la pena comentar que las organizaciones que realizan prue-
bas de inteligencia competitiva complementan estas pruebas con otras en las
que se analizan foros de distintos tipos, para monitorizar la exposición de la
organización a posibles ataques futuros. Este tipo de pruebas son más comple-
jas, y requieren una componente de inteligencia que debe ser aportada por
analistas. Estos analistas, además, se apoyan en herramientas relacionadas con
el datamining, que se basa en la recogida masiva de información para su pos-
terior análisis, correlación, visualización, etc.).
4.6.2. Escaneo de direcciones IP y puertos
Esta fase se realiza a continuación del reconocimiento inicial de la fase ante-

rior. También puede hacerse directamente si el auditado facilita toda la infor-
mación necesaria para iniciar estas tareas y no está interesado en los resultados
de la prueba anterior. Esta fase es especialmente crítica y necesaria cuando se
ejecutan análisis de vulnerabilidades de sistemas expuestos a Internet.
El escaneo de la red proporciona una imagen más clara de la visibilidad. No

sólo se obtienen todos los hosts visibles (lo cual completa a los identificados
en la fase anterior), sino que, además, se recopilan todos los servicios IP que
se ofrecen. Es importante aclarar que esta visibilidad depende del punto des-
de donde se realicen las pruebas, puesto que las redes IP suelen disponer de
medidas para el filtrado de tráfico (ya sea mediante listas de control de acceso
en los routers, por medio del uso de NAT –network address translation– o de fi-
rewalls). El auditor deberá planificar los distintos puntos desde donde realizar
sus pruebas en función de los objetivos de la auditoría.
Los objetivos específicos de esta fase serán tener lo más clara posible la topo-
logía de red auditada desde los distintos puntos de análisis. Las técnicas más
habituales utilizadas en esta fase son las siguientes:
1) Barrido ICMP.
2) Barrido de puertos.
3) Identificación de sistemas operativos y servicios.
Barrido ICMP
Mediante distintos tipos de mensajes ICMP, se pueden identificar hosts pre-

sentes en una red. El tipo más utilizado es el 8 - Echo Request, que es el usado
por el comando ping. Mediante el uso de barridos de otros tipos –13 Timestamp
Request, 15 Information Request o 17 Subset address mask Request– se pueden
identificar redes potencialmente mal protegidas o incluso desprotegidas. Es
incluso posible enviar este tipo de mensajes a las direcciones de broadcast de
las subredes, para identificar sistemas mal configurados. Habitualmente, los
dispositivos de firewall deberían impedir la entrada de mensajes ICMP desde

otras redes y, dentro de las mismas, los equipos no deberían responder a estos
mensajes (salvo el de tipo 8).
Algunas herramientas que se pueden emplear son: sing o nmap.
Barrido de puertos
Se trata de identificar todos los servicios TCP y UDP accesibles en los hosts
detectados. El barrido ICMP nos permitirá reducir el número de direcciones IP
contra las que realizar este tipo de barridos. Sin embargo, es posible que los
sistemas no respondan al ICMP Echo Request en configuraciones muy seguras.
Esto último no es muy habitual, puesto que dificulta el mantenimiento de los
sistemas, la monitorización y en general la resolución de incidencias técnicas.
Por otro lado, es extremadamente habitual que los routers y firewalls filtren este
tipo de tráfico en los bordes de las redes corporativas. Por lo tanto, si se realiza
un análisis desde el exterior, no se podrá confiar en el resultado del barrido
ICMP, y se debería realizar el barrido de puertos en todas las direcciones IP
que, potencialmente, se quieren analizar. Esto puede resultar muy costoso en
términos temporales.
Para describir las técnicas empleadas, debemos distinguir entre puertos TCP
y UDP, debido a su distinta naturaleza: el primero es orientado a conexión,
mientras que el segundo no.
1)�Escaneo�de�puertos�TCP. Existen varias técnicas de escaneo que hacen uso

de las diferentes respuestas que un puerto TCP debe dar a distintos tipos de
mensajes. Por limitaciones de espacio, mencionaremos sólo las técnicas más
habituales:
• TCP connect() scan. Se realiza una llamada a la máquina en cuestión para

iniciar una conexión TCP. Si la llamada finaliza con éxito, el puerto está
abierto; de lo contrario, no.
Escaneo de puertos TCP connect()
Si ha sido posible realizar la conexión, el sistema auditor cerrará la conexión,

o dejará que la conexión se cierre automáticamente por timeout. Este método
tiene el inconveniente de que requiere completar el proceso de conexión. Por
tanto, esta prueba puede quedar registrada en los registros de actividad del sis-
tema auditado. Este inconveniente puede no ser problemático en ciertos esce-
narios pero, en otros, el equipo auditor necesitará un mecanismo de escaneo
más discreto y al mismo tiempo más rápido.
• SYN scan. Para esta prueba, se requiere una aplicación que tenga acceso
directo al protocolo TCP. De esta manera, los paquetes TCP necesarios para
realizar el barrido son construidos por la propia aplicación. Este método
de barrido difiere de la conexión normal en que, cuando se recibe un pa-
quete TCP de tipo SYN/ACK, el sistema auditor responde con un RST, y
la conexión se cierra inmediatamente. Por tanto, en ningún momento se
llega a abrir la conexión, por lo que no es necesario el envío de ningún
otro paquete IP, ni quedará registrada la conexión.
Este tipo de escaneo es más discreto, aunque la gran mayoría de firewalls
son capaces de detectarlo. Por otra parte, la existencia de un firewall alte-
rará los resultados dependiendo del tipo de política de filtrado que tenga
implementado. Por lo tanto, esta técnica nos permitirá examinar el filtra-
do aplicado por los firewalls.
Escaneo de puertos SYN scan
Páginas web
Existen otros métodos para escanear redes que, por su complejidad técnica, consideramos
fuera del alcance de este módulo. Para más información, podemos consultar el sitio web:
http://www.insecure.org/nmap/man y http://www.nmap-tutorial.com.
Como conclusión, diremos que el uso acertado del escaneo de redes, junto con
otras técnicas de más bajo nivel, permiten comprobar la política de filtrado
implementada en los firewalls de la organización.
Es interesante apuntar que para realizar el escaneo más rápido de grandes ran-
gos de direcciones IP, existen otros métodos llamados asíncronos. En los mé-
todos comentados anteriormente, el sistema auditor mantiene un hilo de eje-
cución para la prueba de cada uno de los puertos. Por lo tanto, cada hilo sólo
puede probar una IP y un puerto. Debe enviar el paquete y esperar la respuesta
antes de poder pasar al siguiente IP-puerto a probar. Por esta razón se denomi-
nan síncronos. Sin embargo, en estos métodos asíncronos, se separa en hilos
de ejecución distintos el proceso que envía paquetes del que los recibe. De este
modo puede realizar envíos masivos de paquetes SYN desde un hilo y desde
el otro escuchar aquellos que responden con un SYN/ACK. Este método tiene
la ventaja enorme que permite acelerar enormemente el proceso, pero su des-
ventaja es que es más impreciso ya que puede producir muchos más paque-
tes perdidos (dropped) que no es capaz de detectar y que por lo tanto marcará
como puertos filtrados. De todos modos, estos mecanismos son ampliamente
utilizados especialmente como paso previo a realizar un escaneo más detalla-
do cuando nos enfrentamos a las tareas de escanear rangos de IP muy grandes
(por ejemplo, un 10.0.0.0/16 que podría ser el rango privado de una red corpo-
rativa). Se suele realizar primero un escaneo con este tipo de herramienta pero
limitado a un conjunto pequeño de puertos habituales (por ejemplo, 80, 135,
443, 445, 8080, 8081, 8443) y con los resultados obtenidos analizarlos para
preparar un escaneo tradicional síncrono con nmap sobre las direcciones IP o
rangos que se hayan detectado como activos en el escaneo inicial asíncrono.
Algunos ejemplos de herramientas que emplean esta técnica son: masscan,

zmap, scanrand, unicornscan.
2)�Escaneo�de�puertos�UDP. El escaneo de puertos UDP es más complicado,

debido a la naturaleza de este tipo de protocolo no orientado a la conexión. En
este caso, los puertos UDP no tienen por qué enviar contestación alguna, y los
puertos cerrados tampoco tienen que enviar un mensaje de error. Es por esta
razón que es poco fiable el escaneo de puertos UPD, aunque las aplicaciones
disponibles facilitan esta tarea. Las dos opciones disponibles serán:
• Enviar un datagrama UDP de prueba a un puerto y esperar a recibir el men-

saje ICMP "Destination port unreachable", lo cual demuestra que el puerto
está cerrado. En caso de no recibir mensaje, puede significar que efectiva-
mente el puerto está abierto, aunque también puede significar que existe
un firewall que impide la salida de mensajes ICMP (lo cual es habitual).
• Emplear software cliente que envíe datagramas UDP "legítimos" de la apli-

cación que se presuponga que está escuchando en el puerto (DNS, SNMP,
TFTP, etc.), y esperar la respuesta correspondiente del protocolo de la capa
de aplicación.
Escaneo de puertos UDP
Cualquiera de estas dos opciones proporciona unos resultados más pobres que los que
se pueden obtener del escaneo de puertos TCP, pero la segunda ofrece resultados más
precisos, aunque su ejecución es más tediosa por necesitar una herramienta específica
para cada puerto.
Respecto a las herramientas más idóneas para este tipo de tareas, se tiene que destacar
NMAP, por encima de casi cualquier otra herramienta incluso comercial. A fecha de rea-
lización de este material, NMAP se encuentra en la versión 7.92 e incluye, además del
tradicional interfaz de línea de comandos, un interfaz gráfico.
Herramienta nmap en su versión con interfaz gráfica
Escaneo con NMAP
En el siguiente ejemplo, empleamos NMAP para escanear puertos empleando el método

TCPconnect() scan:
Uso de nmap para escaneo TCP connect()

Dentro del uso de método síncrono, existen más formas de realizar un escaneo
de puertos (distintas opciones de escaneo de la herramienta nmap, como por
ejemplo el método llamado XMAS) pero su utilidad se ve reducida a situacio-
nes en las que, o bien deseamos ser más sigilosos, o bien deseamos identificar
las políticas implementadas por un firewall por medio de técnicas muy elabo-
radas.
Identificación de sistemas operativos y servicios
Una vez localizadas las máquinas y enumerados los puertos abiertos, quedará
identificar el sistema operativo y los servicios que se encuentran escuchando
en cada uno de los puertos abiertos. En la medida de lo posible, se intentará
identificar también la versión de estos servicios y aspectos de su configuración.
Es importante notar que, en el ejemplo anterior, se identifica al servicio que
hay escuchando en cada puerto en base al número de puerto. Sin embargo,
esta relación entre número de puerto y servicio es la determinada por la IANA,
y no tiene por qué ser la realmente implementada en la máquina en cuestión.
Es decir, se puede instalar un servidor web no sólo en el puerto 80, sino en
cualquier otro.
La detección del sistema operativo de la máquina remota se basa en el hecho

de que el estándar del protocolo IP no especifica cómo debe responderse a
paquetes IP mal formados. La técnica recibe el nombre de "TCP/IP stack finger-
printing". El modo en que un sistema operativo responde a paquetes mal for-
mados depende de cada implementación concreta, por lo que cada fabricante
o implementador de la pila de protocolos IP diseña las respuestas a su gusto.
Esto proporciona una vía para determinar qué sistema operativo se encuentra
en la máquina auditada.
Las herramientas que realizan esta tarea disponen de una base de datos de
respuestas típicas para cada sistema operativo. A partir de los paquetes de res-
puesta recibidos, se puede identificar un sistema operativo de la máquina re-
mota con una elevada probabilidad de acierto.
Respecto a la identificación del servicio que se encuentra detrás de cada puerto

TCP o UDP, ya hemos mencionado que la IANA (Internet Assigned Numbers
Authority), además de ser la responsable de la asignación de direcciones IP, se
encarga también de la asignación de puertos. Sin embargo, esto no implica que
sea necesario respetar estas asignaciones para el correcto funcionamiento de
una aplicación. Por lo tanto, cuando un puerto está abierto, no se puede inferir
directamente que el servicio que corre detrás se corresponde con el previsto por
la IANA. Es necesario recurrir a algún mecanismo para identificar el servicio.
Habitualmente, la técnica utilizada es realizar una conexión al puerto en cues-

tión y observar qué mensaje inicial se devuelve. En muchas ocasiones, este
mensaje contiene el nombre del servicio e incluso la versión. Por tanto, pue-
den aplicarse sistemas similares a los explicados anteriormente para identificar
el sistema operativo. Las herramientas disponen de una base de datos de res-

puestas típicas a ciertos paquetes IP de prueba. Esta técnica suele denominarse
banner grabbing. A pesar de la aparente eficacia de esta herramienta, su uso no
es de mucha utilidad cuando los servicios no muestran ninguna información.
Además, si presentan alguna, se tiene que desconfiar a priori. Por tanto, esta
técnica ha perdido casi totalmente su validez, aunque puede seguir conside-
rándose.
Respecto a las herramientas disponibles para realizar esta tarea, de nuevo desta-
ca sobre casi cualquier otra NMAP, aunque también se puede considerar AMAP.
Además de permitir realizar el escaneo de puertos, NMAP puede emplearse pa-
ra identificar el sistema operativo que utiliza una máquina, y los servicios que
se ejecutan detrás de cada puerto. La opción a emplear en NMAP para identi-
ficar el sistema operativo es –O, y para identificar los servicios –sV. La opción
–A realiza ambas cosas a la vez.
Identificar�sistema�operativo�y�servicio�-�NMAP�línea�de�comandos
C:\Windows\system32>nmap -A -T5 192.168.1.1

Starting Nmap 7.92 ( https://nmap.org ) at 2021-09-29 08:57 Romance Daylight Time
Stats: 0:00:00 elapsed; 0 hosts completed (0 up), 1 undergoing ARP Ping Scan
ARP Ping Scan Timing: About 100.00% done; ETC: 08:57 (0:00:00 remaining)
Stats: 0:00:15 elapsed; 0 hosts completed (1 up), 1 undergoing Service Scan
Service scan Timing: About 75.00% done; ETC: 08:57 (0:00:04 remaining)
Nmap scan report for 192.168.1.1
Host is up (0.016s latency)
Not shown: 994 closed tcp ports (reset)
PORT STATE SERVICE VERSION
21/tcp filtered ftp
22/tcp open ssh Dropbear sshd 2019.78 (protocol 2.0)
23/tcp filtered telnet
80/tcp open http micro_httpd
|_http-title: movistar
443/tcp open ssl/http micro_httpd
| sslv2:
| SSLv2 supported
|_ ciphers: none
|_http-title: movistar
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=CA Telefonica Moviles Espana SA/organizationName=Grupo
Telefonica/stateOrProvinceName=A78923125/countryName=PL
| Not valid before: 2015-09-22T06:17:02
|_Not valid after: 2025-09-19T06:17:02
8080/tcp open http Cisco Meraki firewall httpd
|_http-title: 404 Not Found
MAC Address: 34:57:60:61:E5:32 (MitraStar Technology)
Device type: general purpose
Running: Linux 2.6.X|3.X

OS CPE: cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:3
OS details: Linux 2.6.32 - 3.10
Network Distance: 1 hop
Service Info: OS: Linux; Device: firewall; CPE: cpe:/o:linux:linux_kernel
TRACEROUTE
HOP RTT ADDRESS
1 16.23 ms 192.168.1.1
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 51.17 seconds
C:\Windows\system32>
Herramienta AMAP
Uso�de�AMAP�para�identificar�servicios
C:\tools\thc-amap-windows-master>amap 127.0.0.1 135 445 1688

amap v5.4 (www.thc.org/thc-amap) started at 2016-09-19 22:22:00 - APPLICATION MAPPING mode
Protocol on 127.0.0.1:1688/tcp matches netbios-session

Protocol on 127.0.0.1:135/tcp matches netbios-session
Protocol on 127.0.0.1:445/tcp matches ms-ds
Unidentified ports: none.
amap v5.4 finished at 2016-09-19 22:22:18
C:\tools\thc-amap-windows-master>
Nota: Actualmente AMAP ya no es una herramienta ampliamente utilizada ya

que la precisión que ofrece NMAP es mucho mayor y, por otro lado, ya no ha
sido evolucionada.
4.6.3. Investigación de vulnerabilidades
Las fases que se han explicado hasta ahora son las previas a la investigación
de vulnerabilidades, que es la fase que principalmente interesará al auditor.
Cuando el auditor ya conoce de una máquina su sistema operativo, los servi-
cios que están publicados en la red (y su visibilidad desde distintos puntos de
la red), así como las versiones de ambos, puede pasar a esta siguiente fase. El
análisis de vulnerabilidades consistirá en comprobar si existe alguna vulnera-
bilidad conocida que afecte al sistema operativo o a los servicios en cuestión.
Además de esto, posteriormente se podría realizar una investigación de nue-
vas vulnerabilidades, pero esto requiere unos conocimientos técnicos mucho
más avanzados y, además, no se puede garantizar un resultado concreto. Cabe
notar que el hecho de no identificar ninguna vulnerabilidad en una máqui-
na no significa que ésta sea completamente segura. Sólo implica que, hasta
el momento, se desconoce si existen vulnerabilidades. Una vez ejecutada esta
fase, el auditor finalizará su trabajo.
Para realizar el proceso de investigación de vulnerabilidades, se utilizarán ba-

ses de datos que permiten saber qué vulnerabilidades existen para cada versión
de un servicio o sistema operativo. Una vez encontradas las vulnerabilidades
de los servicios y el sistema operativo en cuestión, se comprobará si realmente
estas vulnerabilidades están presentes. Este proceso puede ser muy largo y cos-
toso, por lo que habitualmente el auditor utilizará herramientas que automa-
tizan estas pruebas. Además, estas herramientas pueden automatizar no sólo
esta fase sino también las anteriores.
Entre las herramientas existentes, tanto comerciales como del movimiento de

software libre, se tiene que destacar muy especialmente Nessus, que se ha ex-
tendido como la herramienta más comúnmente empleada por los auditores
de seguridad. Pero existen otras muchas herramientas de búsqueda de vulne-
rabilidades. Entre ellas, podemos destacar las siguientes:
• Por su valor "histórico", podemos destacar COPS, TITAN y SATAN, desa-

rrolladas por Dan Farmer y Wietse Venema. Estas fueron las primeras he-
rramientas de análisis de vulnerabilidades internas en servidores Unix. Ac-
tualmente, SARA y SAINT son una evolución de SATAN, y permiten aná-
lisis remotos de vulnerabilidades. De ellas sólo sigue existiendo SAINT.
• Posteriormente, han aparecido multitud de otras aplicaciones, tanto Ope-

nSource como comerciales: ISS Internet Scanner, QualysGuard, eEye Re-
tina Network Security Scanner, GFI LANguard Network Security Scanner,
Vigilante SecureScan, N-Stealth, Shadow Security Scanner, Cerberus Inter-

net Scanner, entre otras.
• Finalmente, con el mismo concepto de análisis de vulnerabilidades que

realiza Nessus (y las expuestas en el punto anterior) se ha extendido a las
aplicaciones web, y se han creado herramientas para el análisis de vulnera-
bilidades de aplicaciones. Entre las herramientas comerciales de compro-
bación de vulnerabilidades, se encuentran: Nexpose, Qualys, WebInspect,
de SPI Dynamics; AppScan, de IBM; AppDetective, de Application Secu-
rity; ScanDo, de Kavado; N-Stealth Security Scanner, de N-Stalker; y Web
Vulnerability Scanner, de Acunetix.
Nos centraremos en Nessus debido a su larga trayectoria y soporte actual, su

popularidad en la comunidad, y la posibilidad de disponer de una versión
completamente funcional de manera gratuita. Uno de sus puntos fuertes es
su arquitectura. Existen diversas modalidades de la herramienta, pero la más
empleada por los auditores se instala en un sistema que actúa de sonda desde
donde se realizan los escaneos. El auditor accede a la herramienta vía una in-
terfaz web. En modalidades más avanzadas de la herramienta, el auditor puede
instalar distintas sondas en distintos segmentos de red y coordinar los esca-
neos de cada sonda desde un punto central. Otro de los aspectos que le confie-
ren gran versatilidad es que ha integrado distintas herramientas como NMAP,
HYDRA (para realizar pruebas de contraseñas en búsqueda de vulneraciones de
la política de contraseñas de la organización), NIKTO (para la comprobación
de scripts y CGI en servidores web), un motor para realizar comprobaciones
de configuraciones de sistemas (se tiene que facilitar a la sonda acceso remoto
al sistema que hay que comprobar), etc.
Existe una alternativa de uso distinta al uso desde un equipo del auditor y que
permite realizar despliegues en grandes infraestructuras, especialmente con la
versión Nessus Manager, que permite tanto integrar distintas sondas Nessus
como también el uso de agentes instalados en los sistemas y que reportan
al servidor central de Nessus Manager. Esta solución facilita enormemente la
gestión de credenciales con privilegios elevados y, además, es necesaria para
realizar escaneos en profundidad en los sistemas.
Finalmente es interesante señalar que actualmente, Tenable, el fabricante de

Nessus, ofrece la posibilidad de hacer que tanto sondas como agentes reporten
a una consola alojada en la nube de Tenable, liberando de la necesidad de
mantener un sistema en la propia infraestructura que actúe de punto central
de recogida de información. Éste puede ser muy conveniente en entornos en
los que sea posible el uso de este tipo de herramientas en la nube, y en los que
los sistemas puedan reportar directamente hacia Internet.
Distintas modalidades de despliegue de Nessus Manager
Fuente: Tenable
La forma de trabajar más habitual para un auditor es que emplee su propia

máquina para ejecutar el servidor. Conviene comprobar que el puerto que uti-
liza el servidor web de Nessus esté abierto, para poder conectar con un nave-
gador. Al tratarse de una arquitectura cliente/servidor, se tendrá que crear pre-
viamente un usuario en el servidor para que sea posible acceder a éste desde
el cliente.
Usuarios definidos en el servidor Nessus - Versión Windows
Existen distintos tipos de roles de usuarios y la posibilidad de compartir cier-

ta información entre ellos. El nivel de versatilidad depende de la versión de
Nessus. Por ejemplo, con la versión Nessus Manager existe la posibilidad de
integrar usuarios de un directorio LDAP para realizar la autenticación de ma-
nera centralizada.
El acceso a la herramienta se realiza con un simple navegador, empleando el

usuario definido previamente.
Configuración del cliente Nessus (versión Windows)
Nessus implementa las dos fases anteriormente expuestas, realizando incluso Métodos de escaneo de
la comprobación de las vulnerabilidades conocidas. Nessus
Nessus emplea los mismos mé-

todos que NMAP para realizar
el escaneo de IP y puertos, y
permite configurar el escaneo
según los distintos métodos
existentes, e incluso emplear
directamente NMAP.
Configuración del alcance

Configuración de los parámetros de escaneo (versión Windows)
La prueba de vulnerabilidades se realiza mediante el uso de plugins. Los plugins

son pequeños componentes integrables en el servidor Nessus que han estado
diseñados por el proveedor de la herramienta. Cada plugin permite comprobar
una vulnerabilidad concreta.
Nessus - selección de plugins
La base de datos de plugins se encuentra organizada por temáticas, para que el

auditor pueda seleccionar únicamente aquellos que sean pertinentes. Asimis-
mo, los plugins que pueden causar una interrupción del servicio se encuentran
marcados como peligrosos, y se pueden seleccionar o deseleccionar sencilla-
mente para evitar que la realización de las pruebas técnicas de la auditoría
causen una interrupción de un servicio. De todos modos, este aspecto tiene
que ser consensuado con el auditado y, en caso de duda, el auditor deberá

evitar cualquier tipo de prueba que afecte de manera negativa a los sistemas
del auditado.
Por tanto, el auditor seleccionará únicamente aquellos plugins que se

correspondan con el plan de auditoría previsto. Los resultados del aná-
lisis se mostrarán organizados en base a las direcciones IP de las máqui-
nas escaneadas, y es interesante destacar que cada vulnerabilidad estará
valorada empleando el sistema CVSS.
Ejemplo de un escaneo de vulnerabilidades con Nessus sobre un conjunto de servidores pertenecientes a un dominio Windows
La calidad del análisis obtenido mediante Nessus (y, en general, mediante cual-
quier otra herramienta, ya que todas emplean el mismo esquema de pruebas),
depende exclusivamente de la calidad de los plugins que realizan las pruebas,
y el grado de actualización de la base de datos de plugins. Por lo tanto, que
esta base de datos se encuentre actualizada es esencial para la calidad de los
resultados.
A medida que las vulnerabilidades son descubiertas, el fabricante de Nessus di-

seña los plugins necesarios para comprobarlas. Aparte de Nessus, existen otras
herramientas similares de fabricantes, como Nexpose y Qualys entre otras, y
también dentro del ámbito del movimiento de software libre existe la herra-
mienta OpenVAS (creada a partir de una versión de Nessus cuando esta toda-
vía tenía una licencia de uso más público). OpenVAS tiene la peculiaridad de
que los plugins son creados por la comunidad de usuarios de la herramienta.
En general, todas estas herramientas consiguen, de un modo u otro, mantener
las actualizaciones de los plugins de manera que se puedan detectar nuevas
vulnerabilidades en productos a medida que la comunidad de seguridad las va
descubriendo y publicando.
En ocasiones, para vulnerabilidades especialmente graves, algunas he-

rramientas (especialmente las de pago) realizan este proceso en un solo
día. De igual manera es importante que el auditor mantenga correcta-
mente al día su herramienta de análisis de vulnerabilidades; para ello,
según el tipo de herramienta, tendrá que suscribirse a los servicios de
actualización de este software y pagar por ellos si piensa usarlos con fi-
nes comerciales.
Es importante aclarar que el trabajo del auditor de sistemas informáticos está

cercano al del investigador de seguridad TIC, pero no es el mismo. El trabajo
de un investigador de seguridad TIC no se centra en detectar vulnerabilidades
ya conocidas, sino que pretende buscar nuevas aún no conocidas. En cambio,
el auditor se centra en comprobar cómo se han implementado los controles
técnicos de seguridad, y en identificar las vulnerabilidades conocidas que les
puedan afectar. La identificación de una vulnerabilidad conocida revela un
error en el mantenimiento de los sistemas. Por lo tanto, cuando el auditor re-
visa una infraestructura tecnológica, únicamente se preocupa de la existencia
de alguna de las vulnerabilidades conocidas.
Por otro lado, cabe destacar que es posible que la organización decida actua-
lizar los sistemas en fechas fijas y no cuando aparezcan las vulnerabilidades.
En este caso, el auditor deberá plantearse la idoneidad de esta política, y no
específicamente su implementación.
En este sentido, el auditor dispondrá de la información de las últimas vulne-

rabilidades conocidas, independientemente de su reconocimiento o no por
parte del fabricante del software o dispositivo afectado. En muchas ocasiones,
las vulnerabilidades son detectadas por equipos de analistas/investigadores de
seguridad independientes, los cuales comunican a la comunidad de usuarios la
existencia de un potencial riesgo en algún dispositivo o servicio. Más tarde, el
fabricante reconoce la vulnerabilidad y emite alguna solución, habitualmente
mediante un parche de software que se debe instalar. Por lo tanto, el auditor
debe conocer las vulnerabilidades más recientes y poder identificar aquellas
para las que se dispone de una solución y aquellas que no tienen todavía una
solución conocida. Esta diferenciación permite determinar la gravedad de un
hallazgo y discriminar entre errores de parcheado, debilidades de la política
de parcheado (por ejemplo, por imponer un calendario de actualizaciones es-
tricto y poco frecuente), o bien problemas conocidos en los sistemas para los
que no se dispone de solución.
Tal y como hemos dicho al principio de este apartado, existen muchas fuentes
de información públicas y de pago sobre vulnerabilidades. Las herramientas
de análisis de vulnerabilidades también emplean esta información y suelen
ofrecer un servicio de actualización de las mismas. De hecho, la agilidad con
la que el proveedor proporcione las actualizaciones es un punto crítico con el

que comparar la calidad de distintas herramientas, así como también lo es la
población potencial de sistemas que sean capaces de examinar.
Por último, tenemos que destacar que el uso de estas herramientas debe
ser empleado con cierto cuidado por parte de los auditores, porque a
veces generan resultados falsos, por muy evolucionadas que sean. Por
lo tanto, los resultados de estas herramientas han de ser siempre anali-
zados y, llegado el caso, deberán realizarse pruebas manuales de la vul-
nerabilidad revelada.
4.7. Revisión de seguridad en redes inalámbricas 802.11
La revisión de la seguridad en redes inalámbricas 802.11 es una tarea que,

esencialmente, es la misma que para sus análogos de las redes fijas. Las fases
de enumeración de sistemas y análisis de puertos y servicios, y la evaluación
de las vulnerabilidades de los servicios, son las mismas. Sin embargo, su na-
turaleza es especial al carecer de un medio de transmisión físico. En su lugar,
el medio utilizado es el espacio radioeléctrico, al que puede tener acceso cual-
quier intruso. Por lo tanto, su revisión debe incluir además la verificación de
los controles que gestionen riesgos específicos.
4.7.1. Riesgos de las redes inalámbricas 802.11
Toda implantación de redes inalámbricas se tiene que realizar teniendo pre-

sente que, además de los riesgos habituales que conllevan los sistemas TIC,
por su peculiaridad, aquéllas se encuentran expuestas a nuevos riesgos. Estos
riesgos se pueden recopilar en las siguientes categorías:
• Ataques de inserción de tráfico.

• Intercepción y/o monitorización del tráfico de la red inalámbrica.
• Denegaciones de servicio.
Ataques de inserción de tráfico
Usuarios no autorizados pueden intentar hacer uso de la red inalámbrica. Para

ello, antes tendrán que asociarse al punto de acceso, lo cual puede resultar
sencillo o no dependiendo de si se implementan medidas de cifrado en la red
inalámbrica, o algún otro mecanismo como puede ser la limitación por direc-
ciones MAC. Esta última medida (limitación por direcciones MAC), sin em-
bargo, no es efectiva, puesto que el atacante puede examinar todos los paque-
tes que circulen por la red inalámbrica, leer las direcciones MAC autorizadas
(aunque se emplee cifrado, las cabeceras de la capa de acceso al medio no van
cifradas) y cambiar su dirección MAC para hacer uso de la red cuando no esté
el usuario legítimo.
Otro riesgo, en este mismo sentido, es la instalación de puntos de acceso no

autorizados. Éstos pueden ser instalados por usuarios maliciosos para conse-
guir que los usuarios legítimos de la red inalámbrica se asocien a ellos. A partir
de ahí, los usuarios legítimos pueden ser atacados fácilmente. Los puntos de
accesos pueden ser instalados también por personal propio de la organización
para su propia comodidad, pero sin la autorización ni control del área de se-
guridad o de gestión TIC. Por tanto, estos puntos de acceso son susceptibles
de ser atacados.
Una vez asociado el atacante con la red inalámbrica, tiene a su disposición un

vector de ataque contra sistemas conectados a ella. Si el atacante ha consegui-
do asociarse a un punto de acceso corporativo, podrá atacar sus máquinas y
nos encontraremos ante una situación similar a la de un atacante con acceso
físico a la red fija. Los riesgos que se derivan son los mismos.
Un sistema especialmente susceptible de ser atacado por el intruso es el propio

punto de acceso. Como cualquier otro sistema informático, no está exento
de la posibilidad de tener vulnerabilidades, y éstas suelen explotarse desde su
interfaz de administración. Por esta razón, resulta una buena práctica limitar
el acceso a la interfaz de administración únicamente desde el lado de la red
fija, y prohibirlo desde el lado inalámbrico.
Si encontramos un punto de acceso que ha sido instalado sin autorización,

los riesgos que afectan a los usuarios legítimos son los mismos que en el caso
anterior.
Intercepción y/o monitorización del tráfico de la red inalámbri-

ca
La naturaleza inalámbrica de estas comunicaciones hace que sea posible la es-

cucha pasiva de éstas sin intervención en el canal. Por tanto, es necesario pro-
veer a la infraestructura de mecanismos para reducir este riesgo. Actualmente,
el estándar 802.11 facilita distintos medios: el protocolo WEP, que ha demos-
trado ser inseguro para todas las longitudes de clave sea cual sea la comple-
jidad de la contraseña, y el protocolo WPA (desde la definición del estándar
802.11i), que tiene distintas modalidades. La modalidad más básica es la PSK
("Pre-Shared Key"), y es también la más ampliamente implantada. Otras moda-
lidades más robustas, y también más recomendadas, son la autenticación con-
tra servidores RADIUS, o el uso de certificados digitales. También es posible
utilizar redes privadas virtuales (VPN) sobre la red inalámbrica, tanto en modo
transporte como túnel, pero esto no impide que el intruso siga pudiendo ac-
ceder a la red. La ventaja de las VPN es que el atacante no puede interceptar o
inspeccionar el tráfico de los usuarios legítimos, pero sí puede realizar ataques
contra la disponibilidad de la red, tal y como comentaremos a continuación.
Denegaciones de servicio
La denegación de servicio en una red inalámbrica es un riesgo al que está cons-

tantemente expuesta y que es de difícil mitigación. Cualquier equipo de radio
capaz de emitir en la banda de los 2.4 GHz puede interferir, intencionadamen-
te o no, en el funcionamiento de una red 802.11. Por ello, antes de instalar
una red de este tipo, deben identificarse las fuentes de radiación en esta banda,
así como también los requerimientos de disponibilidad que debe cumplir la
red. El control de la interferencia es difícil, aunque se puede intentar utilizar
antenas direccionales y triangulación para detectar la fuente origen de la in-
terferencia y neutralizarla.
De manera intencionada, un atacante dispone de diferentes técnicas para inu-

tilizar una red inalámbrica: inundación de la red con tramas de desautentica-
ción y de desasociación, envío de tramas de autenticación mal formadas (que
causen que el punto de acceso desautentique al usuario legítimo), saturación
de la memoria de los puntos de acceso con solicitudes de autenticación, etc.
Por último, para aplicaciones críticas es posible que no sea recomendable el

uso de esta tecnología, aunque los beneficios que conlleva pueden llevar a la
organización al punto de asumir los riesgos. En cualquier caso, es un riesgo
que la organización no debe desdeñar.
4.7.2. Política corporativa de seguridad para las redes

inalámbricas
Las organizaciones que implanten redes inalámbricas deberán gestionar, ade-

cuadamente, los riesgos anteriormente expuestos. Debe existir una política
corporativa de seguridad para las redes inalámbricas que se integre con el resto
de las políticas y sistemas de gestión de la seguridad de la información. Esta
política ha de definir la arquitectura, los usos legítimos y los mecanismos de
protección, incluyendo aspectos recomendables como:
• Tratar los puntos de acceso como redes de no confianza. Esto implica que
las redes inalámbricas deben tratarse como si fueran redes externas. Por lo
tanto, se deberían aplicar una o varias de las siguientes medidas de protec-
ción: separar las redes inalámbricas del resto de la infraestructura con un
firewall; configurar el acceso desde estas redes a la red corporativa a través
de VPN; disponer de sistemas de detección de intrusiones (IDS); implantar
mecanismos de identificación y autenticación para el acceso a cualquier
recurso de la red corporativa desde estas redes, entre otras.
Esto también implica que se tienen que proteger los equipos corporativos
que se conecten por medio de estas redes, como si estuvieran en redes no
confiables, caso de Internet. Esto conlleva las siguientes medidas:
– Uso de firewalls personales en los equipos.
– Accesos mediante VPN a los servicios corporativos, además del cifrado
requerido para acceder a la red inalámbrica.
– Uso de software para detección de amenazas (virus, malware, etc.), de

acuerdo con la política corporativa al efecto.
• Disponer de una política de configuración de los puntos de acceso. Los

administradores deberían disponer de una política que describa la confi-
guración básica que se debe dar a los puntos de acceso, la cual debe reflejar:
SSID a emplear, tipo de encriptación (descartar WEP y usar como mínimo
WPA con una contraseña compleja y actualizada periódicamente), valores
de las comunidades SNMP.
• Auditorías periódicas de la seguridad de las redes inalámbricas:

– Política de revisión periódica de la cobertura de las redes inalámbricas
para identificar puntos de acceso no autorizados y verificar las áreas
cubiertas.
– Auditoría periódica de los puntos de acceso: vulnerabilidades de los

servicios que ofrece, fortaleza de los mecanismos de cifrado, reglas de
filtrado de tráfico que apliquen, valores de las comunidades SNMP
configurados en los agentes instalados, etc.
– Análisis periódico de la seguridad de los equipos clientes, para detectar

errores de configuración o insuficiencias en las políticas de seguridad
definidas.
4.7.3. Pruebas de auditoría para la revisión de redes

inalámbricas
Como se puede observar, la implantación de redes inalámbricas tiene ciertas

diferencias respecto a las redes fijas. Por tanto, el auditor debería plantearse re-
visiones de seguridad del mismo modo, pero con ciertas peculiaridades. Ade-
más de las tareas de evaluación de la seguridad que encontramos en otro tipo
de entornos TIC, las pruebas de auditoría deberían contemplar:
• Revisión de la cobertura de la red inalámbrica. Uno de los factores que

deberán tenerse en cuenta será la evaluación del plano de cobertura, para
evitar su extensión más allá de las instalaciones en la medida de lo posi-
ble. Es importante que la cobertura se reduzca lo más posible a las zonas
donde se pretende ofrecer el servicio, mediante el ajuste de la potencia de
los puntos de acceso y el uso de antenas con diagramas de radiación no
omnidireccionales.
Las pruebas destinadas a comprobar el modo en que se gestiona el riesgo
deben:
– Establecer con el auditado cuál es el ámbito previsto para la red inalám-
brica. Es decir, conocer las instalaciones, los puntos de acceso planifi-
cados, y las áreas de cobertura previstas.
– Evaluar el alcance de la instalación inalámbrica. Para ello, el auditor

realizará visitas de auditoría con una herramienta que mida la poten-
cia de señal recibida en varios puntos de las instalaciones y también
fuera de ellas. Las herramientas más tradicionales para esta tarea eran
los analizadores NetStumbler o Kismet, que además podían combinarse
con herramientas de representación gráfica e incluso con dispositivos
GPS externos que registran, de manera automática, las coordenadas y
niveles de potencia de todos los puntos de acceso detectados. Actual-
mente existen múltiples herramientas (algunas comerciales o comer-
ciales con versión comunidad o de evaluación, como Acrylic Wifi o
Ekahau Site Survey o NetSpot) que, mediante interfaces gráficas y el uso
de posicionadores GPS, ayudan a generar un análisis de cobertura de
redes wifi. De esta manera, el auditor obtendrá un plano de las insta-
laciones y alrededores con la cobertura de radio de cada uno de los
puntos de acceso instalados.
• Identificación de fuentes de interferencias o de puntos de acceso no auto-

rizados. Las herramientas y técnicas serán muy similares a las descritas en
el punto anterior. Sin embargo, ahora el auditor no estudiará los puntos
de acceso corporativos, sino que intentará descubrir puntos de acceso no
autorizados y también identificar fuentes de interferencias en la misma
banda de frecuencia.
• Control de acceso al medio. Por último, el auditor deberá evaluar los me-
canismos de control de acceso al medio implantados en las redes inalám-
bricas. Esto implica que el auditor identificará la red y observará el tipo de
cifrado. A fecha de elaboración de este material, se puede considerar que el
cifrado ofrecido por WEP no es seguro para ninguna de las dos longitudes
de clave que ofrece (40 o 104 bits), independientemente de la complejidad
de la clave. El cifrado recomendado es, como mínimo, WPA con claves con
cierta complejidad. Sería aún mejor que, si se dispone de hardware mo-
derno o actualizable, se empleara WPA2. Ambos protocolos son similares,
pero WPA emplea como algoritmo simétrico de cifrado RC4, el cual se ha
demostrado que no es seguro en caso de emplear claves poco complejas (es
posible descubrir la clave WPA aplicando ataques con diccionario en muy
poco tiempo y con muy pocos paquetes capturados). En cambio, WPA2
usa AES, que hasta la fecha no ha sido comprometido.
Las herramientas para realizar este tipo de pruebas son muy variadas:
kismet, airodump, aireplay, aircrack, airdecap, entre otras, así como distri-
buciones de Linux para auditores especializadas en análisis de seguridad
como Kali (más generalista) o Wifislax (especializada en análisis de re-
des wifi). No obstante, cada día aparecen nuevas técnicas, por lo que se
recomienda que el auditor recurra a un experto o bien se mantenga al
día en la auditoría del cifrado de redes inalámbricas.
4.8. Técnicas de análisis de vulnerabilidades de aplicación
Las auditorías de aplicación tienen, por objeto, la verificación de aquellos con-

troles aplicados sobre las propias aplicaciones y de aquellos que éstas incorpo-
ran en su lógica. Estos controles pueden tener por objeto aspectos generales,
como aplicar un control de acceso a la información, con sus fases de identifi-
cación, autenticación y posterior autorización. También pueden tener un ob-
jetivo más específico, como impedir que se genere dos veces la misma factura
en una aplicación de facturación. Este último tipo de controles se suele deno-
minar control de aplicación o de lógica de negocio.
No existen técnicas diseñadas específicamente para la auditoría de controles

de aplicación. El auditor deberá conocer la lógica del negocio, el objetivo del
control y la implementación realizada. En base a esta información, el auditor
diseñará las pruebas que considere necesarias para obtener la certeza de que el
control se está aplicando correctamente.
Del mismo modo, los controles genéricos que se suelen encontrar en los catá-
logos de buenas prácticas son también extremadamente heterogéneos, y no es
posible indicar una única lista de pruebas a realizar. Sin embargo, sí se puede
recomendar el uso de las siguientes técnicas:
• Análisis estático, también referido habitualmente en inglés SAST - Static

Application Security Test.
• Análisis dinámico, denominado a veces DAST - Dynamic Application Secu-
rity Test.
• Análisis de la configuración / parametrización de los sistemas.
4.8.1. Análisis estático
El análisis estático consiste en la revisión sistemática del código fuente de una

aplicación, con el propósito de corregir errores en las primeras fases de su ciclo
de vida. De este modo, se mejora la calidad general del software y, al mismo
tiempo, se reduce el número de vulnerabilidades potenciales en un sistema.
Sin lugar a dudas, un análisis de código es la mejor prueba que se puede realizar
para prevenir las vulnerabilidades más comunes.
Ejemplos de vulnerabilidades más comunes
Falta de control en las cadenas de entrada, condiciones de carrera, gestión incorrecta de

la memoria, desbordamientos de buffers, etc.
Este análisis ahorra también muchos costes a las organizaciones desa-

rrolladoras de software. Sin embargo, este tipo de pruebas requerirán
de una gran experiencia por parte del auditor, y gran conocimiento del
lenguaje en que se encuentre desarrollada la aplicación.
Existe un gran número de herramientas para facilitar, y en cierto modo au-

tomatizar, las tareas de revisión de código. Sin embargo, esta tarea es básica-
mente manual, y las herramientas sólo servirán para facilitar la revisión del
código, realización e inventariado de chequeos automáticos y la realización
de búsquedas elaboradas, y todos estos resultados deben ser examinados por
el auditor para identificar los falsos positivos de los positivos reales. Es posible
que una herramienta identifique un punto en el código en el que existe un
error de programación potencialmente explotable. Por ejemplo, en un progra-
ma realizado en C, se podría estar copiando de un buffer de memoria a otro sin
controlar la longitud. Esto podría llevar a una vulnerabilidad de Buffer Over-
flow. Para confirmar si ese problema de seguridad es realmente una vulnerabi-
lidad explotable, se debería analizar el flujo de los datos que el usuario facilita
para determinar si él puede influir en el contenido de ese buffer que se está
copiando. Si no es así, existe efectivamente un problema de seguridad en el
código pero no es explotable. Este tipo de análisis es complejo y no todas las
herramientas disponen de esta capacidad de identificar si los datos son mani-
pulables por el usuario de la aplicación o no y si, por lo tanto, las vulnerabili-
dades son o no reales. Se necesita un analista de seguridad, o también quizá el
propio desarrollador, para acabar de determinar los positivos reales.
Actualmente existen muchas herramientas para análisis de código con distinto Nota
soporte a lenguajes de programación y con capacidades muy distintas. Entre
El proyecto OWASP mantiene
las herramientas existentes, podemos destacar: un listado muy completo de
herramientas de SAST. https://
owasp.org/www-commu-
• SEMGREP. Herramienta de código abierto con una gran actividad a fecha nity/Source_Code_Analysis_
Tools
de publicación de este material y que permite el análisis del código y ve-
rificación de aplicación de estándares de programación sin necesidad de
compilar ni subir el código a ningún entorno concreto. Se puede integrar
sin problema en pipelines de CI/CD y soporta los lenguajes más habituales
en desarrollos de aplicaciones web.
• Flawfinder. Examina código C y C identificando posibles problemas y cal-

culando, para cada uno de ellos, un nivel de riesgo.
• CxSAST de Checkmarx. Herramienta comercial que se puede integrar en

herramientas de versionado de código (por ejemplo Github o Gitlab) e
integrarse como un paso más en la cadena del pipeline de Delivery de
código o de puesta en producción.
• Fortify source code analysis. Herramienta comercial que se integra con los
entornos integrados de desarrollo (IDE) más habituales y permite realizar
una revisión de código en tiempo de codificación. Soporta un gran número
de lenguajes.
Herramienta Fortify analizando código PHP
• IBM Appscan. Es una herramienta de análisis estático de código para apli-

caciones web y móviles.
• Veracode. Este es otro de los líderes en cuanto a análisis de código que fa-
cilita gran número de herramientas, desde analizadores de código estático
(que nos ocupan) a soluciones completas integradas de gestión del ciclo
de desarrollo del software.
• LAPSE. Especialmente diseñada para servir de apoyo en el proceso de revi-

sión de código de aplicaciones Java J2EE. Permite localizar vulnerabilida-
des potenciales en aplicaciones web (manipulación de los parámetros de
entrada, manipulación de las cabeceras de los mensajes HTTP, manipula-
ción de cookies, inyecciones de código en los parámetros de entrada, etc.).
Esta herramienta se integra con el entorno de desarrollo Eclipse y permite
que la revisión de código se realice en paralelo a la codificación.
Herramienta LAPSE integrada en el IDE ECLIPSE
4.8.2. Análisis dinámico: análisis de aplicaciones web
A continuación, presentaremos el último grupo de técnicas a disposición del

auditor para la evaluación de la seguridad. Se trata del análisis dinámico del
software. En este tipo de pruebas, el auditor analizará el comportamiento del
software cuando éste se encuentra en ejecución. Este tipo de tarea es altamente
especializada, y requiere unos conocimientos técnicos elevados de programa-
ción, debuging y seguridad.
No trataremos en esta sección las técnicas existentes para el análisis de cual-

quier código en ejecución, sino que nos centraremos en el análisis dinámico
de aplicaciones web. Existen más tipos de análisis dinámico de aplicaciones,
que entran en el ámbito de la ingeniería inversa de código, que está fuera del
alcance de este curso.
El número de aplicaciones web que emplean las organizaciones ha crecido re-

cientemente de forma considerable. Esto es debido a la aparición de un nuevo
esquema de aplicación en tres capas: la capa cliente –el browser–, la capa de
presentación –el webserver–, y la capa que contiene las bases de datos y otros
sistemas que implementan la lógica de negocio –los backends–. Este tipo de
aplicaciones web ha crecido notablemente, y muchos sistemas que utilizaban
una arquitectura clásica cliente/servidor han migrado ahora a este nuevo es-
quema.
(7)
Además de las aplicaciones web en tres capas, también tenemos que destacar el Hemos excluido pruebas que,
por su complejidad técnica, se
proyecto OWASP, que ya hemos comentado en el módulo 4. Las aplicaciones
consideran fuera del alcance de es-
que utilizan este tipo de arquitectura son bastante similares unas de otras, y te material. Si son de interés pa-
ra el lector, le referimos a la meto-
por ello suelen tener el mismo tipo de vulnerabilidades. Por lo tanto, y en base dología OWASP y a sus proyectos
a la metodología descrita por OWASP, la auditoría de una aplicación web se OWASP Web Security Testing Gui-
de y OWASP Mobile Security Testing
compondría de las siguientes fases o pruebas7: Guide.
• Recogida de información.
• Revisión del proceso de identificación y autenticación.
• Revisión de la gestión de sesiones.
• Revisión de la validación de los datos de entrada.
Recogida de información
El objetivo de esta fase es comprobar qué información relativa a la aplicación

auditada puede ser obtenida, de forma legítima, por medio de los diferentes
canales existentes en Internet.
1)�Identificación�del�servidor�web. Identificar el tipo de servidor web que

aloja la capa de presentación de la aplicación. Si se determina correctamente
la versión exacta del servidor web, se podrán determinar las vulnerabilidades
publicadas a fecha de la auditoría, y determinar la política adecuada de par-
cheado/mantenimiento del servidor.
Para realizar esta comprobación, se conecta con el servidor HTTP en el puerto

80 (u otro si es el caso) utilizando herramientas como las que se muestran a
continuación, y así se determina qué software y qué versión de éste se está
utilizando:
• Netcat. Permite recoger el banner mostrado por el servidor.
Herramienta Netcat
• HTTPRINT: permite examinar la respuesta del servidor a varias peticiones

HTTP, y comparar estas respuestas con distintas muestras (denominadas
"firmas") mantenidas en el catálogo de la aplicación HTTPRINT.
Herramienta HTTPrint
Por otro lado, el auditor ha de tener en cuenta que, en la actualidad, los ser-
vidores web permiten configurar las respuestas que este tipo de pruebas ana-
lizan, con lo que los resultados solo deben ser tomados como indicativos y
no concluyentes.
2)�Identificación�de�las�aplicaciones. Cuando el objetivo de la auditoria con-

siste en la comprobación general de la seguridad de una infraestructura, se
deberán identificar todas las aplicaciones o portales servidos desde un deter-
minado servidor web. En el caso de que sólo se deba auditar una aplicación
concreta, esta prueba carecerá de sentido. Para identificar las diferentes apli-
caciones que se ejecutan detrás de un servidor web, pueden realizarse las si-
guientes acciones:
• Investigar si existen diferentes URL base que hospedan diferentes aplica- Buscadores tradicionales
ciones web.
www.live.com,
www.dnsstuff.com,
• Investigar si en la IP existen otras aplicaciones instaladas en otros puertos www.google.com, etc.
distintos a los estándares (443, 8080, 8000, etc.). Para ello, se puede em-
plear la herramienta NMAP.
• Para identificar hosts virtuales y encontrar los nombres de dominios asig-

nados a la IP auditada:
– Comprobar la posibilidad de realizar transferencias de zona en el ser-
vidor DNS del dominio examinado.
– Comprobar la posibilidad de realizar resolución inversa de nombres

(reverse DNS query).
– Conectar con servicios en Internet para examinar registros DNS, o usar
directamente buscadores tradicionales.
3)�Minería�de�datos. El objetivo de esta prueba es extraer toda la información

hospedada bajo la aplicación web analizada. Especialmente interesante será
aquella información que permanece oculta al usuario durante el uso esperado
de la aplicación. No debería existir información accesible de forma pública
con datos sensibles.
Mediante esta prueba, se examinan todos los enlaces accesibles en la aplica-

ción, lo que puede revelar información confidencial o al menos relevante acer-
ca de la aplicación web. El objeto de esta prueba será comprobar el "escape
o filtración de información" (information leaking) que se produce en una apli-
cación por el simple hecho de estar expuesta en Internet. Del mismo modo,
también se examinarán sitios web de carácter técnico (foros, mailing lists, etc.)
en búsqueda de información que el personal interno del cliente pudiera haber
publicado y que pudiera resultar relevante.
Para obtener un mapa completo de la aplicación, con todos los puntos de Nota
acceso y todo el contenido publicado en la misma, se hará uso de herramientas
La prueba se denomina "mine-
denominadas spider. He aquí algunos ejemplos: ría de datos", aunque no se re-
fiere a ningún aspecto conoci-
do habitualmente como data-
Herramientas spider mining. En nuestro contexto,
entendemos como "minería de
• Burp spider, que es parte de la aplicación Burp Suite. datos" la recogida de informa-
ción dentro de la propia apli-
cación.
Herramienta BURP Suite
• WebScarab, que utiliza el plugin spider para realizar la tarea que nos interesa.
Herramienta WebScarab
Además de las herramientas mencionadas, se utilizarán buscadores tradicionales. La ra-

zón de utilizar buscadores es que éstos usan "robots" que tienen la virtud de examinar
todos los enlaces accesibles de cada web. Por ello, son en realidad potentes herramientas
de minería de datos.
4)�Inspección�de�los�códigos�de�error�de�la�aplicación. En caso de generarse

un error en la aplicación web, la información que se muestre debe ser la menor
posible. Es decir, no han de ofrecerse detalles técnicos sobre la infraestructura
o sobre la naturaleza del fallo. Igualmente, la aplicación controlará el uso de
diferentes plantillas a la hora de generar los errores, de forma que el usuario
no pueda determinar la naturaleza del error.
Para inspeccionar los diferentes códigos de error, se generarán peticiones HTTP Nota
de diferentes tipos, las cuales darán lugar a errores en la aplicación. De esta
No se buscará generar errores
manera, se estudiará el modo en que la aplicación gestiona las condiciones que provoquen denegaciones
de error. de servicio. Estos aspectos se-
rán tratados en un conjunto de
pruebas específicas.
5)�Determinar�la�arquitectura�de�los�sistemas. Es importante determinar el

tipo de plataforma en la que se encuentra la aplicación con la mayor exactitud
posible. Se tratará de identificar cuáles de los siguientes elementos intervienen
en la prestación del servicio:
• Firewalls, que pueden identificarse mediante el uso de la herramienta

NMAP.
• Proxies o firewalls de nivel de aplicación, que pueden identificarse median-
te la herramienta netcat.
• Servidor de aplicaciones, que puede identificarse a partir de la observación
de los recursos que ofrece la aplicación auditada.
• Backend, que puede identificarse a partir de la navegación por la aplicación.
Los backends que se pueden encontrar son:
– Bases de datos de autenticación. Sin embargo, es difícil determinar la

existencia de una base de datos para la autenticación (LDAP, base de
datos relacional, RADIUS...) desde un punto de vista externo.
– Bases de datos para la gestión de la información.
6)�Interfaz�de�administración. Una interfaz de administración es un punto

candidato a sufrir intentos de ataques por parte de intrusos. Pueden existir in-
terfaces de administración tanto de la propia aplicación como de los diferen-
tes componentes que conforman la arquitectura tecnológica de la aplicación.
Se deberá identificar si existen interfaces de administración accesibles desde
el punto de prueba. En caso afirmativo, habrá de estudiarse qué información
ofrece esta interfaz y qué mecanismos de control de acceso implementa.
El primer paso de esta prueba consiste en listar todas las interfaces de admi-
nistración que podrían existir. Esto se realiza a partir del análisis de la propia
aplicación y su arquitectura. La lista de interfaces puede completarse mediante
la búsqueda de aplicaciones en los diferentes componentes que conforman la
arquitectura. Para ello, puede emplearse la herramienta NMAP.
El segundo paso es determinar si dichas interfaces de administración son ac-

cesibles desde localizaciones públicas (Internet). En caso de que las interfaces
de administración sean accesibles desde Internet, se estudiarán los métodos
de control de acceso implementados y sus posibles debilidades.
7)�Mantenimiento�de�la�aplicación. Las labores de mantenimiento y soporte

de la aplicación pueden dar lugar a filtraciones de información hacia el exte-
rior. En ocasiones, se incluyen comentarios o funciones de debugging en la par-
te cliente que podrían estar revelando información acerca del funcionamiento
interno de la aplicación. Asimismo, también puede suceder que, durante el pa-
so a producción, las versiones antiguas de algunos ficheros de código no sean
eliminadas, sino simplemente renombradas. En ocasiones, se puede llegar a
acceder al código fuente de estas versiones antiguas si no se han eliminado, y
pueden verse como ficheros de texto.
Se pueden llevar a cabo diferentes pruebas para intentar determinar la exis-

tencia de viejos archivos o backups que todavía esté sirviendo la aplicación.
• Inferencia a partir del esquema de nombres utilizado en el contenido pu-

blicado. El objetivo es encontrar archivos viejos que no son manejados
correctamente, de tal manera que la aplicación los muestre como ficheros
de texto, o incluso los ejecute. Esto último podría permitir la explotación
de vulnerabilidades que se han corregido en la versión definitiva.
• Examen de los comentarios en el código del cliente en busca de informa-

ción sensible. Para ello, puede utilizarse la herramienta WebScarab.
• Examen de contenidos no referenciados, obtenidos en la minería de datos.
• Búsqueda de contenidos en la cache de Google o Yahoo.
Revisión del proceso de identificación y autenticación
En esta fase, se revisará el proceso de identificación y autenticación de usua-

rios. En el entorno de una aplicación multiusuario, existe un proceso de iden-
tificación y autenticación que permite verificar la identidad digital de la per-
sona que inicia la comunicación. En base a esta identidad digital, se otorgan
a la persona unos derechos de acceso a la información. En el contexto de una
aplicación web, una vez realizado el proceso de identificación y autenticación,
se suele otorgar al usuario un elemento (token de identificación) que identifi-
ca unívocamente la sesión que se ha establecido. Este token de identificación
puede ser una cookie o un número de sesión pasado como un parámetro en
las peticiones HTTP. Debido a que el protocolo HTTP no está orientado a co-
nexión, es necesario que el token de identificación sea intercambiado en cada
transacción entre el cliente y el servidor de la aplicación web, para poder saber
en todo momento a que sesión de usuario se corresponde la petición HTTP.
Si este proceso no está implementado adecuadamente, un usuario puede ser
visto por la aplicación con un rol que no le pertenece y, por lo tanto, puede
que se le apliquen privilegios que no le corresponden. Un usuario podría in-
cluso llegar a acceder sin tener ningún de derecho de acceso si fuera capaz de
adivinar cómo son gestionados estos tokens. Para revisar el proceso de identi-
ficación y autenticación, se seguirán los siguientes pasos:
(8)
• Determinar� la� topología� de� los� tokens� de� identificación. Las tareas a Para más detalles sobre qué de-
termina si el esquema de identifi-
realizar serían:
cación y autenticación es correc-
– Encontrar los diferentes tokens de identificación de que dispone la apli- to, hay que consultar las guías de
OWASP.
cación para autorizar el acceso.
– Determinar la topología de dichos tokens de identificación: longitud,
contenido, cómo se hacen llegar hasta la aplicación, si son recupera-
bles, número máximo de intentos, etc.
– Concluir si el número de tokens utilizados y su topología son adecua-
dos8 en el contexto de la aplicación.
• Revisar�el�uso�de�contraseñas�por�defecto�o�de�diccionario. Se deben
evitar y eliminar, si existen, contraseñas por defecto en las aplicaciones
que se sirven. Igualmente, se han de evitar contraseñas predecibles, fácil-
mente adivinables, por ejemplo, a partir de un diccionario de palabras. En
interfaces de administración o aplicaciones públicas, se ha de revisar que

no se estén utilizando nombres de usuario y contraseñas de la instalación
por defecto de la aplicación.
En aplicaciones específicas de una compañía, desarrolladas a medida, se
debe evitar el uso de cuentas de usuario típicas (como "Admin", "Adminis-
trador", "System", etc.) y contraseñas fácilmente predecibles (contraseña
igual al nombre de usuario, palabras de un diccionario, etc.). Para reali-
zar esta prueba en entornos de aplicaciones web, puede utilizarse la herra-
mienta hydra (o similar).
• Comprobar�vulnerabilidad�a�ataques�de�fuerza�bruta. Se debe evitar el

uso de contraseñas que se puedan romper en un tiempo razonable me-
diante ataques de fuerza bruta, es decir, mediante la prueba sistemática
de todas las contraseñas posibles. La prueba de fuerza bruta se ejecutará
contra contraseñas vulnerables a este tipo de ataque. Para la prueba siste-
mática de todas las posibles combinaciones, puede utilizarse el software
hydra (o similar).
Por otra parte, los token de identificación (los que identifican una sesión en
una aplicación web) también son susceptibles de ser comprometidos por
fuerza bruta. Como resultado del análisis de la topología del token, existe la
posibilidad de determinar el grado de aleatoriedad del mismo (idealmente
tendrían que ser totalmente aleatorios o al menos pseudoaleatorios). En
caso de que se detecte algún patrón de construcción, puede determinarse
si es posible predecir total o parcialmente los tokens y, a continuación,
terminar el ataque mediante la aplicación de la fuerza bruta.
• Comprobar�efectividad�del�marco�de�autenticación. Una aplicación con

autenticación debe controlar, en todo momento, que no se pueda evitar
el marco de autenticación para acceder de forma directa a los recursos de
la misma. Para determinar si es posible evitar el marco de autenticación,
se diseñan una serie de test descritos a continuación:
– Acceso directo a recursos de la aplicación. Consiste en diseñar peticio-
nes directas a contenidos protegidos de la aplicación, sin pasar previa-
mente por la autenticación.
– Modificación de parámetros relacionados con la autenticación. Estu-

diar la existencia de variables relacionadas con la autenticación que
puedan ser modificadas por el usuario para acceder a recursos prote-
gidos.
– Análisis de ID de sesión. Si la aplicación web utiliza ID de sesión para

garantizar el acceso a los recursos una vez el usuario se ha autentica-
do, la predicción de dichos ID puede comprometer el sistema. Para el
análisis de ID de sesión, puede utilizarse la herramienta WebScarab.
– Inyección. Consiste en determinar si el backend utilizado para la au-

tenticación y el marco de autenticación que trabaja sobre él son sus-
ceptibles a problemas de validación de los datos de entrada (descritos
más adelante). Estos problemas podrían permitir a un atacante dispo-
ner de tokens correctos para acceder a contenidos restringidos.
Para realizar estos test, es necesario construir o modificar las peticiones que se
envían a la aplicación web analizada. Para ello, puede utilizarse el navegador
Mozilla Firefox y varios plugins que permiten observar y estudiar, detallada-
mente, la información que envía y recibe la aplicación.
Ejemplo de plugins
Web Developer, Live HTTP Headers, FireBug, Add 'n' Edit Cookies, Tamper Data, entre
otros.
Igualmente, puede ser necesario el uso de un proxy web que permita estudiar y
alterar el flujo de información intercambiada entre el navegador y la aplicación
web. Las herramientas que pueden utilizarse son BURP y WebScarab.
• Revisar�los�mecanismos�de�gestión�de�ficheros. En las aplicaciones web

actuales, es habitual el acceso a archivos del sistema de ficheros para servir
información u obtener código. En ocasiones, la selección del archivo acce-
dido puede estar determinada por parámetros de la petición. El manejo de
los archivos debe estar correctamente implementado, para evitar el acceso
a recursos o la ejecución de código sin autorización.
Para llevar a cabo la prueba, en primer lugar se debe determinar si existen
formas de utilizar los mecanismos de manejo de archivos para acceder a
recursos no autorizados. Se trata de identificar en qué medida los paráme-
tros de la comunicación HTTP entre el cliente y la aplicación determinan
los archivos que son accedidos.
El segundo paso es diseñar y realizar los test que permitan determinar si el
manejo de archivos está funcionando adecuadamente o si, por el contra-
rio, éste se ve afectado por problemas.
Problemas de directorio transversal
Los problemas de directorio transversal permiten el acceso a archivos del sistema me-
diante la manipulación de los parámetros de la petición que gobiernan el directorio que
se tiene que acceder. Éste y otros problemas están relacionados con errores de validación
de la entrada del usuario.
Para realizar estas pruebas, pueden utilizarse las mismas herramientas descritas
en el punto anterior.
• Revisar�el�mecanismo�de�recuperación�de�contraseña. Si la aplicación
permite al usuario recuperar una contraseña que ha olvidado, el mecanis-
mo utilizado no debe introducir ninguna vulnerabilidad en el marco de
autenticación. Para ello, se ha de estudiar si existen mecanismos para que
el usuario recupere la contraseña, el modo en que funcionan y si pueden

existir vulnerabilidades. Éstas dependerán de los mecanismos dispuestos,
y pueden estar relacionadas con errores en la validación de los parámetros
de entrada, o con ataques de ingeniería social (en el caso de que exista
un servicio de soporte al usuario). A partir de este estudio, se determina
el grado de robustez del proceso y las posibles vulnerabilidades que este
mecanismo introduce en el marco de la autenticación.
Por otro lado, la aplicación debe prevenir que el usuario almacene la con-
traseña en el navegador. Esto implica verificar que el código de cliente des-
activa la propiedad de "autocompletar" del navegador.
• Revisar�el�proceso�de�logout. La aplicación, en caso de tener un marco de

autenticación, debe haber implementado un proceso de logout para evitar
que se reutilicen sesiones. También se debe ejecutar el proceso de logout
automáticamente tras un cierto tiempo de inactividad del usuario, para
evitar, por ejemplo, el uso de la sesión en caso de ausencia del usuario
original.
Durante el proceso de revisión de esta funcionalidad, debe verificarse que
el proceso de logout elimina efectivamente la sesión del usuario, que se
eliminan las cookies en el cliente, si es necesario, y que la sesión no se puede
reutilizar. Finalmente, se estudiará también el grado de accesibilidad a la
función de logout.
Para realizar estas pruebas, será necesario el uso de un proxy web que per-
mita estudiar y alterar el flujo de información entre el navegador y la apli-
cación web. Las herramientas que pueden utilizarse son BURP y WebSca-
rab.
• Revisar�la�gestión�de�la�cache�del�navegador. La aplicación debe contro-

lar los contenidos que se guardan en la cache del navegador, para evitar
que se almacenen contenidos sensibles que puedan ser accedidos una vez
se ha abandonado una sesión. De esta manera, debe evitarse la fuga de
información sensible por medio de la cache del navegador del usuario.
Para revisar que la cache del navegador se gestiona correctamente, puede
utilizarse la herramienta WebScarab. Esta herramienta permite observar
todas las respuestas que ha producido la aplicación web, y comprobar que,
para todas las que contengan información sensible, se han dado instruc-
ciones al navegador para no cachear los datos, mediante las cabeceras HTTP
correspondientes.
Revisión de la gestión de sesiones
Debido a que el protocolo HTTP sobre el que se implementan las aplicaciones

web no almacena información de estado, es muy importante revisar la imple-
mentación que realiza la aplicación para mantener el estado de la conexión y
controlar la interacción con el usuario. En esta fase, se realizarán las pruebas
para revisar la gestión de las sesiones de usuario.
• Estudio�del�esquema�de�sesiones. En una aplicación web con un marco

de autenticación, es importante mantener sesiones para controlar la inter-
acción del usuario. Para gestionar una sesión, se utilizan tokens de sesión.
Estos tokens pueden ser principalmente de tres tipos: cookies, números de
sesión transportados en parámetros de una petición GET, o parámetros pa-
sados por una petición POST contenidos en campos ocultos de formula-
rios. En cualquier caso, los tokens de sesión deben cumplir ciertas propie-
dades –ser aleatorios, únicos, resistentes a análisis estadísticos o criptográ-
ficos– y evitar la fuga de información sensible.
El estudio del esquema de sesiones requerirá, en primer lugar, determinar
la estructura de los tokens de sesión y la posibilidad de que éstos puedan
dar lugar a una fuga de información. Para ello, se examinará una muestra
significativa de tokens en busca de patrones o información sensible (inclu-
so ofuscada), y se revisarán las condiciones bajo las que se reutilizan los
tokens. Esta misma prueba servirá para determinar si los tokens de sesión
se generan de una forma predecible y si son valores realmente aleatorios.
En los casos que se considere adecuado y factible, se intentarán realizar
ataques de fuerza bruta para intentar obtener ID de sesión válidos.
Para recoger tokens de sesión y examinar sus características, se puede utili-
zar la herramienta WebScarab, la cual también permite manipular los to-
kens de sesión que ofrece la aplicación y realizar estudios acerca de su alea-
toriedad. En el caso de intentar ataques de fuerza bruta para obtener tokens
de sesión válidos, se utilizará alguna herramienta de fuzzing con fuentes
de datos personalizadas.
Herramientas de fuzzing
Las herramientas que se utilizan para este propósito son los módulos de fuzzing de We-
bScarab o BURP, o bien el fuzzer jbrofuzz.
Herramienta JBroFuzz
• Estudio�de�la�exposición�de�los�tokens�de�sesión. La aplicación debe pre-

venir que los tokens de sesión sean visibles durante su envío desde el clien-
te hasta el servidor. De lo contrario, las sesiones de los usuarios pueden
verse comprometidas. Para asegurar que los tokens no son visibles, se debe
comprobar que éstos se envían siempre cifrados con cada petición HTTP,
y que además se utiliza un canal seguro para el envío (HTTPS).
A continuación, se debe validar que la aplicación implemente el control
adecuado, mediante directivas, para evitar que proxys cache intermedios
almacenen tokens de sesión. También se ha de controlar que el envío de
los tokens de sesión no se realice mediante peticiones GET, y verificar que
el servidor no los acepta en una petición GET. Para la realización de es-
tas pruebas, se utilizará una herramienta de tipo proxy como WebScarab
o BURP.
• Prevención� de� ataques� de� session� riding� o� cross� site� request� forgery
(CSRF). Un ataque de CSRF es aquel en el que se fuerza a un usuario de
una aplicación web a realizar una petición HTTP que él no ha solicitado
expresamente (siguiendo un enlace o pulsando un botón de un formula-
rio). Esta petición puede tener un impacto relevante, como podría ser por
ejemplo un cambio de contraseña, una orden de pedido, etc. Normalmen-
te, se requiere que la víctima ya tenga establecida la sesión en la aplicación
web vulnerable.
La aplicación web debe prevenir que se realicen acciones importantes y
relevantes sin la intervención del usuario o confiando únicamente en in-
formación predecible (aunque sea dentro del marco de una sesión auten-
ticada). Sin este tipo de precaución, la petición que causa la acción podría
preconstruirse y esconderse, de tal manera que el usuario la ejecutase sin
su conocimiento y sin percatarse del efecto que se ha causado. La proble-
mática de esta vulnerabilidad es que puede ser explotada sin atacar real-
mente a la aplicación, puesto que en realidad se está aprovechando un
error en el diseño.
Modos de ocultar y forzar la petición
El modo de ocultar y forzar la petición es variado. Por ejemplo, se puede insertar en cual-
quier página que vaya a visitar la víctima (no tiene que ser en la aplicación atacada) una
imagen que en realidad contiene una petición construida para lanzar el ataque. También
se podría aprovechar una vulnerabilidad de cross-site scripting en un sitio web que la víc-
tima visite y, mediante código javascript insertado en el navegador de la víctima, lanzar
la petición. Cuando la víctima visita el sitio web que contiene el contenido malicioso,
automáticamente y sin su conocimiento, se lanza una petición contra la aplicación web
con todos los parámetros necesarios para realizar el ataque.
Para evitar este tipo de ataques, la aplicación debe implementar medidas co-
mo añadir información específica de la sesión en las peticiones que ejecutan
alguna acción.
Medidas de seguridad
Utilizar campos ocultos en formularios que sean aleatorios y distintos para cada petición
(aunque la acción ejecutada en la aplicación sea exactamente la misma). Además, la apli-
cación deberá comprobar que los parámetros recibidos son los que se esperaba para la
sesión, y que se han recibido en el momento exacto.
Otra medida puede ser pedir confirmación al usuario antes de realizar cualquier acción
relevante. El objetivo final de estas medidas será evitar la ejecución de acciones en el
contexto de un usuario sin su conocimiento ni consentimiento.
El auditor puede estudiar la vulnerabilidad de la aplicación web a este tipo

de ataques utilizando una aplicación de tipo proxy como WebScarab o BURP.
Estas aplicaciones permiten observar qué tipo de peticiones se utilizan para
consultar información de la aplicación web o ejecutar acciones relevantes. Del
mismo modo, permiten estudiar qué información es necesaria enviar en la pe-
tición, si se confía únicamente en información que tiene el navegador (como
una cookie) y si se pide confirmación de las acciones. Por último, estas aplica-
ciones permiten también manipular las peticiones.
Revisión de la validación de los datos de entrada
Probablemente, los mayores problemas de seguridad en una aplicación web se

derivan de errores en la validación de la entrada. Así pues, no se debe confiar
en los datos externos que se reciben, ya que son siempre susceptibles de ser
alterados por un atacante. Las pruebas que se realicen en este ámbito determi-
nan el correcto tratamiento de la entrada del usuario, especialmente cuando
ésta puede conducir a vulnerabilidades en la aplicación.
(9)
• Problemas�de�inyección. Cuando la entrada de un usuario va a ser final- Consultar OWASP Web Security
Testing Guide.
mente utilizada por un backend o intérprete, es necesario validarla correc-
tamente para evitar la ejecución de instrucciones o comandos. Para ello, se
seleccionarán primero los vectores de entrada de datos que sean suscepti-
bles de ser interpretados. Los vectores de entrada susceptibles son aquellos
que serán interpretados por un backend (un servidor LDAP, un gestor de
bases de datos relacionales o un intérprete de comandos) o incluso por el
propio navegador web del usuario (inyección de contenido en la capa de
presentación).
Una vez identificados los intérpretes susceptibles de tratar determinados

datos de entrada, se realizarán baterías de pruebas para encontrar inyec-
ciones de diferente tipo9.
Inyecciones
Algunos ejemplos de inyecciones:
• Cross Site Scripting

• Inyección SQL
• Inyección LDAP
• Inyección ORM
• Inyección XML
• Inyección SSI
• Inyección XPath
• Inyección IMAP/SMTP
• Inyección de código
• Inyección de comandos
Para la realización de estas pruebas, será necesario observar y modificar el flu-

jo de información entre el cliente y la aplicación. Para ello, se utilizará una
aplicación de tipo proxy como WebScarab o BURP. También es posible utilizar
una herramienta de fuzzing con fuentes de datos personalizadas.
Ejemplos de las herramientas que se utilizan para este propósito son los módulos de
fuzzing de WebScarab o BURP, o bien el fuzzer jbrofuzz.
• Corrupción�de�memoria. Las entradas del usuario deben tratarse de forma

adecuada, para evitar que las aplicaciones que van a tratar luego los datos
puedan verse afectadas por problemas de corrupción de memoria, como
desbordamientos de buffer o bugs de formato.
Los desbordamientos de memoria son causados por problemas de falta de
verificación de los datos de entrada. Las variables que contienen estos da-
tos se pasan a los procesos por medio de buffers de memoria (en la pila o
el heap). Si no se controla la longitud que tienen estos datos, puede pro-
vocarse un mal funcionamiento en el proceso que los recibe.
Para comprobar la posibilidad de realizar este tipo de ataques en la aplica-
ción web, se utilizará una batería de pruebas contra los diferentes vecto-
res de entrada priorizados. Cada una de estas pruebas se centrará en un
parámetro de entrada, y se harán pruebas del funcionamiento del proceso
dando distintos valores al parámetro con longitudes distintas. En el mo-
mento en que se detecta un funcionamiento anómalo del proceso, se ten-
drá identificado un punto potencial de desbordamiento de buffer.
Para la ejecución de las baterías de pruebas, puede utilizarse también al-
guna herramienta de fuzzing con fuentes de datos personalizadas; poste-
riormente, se deberán emplear herramientas de debugging para identificar
el origen del mal funcionamiento. Esto permitirá determinar si el error se
debe o no a un desbordamiento de buffer.
Este tipo de pruebas son las más complicadas de realizar, y podríamos con-
siderar que el trabajo del auditor se convierte en una investigación de se-
guridad de un producto de software concreto.
Todas las fases y técnicas anteriormente descritas son automatizables hasta

cierto punto, y por ello en el mercado hay herramientas disponibles para los
auditores especializadas en la búsqueda de vulnerabilidades en aplicaciones
web (Acunetix, Netsparker, Nessus, Nexpose, Qualys, etc.) que automatizan
prácticamente todas las fases. Facilitando credenciales al escáner, la herramien-
ta realiza por sí sola el recorrido de la aplicación (web spidering o web crawling)
y, sobre cada una de las páginas y parámetros detectados, es capaz de pasar
toda una batería de pruebas. Sin embargo, estas herramientas pueden generar
falsos positivos, no alcanzar completamente todas las partes de la aplicación
o no ser capaces de detectar problemas ligados a la lógica de negocio que rea-
liza la aplicación. Por ello esas herramientas constituyen un elemento muy
importante del arsenal de técnicas disponibles para el auditor, pero en ningún
caso un sustituto completo de la labor profesional, diligente e inteligente de
un auditor experimentado.
4.8.3. Diferencias entre SAST y DAST
Los dos tipos de enfoques de cara a realizar la revisión de una aplicación son
radicalmente distintos, pero totalmente complementarios. Para una completa
revisión de una aplicación, se debería realizar ambos tipos de auditoría, ya que
ciertas vulnerabilidades serán difíciles de detectar por el DAST cuando en el
SAST podrán ser detectados tras un análisis del código y, a la inversa, ciertos
errores detectados en el SAST podrían resultar más sencillos de verificar me-
diante un DAST, puesto que un potencial error de programación podría no ser
realmente explotable por un atacante. Como se ha comentado anteriormente
en el apartado dedicado a SAST, ese tipo de pruebas se realizan con el apoyo de
herramientas que detectan problemas de seguridad potenciales en el código
fuente. Pero, según las capacidades de la herramienta o incluso por la comple-
jidad intrínseca del flujo de datos en la aplicación, puede ser difícil determinar
si un atacante puede llegar o no a aprovechar ese fallo. Es ahí donde las prue-
bas de DAST pueden complementar al SAST y mediante una prueba dinámica
bien dirigida se puede comprobar si realmente el fallo es o no explotable por
un atacante. Es por esto que en una organización madura se deberían contem-
plar ambos tipos de pruebas.
Veamos a continuación en más detalle en que difieren ambos estilos de revi-

sión de aplicaciones.
Recursos necesarios
El SAST es un ejercicio puramente con enfoque “White Box”, ya que tiene ac-
ceso completo a todo el código fuente de la aplicación a auditar y posiblemen-
te a sus librerías y dependencias también. Sin embargo, el DAST permite un
enfoque más mixto. Puede ir del completamente “Black Box” que simularía
las condiciones más realistas de un atacante a otros enfoques mixtos (distintos
grados de “Grey Box”) en el que, para acelerar el proceso de análisis, se le fa-
cilitará al auditor la información que pueda resultar necesaria como versiones
de software o librerías, usuarios con ciertos niveles de permisos, parámetros
de configuración, información sobre la infraestructura subyacente, etc.
Al ser el SAST un enfoque puramente estático de análisis del código, no tiene

en cuenta posibles vulnerabilidades que dependen de la configuración del en-
torno de ejecución. Estos problemas podrían ser detectados en un DAST donde
el auditor trata con la aplicación y con la infraestructura que la sustenta y, por
lo tanto, podrá identificar problemas propios de la infraestructura que podrían
comprometer la información manejada por la aplicación o vulnerabilidades
que sólo se expresan cuando la aplicación interactúa con la infraestructura.
Con el fin de detectar este tipo de aspectos derivados de la configuración que
no haría el SAST, existen, como se ha comentado en el apartado anterior, revi-
siones de configuración de los entornos. Estas revisiones pueden ser manuales
o bien mediante herramientas que permiten automatizar muchas de las verifi-
caciones, más aún ahora que los entornos de despliegue disponen de API para
su configuración programática. Es interesante apuntar que actualmente existe
una tendencia a gestionar la infraestructura como código, y que la descripción
de la infraestructura a desplegar, así como su configuración, se mantienen en
ficheros de configuración (esta tendencia es conocida como “IaC - Infrastruc-
ture as Code) que pueden ser analizados también como código. Es por esto que
el SAST se está orientando también a la revisión del código, ya no de una apli-
cación, sino de una infraestructura.
Relación con el ciclo de desarrollo
Para realizar un DAST, es necesario que la aplicación esté en una fase de desa-
rrollo más avanzado que en un SAST, ya que es necesario que esté en un estado
que permita su ejecución en algún tipo de entorno como mínimo de pruebas
o integración (tampoco es necesario que estas pruebas se realicen en produc-
ción). Por el contrario, en un SAST, el análisis se puede realizar incluso antes
de realizar el paso a un entorno. De hecho, actualmente es habitual en orga-
nizaciones que aplican metodologías de desarrollo ágil, integran el SAST en el
pipeline de CI/CD y que deba pasar las pruebas automáticas con un cierto nivel
de éxito para permitir que el proceso automático de entrega de código avan-
ce. De esta manera, cuando un desarrollador entregue nuevo código en un
repositorio controlado de código (por ejemplo de tipo GIT), el entorno podría
analizar mediante SAST el nuevo código y podría denegar la incorporación al
repositorio. Esto hace que algunas herramientas SAST estén incluso ya inclui-
das en los entornos de programación de los desarrolladores. Esta característica

hace que los problemas de seguridad que se detectan con un SAST suelen ser
más sencillos, rápidos y baratos de resolver que los detectados en un DAST.
4.8.4. Análisis de la configuración / parametrización de los

sistemas
Los siguientes elementos pueden requerir una auditoría de la configuración:
• Firewalls.
• Routers y otros elementos de comunicaciones, como balanceadores de car-
ga o switches gestionables.
• Sistemas operativos.
• Sistemas gestores de bases de datos.
• Aplicaciones.
Es también una tarea que requiere gran experiencia del auditor, puesto que se
tratará de comprobar la situación de todos los parámetros de configuración de
un sistema. Además, para poder determinar si un sistema está bien configura-
do, se tendrán en cuenta las políticas de seguridad de la organización. En caso
de no existir estas políticas, el auditor deberá dar su opinión de auditoría en
base a los catálogos de buenas prácticas.
(10)
Tal y como hemos apuntado, el auditor necesitará un buen conocimiento del Para más información acerca de
la Comunidad de Equipos de Res-
sistema a auditar. Puesto que esto es complejo, hay listas de comprobación,
puesta ante Incidentes de Seguri-
o checklists, para realizar la revisión de la configuración de un sistema. Las dad Informática, hay que visitar las
páginas web: http://www.first.org
checklists suelen contener instrucciones sobre cómo realizar la configuración o http://www.cert.org.
mínima necesaria para que un sistema pueda integrarse, de forma segura, en
un entorno operacional. Algunos fabricantes ya proporcionan estas checklists
y, en otras ocasiones, son terceras organizaciones quienes las facilitan. Estas
organizaciones suelen estar encuadradas en organismos públicos dedicados
a la seguridad de la información o la gestión de incidentes telemáticos (los
llamados CERT10). En este sentido, son destacables las siguientes iniciativas:
• El NIST (National Institute of Standards and Technology) ha realizado una

recopilación exhaustiva de checklists recogiendo recomendaciones de fa-
bricantes y criterios comunes para distintas organizaciones gubernamen-
tales americanas, y también ha emitido un documento (SP 800-70 Security
Configuration Checklists Program for IT products) que da las indicaciones ne-
cesarias para desarrollar una checklist y/o emplear las checklists recopiladas
por el NIST u otras fuentes. El auditor empleará este documento para cons-
truir su propia lista de comprobación en base a su experiencia y otras listas
que puedan existir. No hay que olvidar que estas checklists son genéricas,
y que se deberán adaptar a las circunstancias específicas del auditado.
• Los CERT nacionales, como por ejemplo el CCN-CERT en España, publican

guías para la segurización de software (con acceso restringido a usuarios
registrados). El auditor podría construir su propia checklist a partir de las

recomendaciones dadas en estas guías.
• El CIS (Center for Internet Security) ha desarrollado los CIS benchmarks.

Al igual que las guías del CCN-CERT, estos benchmarks contienen las re-
comendaciones para la configuración segura de diferentes paquetes de
software y sistemas operativos. Es importante destacar que estos bench-
mark contienen el consenso establecido entre la NSA (National Security
Agency), la DISA (Defense Information Systems Agency), el NIST, la GSA
(General Services Administration), el SANS Institute, y los miembros del
CIS sobre la seguridad de distintos sistemas operativos y paquetes de soft-
ware en relación con su configuración. Los CIS benchmarks son similares
a las checklists, pero tienen la ventaja de que proporcionan mecanismos
para realizar una valoración numérica de la seguridad del sistema. Por lo
tanto, constituyen una fuente de información muy valiosa para el auditor.
Cabe destacar, también, que los miembros adheridos al CIS tienen a su
disposición herramientas con las que ejecutar en local los test descritos en
los benchmarks, y obtener así la puntuación directamente.
En este punto, es interesante comentar que realizar la verificación del cumpli-

miento de una checklist (lista de comprobación) puede ser una labor larga, pero
fácilmente automatizable mediante scripts (guiones) o uso de herramientas de
escaneo. Algunas herramientas de escaneo de vulnerabilidades incluyen, como
funcionalidad adicional, la realización de comprobaciones de parámetros de
seguridad. En la terminología del mercado, éstas se denominan habitualmen-
te compliance checks. Herramientas como Nessus, Qualys o Nexpose pueden
realizar este tipo de tareas, e incluso el fabricante facilita los ficheros de con-
figuración basados en fuentes reconocidas como el NIST o el CIS, menciona-
dos anteriormente. En general, estas herramientas se conectan remotamente
al sistema que se ha de analizar con credenciales de administrador o emplean
un agente (si se implementa de este modo) instalado con privilegios elevados,
y se realiza un conjunto de verificaciones que el auditor prepara mediante al-
gún tipo de fichero de configuración. Esta lista de verificación puede estar rea-
lizada en algún tipo de sintaxis propia del fabricante (es el caso, por ejemplo,
de Nessus) o bien se pueden aceptar listas de configuración en los lenguajes de
marcas estándares OVAL (Open Vulnerability and Assessment Language) y XXDF
(Extensible Configuration Checklist Description Format), conocido como OVAL.
Estos dos estándares forman parte del conjunto de estándares SCAP (Security
Content Automation Protocol). El término protocolo no debe ser entendido como
un término técnico de comunicación de datos, sino como un conjunto de es-
pecificaciones para definir una manera de actuar. En este caso, este protocolo
facilita la automatización de procesos relacionados con la seguridad (ésta sí,
desde el punto de vista técnico). El NIST ha elaborado una guía introductoria
para SCAP en el documento SP800-117 (Guide to Adopting and Using the Security
Content Automation). El protocolo SCAP contiene distintos componentes:
• Extensible Configuration Checklist Description Format (XCCDF),

• ®
Open Vulnerability and Assessment Language (OVAL ),
• Open Checklist Interactive Language (OCILTM),
• Common Platform Enumeration (CPETM),
• Common Configuration Enumeration (CCE
TM
),
• ®
Common Vulnerabilities and Exposures (CVE ),
• Common Vulnerability Scoring System (CVSS) y
• Common Configuration Scoring System (CCSS).
El objeto de esta estandarización es establecer el uso de un lenguaje común

en el sector privado de la seguridad informática y facilitar el intercambio de
información y la interoperabilidad de herramientas. Un ejemplo de interope-
rabilidad es el que acabamos de comentar respecto a la elaboración de listas
de comprobación por parte de una organización ajena a un fabricante de pro-
ductos de seguridad, como puede ser un escáner de vulnerabilidades.

Auditoría Técnica

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Auditoría Técnica

Cargado por

Copyright:

Formatos disponibles

Auditoría Técnica

M1.810 UOC 2022

Introducción a la Auditoría TIC y

M1.810 - Auditoría técnica aula 2

Módulo 1 - Introducción a la auditoria

Introducción a la auditoría TIC y de seguridad TIC

Rafael Estevan de Quesada

Tiempo mínimo de dedicación recomendado: 5 horas

Rafael Estevan de Quesada

Ingeniero superior de Telecomuni-

La revisión de este recurso de aprendizaje UOC ha sido coordinada

Cuarta edición: febrero 2022

2. Componentes de una auditoría...................................................... 12

5. Estandarización de la labor de auditoría.................................... 33

6. Gobierno de las TIC........................................................................... 43

7.5. Independencia de auditoría ........................................................ 53

Todas estas medidas de seguridad y los mecanismos para gestionarlas confor-

Sin embargo, cabe recordar que la seguridad es un proceso vivo, que no es

Por esta razón se producen constantes cambios tanto en la configuración de los

Estas revisiones de la seguridad de una organización se denominan auditorías

Cuando las auditorías de seguridad se basan en la revisión del conjunto de me-

comprobar que la gestión de la seguridad se realiza de manera acorde a unos

"Section 404: Management Assessment of Internal Controls

1) state the responsibility of management for establishing and maintaining an adequate

Toda esta situación que hemos comentado ha llevado al auge de la disciplina

Actualmente, la gestión moderna de los negocios, y en especial en organiza-

• Marcos regulatorios generales para todos los negocios, pero específicos en

• Marcos regulatorios del sector en que se desarrolla la actividad de negocio,

• Términos y condiciones concretados en las relaciones contractuales entre

• Buenas prácticas de la industria.

De manera muy informal, cuando se habla de auditoría se piensa en una he-

Una auditoría, desde un punto de vista muy general, es un proceso eje-

Por tanto, podemos concluir que el proceso de auditoría pretende poder

Se entiende por evidencia de auditoría el conjunto de registros, declaraciones

Es importante entender que según el ámbito de conocimiento o de organiza-

• Auditorías financieras, con muchas distinciones (auditorías de cuenta, va-

• Auditorías a procesos productivos o de calidad, no sólo relacionadas con

• Auditorías al proceso de gestión de recursos humanos.

• Auditorías de cumplimiento legal.

Auditorías del marco legal de protección de datos de carácter personal. Anteriormente

• Auditorías a la gestión medioambiental.

• Auditorías a los sistemas de información y en general a la forma en que

Conviene destacar que nos ocuparemos de las auditorías a sistemas de gestión

1.1. Principios de auditoría

Los principios de auditoría afectan tanto al comportamiento y características

• Integridad�/�Conducta�ética. Fundamento del profesionalismo. En una

• Presentación�justa�e�imparcial. La obligación de informar verazmente y

• Debido� cuidado� profesional. La aplicación de diligencia y juicio en la

Por otra parte, otros principios de auditoría se aplican al propio proceso de

• Independencia. Es la base de la imparcialidad y objetividad de las con- Ley 22/2015, de 20 de

• Enfoque�basado�en�la�evidencia. La base racional para llegar a conclu-

• Confidencialidad. Finalmente, las partes implicadas en la auditoría

Si un auditor se ciñe a los principios descritos, el resultado de su trabajo será

2. Componentes de una auditoría

2.1. Tipos genéricos de auditorías

En el proceso de auditoría aparecen tres actores principales que están íntima-

Relaciones entre los actores de una auditoría

• El auditor, o mejor dicho, el equipo auditor: es el grupo de personas (o una

• El auditado: es la organización (o podría también ser la persona, aunque

• El cliente de la auditoría: es la persona u organización interesada en cono-

De la existencia o no de los tres actores de una auditoría, la relación que ten-

• Auditorías internas o de primera parte.

• Auditorías de tercera parte.

2.1.1. Auditorías internas o de primera parte