Auditoria de Sistema - Tema4

AUDITORIA DE SISTEMAS COMPUTARIZADOS
TEMA 4
AUDITORIA DE LA SEGURIDAD
4.1. INTRODUCCIÓN
Para muchos la seguridad sigue siendo el área principal a auditar, hasta el punto de
que en algunas entidades se creó inicialmente la función de auditoría informática para
revisar la seguridad, aunque después se hayan ido ampliando los objetivos.
Es sabido que puede haber seguridad sin auditoría, puede existir auditoría de otras
áreas, y queda un espacio de encuentro: la auditoría de la seguridad (figura 4.1), cuya
área puede ser mayor o menor según la entidad y el momento.
Figura 4.I. Encuentro entre seguridad y auditoría
Lo cierto es que cada día es mayor la importancia de la información, especialmente

relacionada con sistemas
basados en el uso de tecnologías de la información y por lo que el impacto de los
fallos, los accesos no autorizados, la de la información, y otras incidencias, tienen un
impacto mucho mayor que hace unos años: de ahí la necesidad de protecciones
adecuadas que se evaluarán o recomendarán en la auditoría de seguridad.
Entonces, debemos ir hablando más de Auditoría en Sistemas de Información que

sólo de Auditoría Informática, y no se trata de un juego de palabras sino de una
actualización acorde con el nuevo enfoque y las áreas que llega a cubrir, y lejos ya de la
denominación en inglés que seguimos viendo en muchos libros, auditoría en proceso
electrónico de datos (Electronic Data Processing).
La nueva denominación abarca globalmente los sistemas de información: desde la

planificación, el alineamiento con las estrategias de las entidades, hasta los sistemas de
información y el aprovechamiento de las tecnologías de la información aportan, ventajas
competitivas a la entidad, la gestión de los recursos, e incluso la medida de la
rentabilidad de todo ello, que es quizá el único punto que se sugiere a la hora de
establecer objetivos de la auditoría.
Algunas entidades tienen detallados sus costes en la contabilidad analítica, ¿cómo

cuantificar en algunas semanas las ventajas y los beneficios - algunos tangibles y
difícilmente cuantificables- si la propia entidad no ha podido hacerlo en toda su
existencia?
Volviendo a la seguridad, en la figura 4.2 se observa que los objetivos de la auditoría

de la seguridad son abarcativos y preserva la seguridad y confidencialidad de la
información (constituye el control del control), aunque solemos oír con respecto a la
misma varias expresiones como seguridad informática, seguridad de los sistemas y
tecnologías de la información, seguridad - o protección- de la información, sin llegar
a descartar ninguna, nos quedaremos con la última, ya que los datos y la información
son los activos estratégicos y valiosos relacionados con los sistemas y el uso de las
tecnologías de información.
. Hugo Ruchinsky 1 Lic. Miguel Badaracco

Objetivos de la seguridad y de la Auditoría de la Seguridad
Personas instalaciones
Y funciones
Producción
Equipos Datos y
Periferia y software
comunicaciones
Fig. 4.2
La expresión seguridad informática, que es la más usada, puede llegar a relacio-

narse sólo con los equipos y los entornos técnicos, como si la información en otros
soportes y ambientes no requiriera protección, cuando son las propias operaciones de
la entidad, el negocio en entidades con ánimo de lucro, lo que requiere protección.
Si no existen suficientes y adecuadas medidas de protección se puede perder in-

formación vital, o al menos no estar disponible en el momento requerido (pensemos en
diagnósticos de pacientes muy graves o en control de vuelos), las decisiones tomadas
pueden ser erróneas, o se pueden incumplir contratos o la propia legislación, lo que
puede traducirse en grandes multas en el caso de infracciones graves, o lo que es aún
peor: la inmovilización de los ficheros.
Debe evaluarse en la auditoría si los modelos de seguridad están en consonancia

con las nuevas arquitecturas, las distintas plataformas y las posibilidades de las comu-
nicaciones, porque no se puede auditar con conceptos, técnicas o recomendaciones de
hace algunos años (que en realidad no son tantos).
En cuanto a la justificación de la auditoría, basta sólo decir que tanto la normativa

como la auditoría son necesarias: una auditoría no basada en políticas de la entidad
auditada (además de las normas para realizar la auditoría) sería subjetiva y hasta
peligrosa (aunque en sistemas de información es una situación habitual, que no
normal); y la existencia de normativa sin auditoría podría equivaler a la no-existencia
por ej. de la policía de transito, lo que incrementaría los accidentes e iría convirtiendo la
circulación en caótica y peligrosa.
La realidad es que no se conocen datos completos y fiables sobre el nivel de

protección de las entidades en nuestro país y menos aún en nuestra zona, respecto a
sistemas de información y vendrían bien algunas estadísticas.

Volviendo al control, los grandes grupos de controles son los siguientes, además de
poderlos dividir en manuales y automáticos, o en generales y de aplicación:
. Controles directivos, que son los que establecen las bases, como las políticas, o la
creación de
comités
relacionados o de funciones: de administración de seguridad o auditoría de
sistemas de
información interna.
· Controles preventivos: antes del hecho, como la identificación de visitas (seguridad
física) o las contraseñas (seguridad lógica).
· Controles de detección, como determinadas revisiones de accesos producidos o la
detección de incendios.
· Controles correctivos, para rectificar errores, negligencias o acciones
intencionadas, como la recuperación de un archivo dañado a partir de una copia.
· Controles de recuperación, que facilitan la vuelta a la normalidad después de
accidentes o contingencias, como puede ser un plan de continuidad adecuado.
Podemos hablar de Objetivos de Control respecto a la seguridad, que vienen a ser

declaraciones sobre el resultado final deseado o propósito a ser alcanzado mediante las
protecciones y los procedimientos de control, objetivos como los recogidos en la
publicación COBIT (Control Objectives for Information and Related Technologies) de
ISACA (lnformation Systems Audit and Control Association / Foundation).
Cada entidad ha de definir sus propios objetivos de control, en cuanto a seguridad y

otras áreas, y crear y mantener un Sistema de Control Interno (funciones, procesos,
actividades, dispositivos...) que puedan garantizar que se cumplen los objetivos de
control.
Los auditores somos, en cierto modo, los "ojos y oídos" de la Dirección, que a
menudo no puede, o no debe, o no sabe, cómo realizar las verificaciones o
evaluaciones. (En cuanto a los ojos sigue existiendo en algunos sectores la figura
clásica del veedor.)
En los informes se recomendará la implantación o refuerzo de controles, y en

ocasiones incluso que se considere la supresión de algún control, si resulta redundante
o ya no es necesario.
El sistema de control interno ha de basarse en las políticas, y se implanta con

apoyo de herramientas, si bien encontramos a menudo en las auditorías que lo que
existe es más bien la implantación parcial de controles de acceso lógico a través de
paquetes o sistemas basada en el criterio de los técnicos, pero no sustentada en
normativas o bien habiendo partido ésta de los propios técnicos, sin aprobaciones de
otro nivel.
La realidad es que el control interno no está generalizado en Argentina (y menos

aún en la zona) fuera de los procesos que implican gastos, y especialmente pagos, pero
existen otros riesgos tan importantes o más que las pérdidas monetarias directas,
relacionados con la gestión adecuada de los recursos informáticos o con la propia
protección de la información, que podrían suponer responsabilidades y pérdidas muy
importantes para la entidad.
Cuando existe un sistema de control interno adecuado los procesos de auditoría,

especialmente si son periódicos, son revisiones necesarias pero más rápidas, con in-
formes más breves; si el sistema de control interno es débil, la auditoría llevará más
tiempo y esfuerzo, su coste será mayor, y las garantías de que se pongan en marcha
las recomendaciones son mucho menores; en ocasiones la situación dista tanto de la
ideal como la del paciente que se somete a un chequeo después de varios años sin
control.
4.2. AREAS QUE PUEDE CUBRIR LA AUDITORIA DE LA SEGURIDAD
Se incluyen las que con carácter general pueden formar parte de los objetivos de

una revisión de la seguridad, si bien ésta puede abarcar sólo parte de ellas si así se ha
determinado de antemano.
En una auditoría de otros aspectos pueden también surgir revisiones solapadas con
la seguridad; así, a la hora de revisar los desarrollos, normalmente se verá si se
realizan en un entorno seguro y protegido, y lo mismo a la hora de revisar la
explotación, o el área de técnica de sistemas, las redes, la informática de usuario final,
las bases de datos... y en general cualquier área, salvo que expresamente se quiera
pasar por alto la seguridad y concentrarse en otros aspectos como pueden ser la
gestión, costes, nivel de servicio, cumplimiento de procedimientos generales, calidad, o
cualquier otro.
Volviendo a las áreas, las que se citan pueden ser objeto de la auditoría de segu-
ridad, si bien en cada caso se habrán fijado los objetivos que más interesen, no consi-
derando o por lo menos no con el mismo énfasis otros, si bien debiendo quedar claro y
por escrito cuáles son esos objetivos, tanto cuando se trate de una auditoría interna
como externa, en cuyo caso puede mediar un contrato o al menos una propuesta y
carta de aceptación.
Las áreas generales citadas, algunas de las cuales se amplían después, son:
Lo que hemos denominado controles directivos, es decir los fundamentos de la

seguridad: políticas, planes, funciones, existencia y funcionamiento de algún
comité relacionado, objetivos de control, presupuesto, así como que existen
sistemas y métodos de evaluación periódica de riesgos.
· El desarrollo de las políticas: procedimientos, posibles estándares, normas y

guías, sin ser suficiente que existan estas últimas.
. Que para los grupos anteriores se ha considerado el marco jurídico aplicable. Así
como las
regulaciones o los requerimientos aplicables a cada entidad, otro aspecto es el
cumplimiento de
los contratos.
· Amenazas físicas externas: inundaciones, incendios, explosiones, corte de líneas

o de suministros, terremotos, terrorismo, huelgas...
. Control de accesos adecuado, tanto físicos como los denominados lógicos, para
que cada
usuario pueda acceder a los recursos a que esté autorizado y realizar sólo las
funciones
permitidas: lectura, variación, ejecución, borrado, copia... y quedando las pistas
necesarias para
control y auditoría, tanto de accesos producidos al menos a los recursos más
críticos como los
intentos en determinados casos.
. Protección de datos: lo que se fije en las leyes y su Reglamento (que está con-
cebido pero hasta
ahora no ha salido a la luz) en cuanto a los datos de carácter personal bajo
tratamiento
automatizado, y otros controles en cuanto a los datos en general, según la
clasificación que
exista, la designación de propietarios y los riesgos a que estén sometidos.
. Comunicaciones y redes: topología y tipo de comunicaciones, posible uso de

cifrado,
protecciones ante virus, éstas también en sistemas aislados aunque el impacto
será menor que
en una red.

. El entorno de Producción, entendiendo como tal Explotación más Técnica de

Sistemas, y con
especial énfasis en el cumplimiento de contratos en lo que se refiere a
protecciones, tanto
respecto a terceros cuando se trata de una entidad que presta servicios, como el
servicio
recibido de otros, y de forma especial en el caso de la subcontratación total o
outsourcing.
· El desarrollo de aplicaciones en un entorno seguro, y que se incorporen controles

en los
productos desarrollados y que éstos resulten auditables.
· La continuidad de las operaciones.

No se trata de áreas no relacionadas, sino que casi todas tienen puntos de enlace
y partes comunes: comunicaciones con control de accesos, cifrado con comunicaciones
y soportes, datos con soportes y con comunicaciones, explotación con varias de ellas, y
así en otros casos.
4.3. EVALUACIÓN DE RIESGOS
Se trata de identificar los riesgos, cuantificar su probabilidad e impacto, y analizar

medidas que los eliminen - lo que generalmente no es posible- o que disminuyan la
probabilidad de que ocurran los hechos o mitiguen el impacto.
Para evaluar riesgos hay que considerar, entre otros factores, el tipo de información
almacenada, procesada y transmitida, la criticidad de las aplicaciones, la tecnología
usada, el marco legal aplicable, el sector de la entidad, la entidad misma y el momento.
Para ello los auditores disponemos de listas, que normalmente incluimos en hojas
de cálculo, o bien usamos paquetes, y tal vez en el futuro sistemas expertos. El pro-
blema sigue siendo la adaptación de los puntos a cada caso, y asignar el peso que pue-
de tener cada uno de los puntos.
Desde la perspectiva de la auditoría de la seguridad es necesario revisar si se han

considerado las amenazas, o bien evaluarlas si es el objetivo, y de todo tipo: errores y
negligencias en general, desastres naturales, fallos de instalaciones, o bien fraudes o
delitos, y que pueden traducirse en daños a: personas, datos, programas, redes,
instalaciones, u otros activos, y llegar a suponer un peor servicio a usuarios internos y
externos, normalmente clientes, imagen degradada u otros difícilmente cuantificables, e
incluso pérdida irreversible de datos, y hasta el fin de la actividad de la entidad en los
casos más graves.
Para ello es necesario evaluar las vulnerabilidades que existen, ya que la cadena de
protección se podrá romper con mayor probabilidad por los eslabones más débiles, que
serán los que preferentemente intentarán usar quienes quieran acceder de forma no
autorizada.
Debemos pensar que las medidas deben considerarse como inversiones en segu-
ridad, aunque en algunos casos se nos ha dicho que no es fácil reflejarlas como activos
contables ni saber cuál es su rentabilidad; podemos estar de acuerdo, pero ¿cuál es la
rentabilidad de blindar la puerta de acceso a nuestro domicilio o la de instalar un
antirrobo en nuestro automóvil? Esa rentabilidad la podemos determinar si los dispo-
sitivos o controles han servido para evitar la agresión, y a veces habrá constituido
simplemente una medida disuasoria, sobre todo en seguridad lógica, y no llegaremos a
conocer su efecto positivo.
En todo caso debemos transmitir a los auditados que, además, la seguridad tiene un
impacto favorable en la imagen de las entidades (aunque esto sólo no suela justificar
las inversiones), y tanto para clientes y posibles como para los empleados. Unos y otros
pueden sentirse más protegidos, así como sus activos.

La protección no ha de basarse sólo en dispositivos y medios físicos, sino en

formación e información adecuada al personal, empezando por la mentalización a los
directivos para que, en cascada, afecte a todos los niveles de la pirámide organizativa.
El factor humano es el principal a considerar, salvo en algunas situaciones de

protección física muy automatizadas, ya que es muy crítico: si las personas no quieren
colaborar de poco sirven los medios y dispositivos aunque sean caros y sofisticados.
Además, es conveniente que haya cláusulas adecuadas en los contratos, sean de

trabajo o de otro tipo, especialmente para quienes están en funciones más críticas.
Es necesaria una separación de funciones: es peligroso que una misma persona

realice una transacción, la autorice, y revise después los resultados (un diario de ope-
raciones, por ejemplo), porque podría planificar un fraude o encubrir cualquier anomalía,
y sobre todo equivocarse y no detectarse; por ello deben intervenir funciones/personas
diferentes y existir controles suficientes.
En un proceso de auditoría, por tanto, se evaluarán todos estos aspectos y otros,

por ejemplo si la seguridad es realmente una preocupación corporativa no es suficiente
que exista presupuesto para ello; si las personas a diferentes niveles están
mentalizadas, pues es necesaria una cultura de la seguridad; y si hay un comité que fije
o apruebe los objetivos correspondientes y en qué medida se alcanzan, qué modelo de
seguridad se quiere implantar o se ha implantado, qué políticas y procedimientos
existen: su idoneidad y grado de cumplimiento, así como la forma en que se realiza el
desarrollo de aplicaciones, si el proceso se lleva a cabo igualmente en un entorno se-
guro, con separación de programas y separación en cuanto a datos, si los seguros cu-
bren los riesgos residuales, y si está prevista la continuidad de las operaciones en el
caso de incidencias.
Una vez identificados y medidos los riesgos, lo mejor sería poder eliminarlos, pero
ya hemos indicado que normalmente lo más que conseguimos es disminuir la
probabilidad de que algo se produzca o bien su impacto: con sistemas de detección, de
extinción, mediante revisiones periódicas, copiando ficheros críticos, exigiendo una
contraseña u otros controles según los casos.
Algunos manuales hablan de transferir los riesgos, por ejemplo contratando un

seguro, pero debemos recordar que si se pierden los datos la entidad aseguradora abo-
nará el importe estipulado - si no puede acogerse a alguna cláusula en letra pequeña-
pero la entidad seguirá sin recuperar los datos.
Otra posibilidad es asumir los riesgos, pero debe hacerse a un nivel adecuado en la
entidad, .y considerando que puede ser mucho mayor el coste de la inseguridad que el
de la seguridad, lo que a veces sólo se sabe cuando ha ocurrido algo. ¿Cuál es el
riesgo máximo admisible que puede permitirse una entidad? Alguna vez se nos ha
hecho la pregunta, y depende de lo crítica que sea para la entidad la información así
como disponer de ella, e incluso puede depender del momento: es un tema tan crítico
que no puede generalizarse.
Algunos de los riesgos se han podido asumir de forma temporal, por estar en pro-
ceso de cambio las plataformas, las aplicaciones o las instalaciones, o por no existir
presupuesto ante las grandes inversiones necesarias; en todos los casos debe constar
por escrito que se asumen y quién lo hace, y ha de ser alguien con potestad para
hacerlo, ya que a menudo son técnicos intermedios quienes asumen la responsabilidad
sin poder hacerlo, o bien los directivos señalan a los técnicos cuando ocurre algo sin
querer asumir ninguna responsabilidad.
Si la entidad auditada está en medio de un proceso de implantación de la seguridad,

la evaluación se centrará en los objetivos, los planes, qué proyectos hay en curso y los
medios usados o previstos.
La evaluación de riesgos puede ser global: todos los sistemas de información,

centros y plataformas, que puede equivaler a un chequeo médico general de un indivi-

duo, y que es habitual la primera vez que se realiza, o bien cuando se ha producido el
nombramiento de algún responsable relacionado, o cuando una entidad compra otra,
pero puede producirse también una evaluación parcial de riesgos, tanto por áreas como
por centros, departamentos, redes o aplicaciones, así como previa a un proyecto, como
puede ser una aplicación a iniciar.
A menudo en la auditoría externa se trata de saber si la entidad, a través de fun-

ciones como administración de la seguridad, auditoría interna, u otras si las anteriores
no existieran, ha evaluado de forma adecuada los riesgos, si los informes han llegado a
los destinatarios correspondientes y si se están tomando las medidas pertinentes, así
como si el proceso se realiza con la frecuencia necesaria y no ha constituido un hecho
aislado.
En estos casos se debe considerar la metodología que se sigue para evaluar los
riesgos más que las herramientas, aunque sin dejar de analizar éstas, y si se han con-
siderado todos los riesgos -al menos los más importantes- y si se han medido bien, ya
que sobre todo cuando la evaluación se hace de forma interna por técnicos del área de
sistemas de información suelen minimizar los riesgos porque llevan años conviviendo
con ellos o simplemente los desconocen.
La seguridad no es un tema meramente técnico, aunque sean muy técnicas algunas

de las medidas que haya que implantar.
Es necesaria la designación de propietarios de los activos, sobre todo los datos (por
delegación de los titulares), y que son quienes pueden realizar la clasificación y
autorizar las reglas de acceso; un buen propietario se interesará por los riesgos que
puedan existir, por lo que promoverá o exigirá la realización de auditorías y querrá
conocer, en términos no técnicos, la sustancia de los informes.
Al hablar de seguridad siempre se habla de sus tres dimensiones clásicas:

confidencialidad, integridad y disponibilidad de la información, y algunos controles van
más dirigidos a tratar de garantizar alguna de estas características.
La confidencialidad: se cumple cuando sólo las personas autorizadas (en un

sentido amplio podríamos referimos también a sistemas) pueden conocer los datos o la
información correspondiente.
Podemos preguntamos ¿qué ocurriría si un soporte magnético con los datos de los
clientes o empleados de una entidad fuera cedido a terceros?,/,cuál podría ser su uso
final?,/,habría una cadena de cesiones o ventas incontroladas de esos datos?
La integridad: consiste en que sólo los usuarios autorizados puedan variar (mo-
dificar o borrar) los datos. Deben quedar pistas para control posterior y para auditoría.
Pensemos que alguien introdujera variaciones de forma que perdiéramos la in-

formación de determinadas deudas a cobrar (o que sin perderla tuviéramos que recurrir
a la información en papel), o que modificara de forma aleatoria parte de los domicilios
de algunos clientes.
Algunas de estas acciones se podrían tardar en detectar, y tal vez las diferentes
copias de seguridad hechas a lo largo del tiempo estarían "viciadas" (corruptas decimos
a veces), lo que hada difícil la reconstrucción.
La disponibilidad: se alcanza si las personas autorizadas pueden acceder a tiempo

a la información a la que estén autorizadas.
El disponer de la información después del momento necesario puede equivaler a la

falta de disponibilidad. Otro tema es disponer de la información a tiempo sin que ésta
sea correcta, e incluso sin saberse, lo que puede originar la toma de decisiones
erróneas.
Más grave aún puede ser la ausencia de disponibilidad absoluta por haberse pro-

ducido algún desastre. En ese caso, a medida que pasa el tiempo el impacto será ma-
yor, hasta llegar a suponer la falta de continuidad de la entidad como ha pasado en
muchos de los casos producidos (más de un 80% según las estadísticas).
Debe existir además autenticidad: que los datos o información sean auténticos,
introducidos o comunicados por usuarios auténticos y con las autorizaciones necesa-
rias.
4.4. FASES DE LA AUDITORIA DE SEGURIDAD
Con carácter general pueden ser:
Concreción de los objetivos y delimitación del alcance y profundidad de la auditoría, así

como del período cubierto en su caso, por ejemplo revisión de accesos del último
trimestre; si no se especifica, los auditores deberán citar en el informe el período
revisado, porque podría aparecer alguna anomalía anterior, incluso de hace mucho
tiempo, y llegarse a considerar una debilidad de la auditoría.
· Análisis de posibles fuentes y recopilación de información: en el caso de los internos

este proceso puede no existir.
· Determinación del plan de trabajo y de los recursos y plazos en caso necesario, así
como de comunicación a la entidad.
· Adaptación de cuestionarios, y a veces consideración de herramientas o perfi-

les de especialistas necesarios, sobre todo en la auditoría externa.
· Realización de entrevistas y pruebas.
· Análisis de resultados y valoración de riesgos.
· Presentación y discusión del informe provisional.
· Informe definitivo.
4.5. AUDITORIA DE LA SEGURIDAD FÍSICA
Se evaluarán las protecciones físicas de datos, programas, instalaciones, equipos,

redes y soportes, y por supuesto habrá que considerar a las personas: que estén prote-
gidas y existan medidas de evacuación, alarmas, salidas alternativas, así como que no
estén expuestas a riesgos superiores a los considerados admisibles en la entidad e in-
cluso en el sector, por ejemplo por convenio o normativa específica; y si bien todos
estos aspectos suelen ser comunes con las medidas generales de la entidad, en una
auditoría de sistemas de información nos preocupamos especialmente por quienes
están en el área o de los daños que puedan afectar a los usuarios de los sistemas si
entra dentro de la auditoría.
Las amenazas pueden ser muy diversas: sabotaje, vandalismo, terrorismo, acci-
dentes de distinto tipo, incendios, inundaciones, averías importantes, derrumbamientos,
explosiones, así como otros que afectan a las personas y pueden impactar el fun-
cionamiento de los centros, tales como errores, negligencias, huelgas, epidemias o
intoxicaciones.
(Hay algo más que no recogemos en los informes, pero convencidos de que se trata
de una amenaza real sí lo comentamos verbalmente a veces en la presentación del
informe o en cursos a sabiendas de que produce comentarios: la lotería; si toca en un
área un premio importante, juegan todos el mismo número, y no existen sustitutos o no
hay una documentación adecuada - pensemos en un grupo que mantiene una apli-
cación- se puede originar un problema importante, y la prevención no es fácil porque no
se puede impedir el hecho).
Desde la perspectiva de las protecciones físicas algunos aspectos a considerar son:

Ubicación del centro de procesos, de los servidores locales, y en general de cualquier

elemento a proteger, como puedan ser los propios terminales, especialmente en zonas
de paso, de acceso público, o próximos a ventanas en plantas bajas. Protección de
ordenadores portátiles, incluso fuera de las oficinas: aeropuertos, automóviles,
restaurantes...
· Estructura, diseño, construcción y distribución de los edificios y de sus plantas.
· Riesgos a los que están expuestos, tanto por agentes externos, casuales o no, como
por accesos fisicos no controlados.
. Amenazas de fuego (materiales empleados); riesgos por agua: por accidentes

atmosféricos o por averías en
las conducciones; problemas en el suministro eléctrico, tanto por caídas como por
perturbaciones.
. Controles tanto preventivos como de detección relacionados con los puntos

anteriores, así como de acceso
basándose en la clasificación de áreas según usuarios, incluso según día de la
semana y horario.
. Además del acceso, en determinados edificios o áreas debe controlarse el contenido

de carteras, paquetes,
bolsos o cajas, ya que podrían contener explosivos, así como lo que se quiere sacar
del edificio, para evitar
sustituciones o sustracción de equipos, componentes, soportes magnéticos,
documentación u otros activos.
. El control deberá afectar a las visitas, proveedores, contratados, clientes... y en

casos más estrictos
igualmente a los empleados; los ex empleados se deberán considerar visitas en todo
caso.
. Protección de los soportes magnéticos en cuanto a acceso, almacenamiento y

posible transporte, además de
otras protecciones no físicas, todo bajo un sistema de inventario, así como
protección de documentos impresos y de cualquier tipo de documentación clasificada.
Es fácil y barato obtener copias magnéticas periódicas de datos y de programas frente

al perjuicio que nos puede causar el no haberlo hecho; es mucho más difícil o caro, o no
es posible, obtener copias con igual valor de otros objetos o activos como obras de arte.
Todos los puntos anteriores pueden, además, estar cubiertos por seguros.
4.6. AUDITORIA DE LA SEGURIDAD LOGICA
Es necesario verificar que cada usuario sólo pueda acceder a los recursos a los que
le autorice el propietario, aunque sea de forma genérica, según su función, y con las
posibilidades que el propietario haya fijado: lectura, modificación, borrado, ejecución...
trasladando a los sistemas lo que representaríamos en una matriz de accesos en la
que figuraran los sujetos: grupos de usuarios o sistemas, los objetos que puedan ser
accedidos con mayor o menor asiduidad: un disco, una aplicación, una base de datos,
una librería de programas, un tipo de transacción, un programa, un tipo de campo... y
para completar la tripleta, las posibilidades que se le otorgan: lectura, modificación,
borrado, ejecución...
Desde el punto de vista de la auditoría es necesario revisar cómo se identifican y

sobre todo autentican los usuarios, cómo han sido autorizados y por quién, y qué ocurre
cuando se producen transgresiones o intentos: quién se entera y cuándo y qué se hace.
En cuanto a autenticación, hasta tanto no se abaraten más y generalicen los sis-

temas basados en la biométrica, el método más usado es la contraseña, cuyas carac-

terísticas serán acordes con las normas y estándares de la entidad, que podrían con-
templar diferencias para según qué sistemas en función de la criticidad de los recursos
accedidos.
Algunos de los aspectos a evaluar respecto a las contraseñas pueden ser:
· Quién asigna la contraseña: inicial y sucesivas.
· Longitud mínima y composición de caracteres.
· Vigencia, incluso puede haberlas de un solo uso o dependientes de una función

tiempo.
· Control para no asignar las "x" últimas.
· Número de intentos que se permiten al usuario, e investigación posterior de los

fallidos: pueden ser errores del
usuario o intentos de suplantación.
. Si las contraseñas están cifradas y bajo qué sistema, y sobre todo que no aparezcan
en claro en las pantallas, listados, mensajes de comunicaciones o corrientes de
trabajos (JCL en algunos sistemas).
. Protección o cambio de las contraseñas iniciales que llegan en los sistemas, y que a
menudo aparecen en los
propios manuales.
. Controles existentes para evitar y detectar caballos de Troya: en este contexto se trata
de un programa
residente en un PC que emulando un terminal simule el contenido de la pantalla que
recoge la identificación y
contraseña del usuario, grabe la contraseña y devuelva control al sistema verdadero
después de algún mensaje
simulado de error que normalmente no despertará las sospechas del usuario.
· La no-cesión, y el uso individual y responsable de cada usuario, a partir de la

normativa.
Siempre se ha dicho que la contraseña ha de ser difícilmente imaginable por ajenos
y fácilmente recordable por el propio usuario, y este último aspecto se pone en peligro
cuando un mismo usuario ha de identificarse ante distintos sistemas, para lo que puede
asignar una misma contraseña, lo que supone una vulnerabilidad si la protección es
desigual, por ser habitual que en pequeños sistemas o aplicaciones aisladas las
contraseñas no están cifradas o lo estén bajo sistemas vulnerables; si opta por asignar
varias contraseñas puede que necesite anotarlas.
La solución más adecuada por ahora puede consistir en utilizar sistemas de iden-
tificación únicos (single sign-on) que faciliten la administración y el acceso,
permitiéndolo o no a según qué usuarios/sistemas/funciones, o bien adoptar cualquier
otro tipo de solución que, con garantías suficientes, pueda propagar la contraseña entre
sistemas.
En la auditoría debemos verificar que el proceso de altas de usuarios se realiza

según la normativa en vigor, y que las autorizaciones requeridas son adecuadas, así
como la gestión posterior como variaciones y bajas, y que los usuarios activos siguen
vigentes, y si se revisa cuáles son inactivos y porqué, por ejemplo contrastando
periódicamente con la base de datos de empleados y contratados. Debiera estar
previsto bloquear a un usuario que no accediera en un período determinado ¿35 días?
Otra posible debilidad que debe considerarse en la auditoría es si pueden crearse

situaciones de bloqueo porque sólo exista un administrador, que puede estar ausente
de forma no prevista, por ejemplo por haber sufrido un accidente, e impedir la creación

de nuevos usuarios en un sistema de administración centralizada y única; en más de

una ocasión, según de qué entorno se trate hemos recomendado la existencia de algún
usuario no asignado con perfil especial y contraseña protegida que pueda utilizar
alguien con autoridad en caso de emergencia: todas sus operaciones deberán quedar
registradas para control y auditoría.
4.7. AUDITORIA DE LA SEGURIDAD Y EL DESARROLLO DE APLICACIONES
Todos los desarrollos deben estar autorizados a distinto nivel según la importancia
del desarrollo a abordar, incluso autorizados por un comité si los costes o los riesgos
superan unos umbrales; se revisará la participación de usuarios, y de los auditores
internos si la auditoría es externa, a qué librerías pueden acceder los desarrolladores, si
hay separación suficiente de entornos, la metodología seguida, ciclos de vida, gestión
de los proyectos, consideraciones especiales respecto a aplicaciones que traten datos
clasificados o que tengan transacciones económicas o de riesgo especial, términos de
los contratos y cumplimiento, selección y uso de paquetes, realización de pruebas a
distintos niveles y mantenimiento posterior, así como desarrollos de usuarios finales.
El pase al entorno de explotación real debe estar controlado, no descartándose la

revisión de programas por parte de técnicos independientes, o bien por auditores
preparados, a fin de determinar la ausencia de "caballos de Troya", bombas lógicas y
similares, además de la calidad.
Otro aspecto es la protección de los programas, al menos desde dos perspectivas:

de los programas que sean propiedad de la entidad, realizados por el personal propio o
contratado su desarrollo a terceros, como el uso adecuado de aquellos programas de
los que se tenga licencia de uso.
4.8. AUDITORIA DE LA SEGURIDAD EN EL AREA DE PRODUCCION
Las entidades han de cuidar especialmente las medidas de protección en el caso de

contratación de servicios: desde el posible marcado de datos, proceso, impresión de
etiquetas, distribución, acciones comerciales, gestión de cobros, hasta el outsourcing
más completo, sin descartar que en el contrato se prevea la revisión por los auditores,
internos o externos, de las instalaciones de la entidad que provee el servicio.
También debe revisarse la protección de utilidades o programas especialmente

peligrosos, así como el control en generación y cambios posteriores de todo el software
de sistemas, y de forma especial el de control de accesos.
Otro aspecto a revisar es el control de los formularios críticos.
La gestión de problemas y cambios y la calidad son aspectos que también tienen

que ver con la seguridad.
4.9. AUDITORIA DE LA SEGURIDAD DE LOS DATOS
Es un aspecto que puede entenderse dentro de la Producción y las Comunicacio-

nes, pero que merece ser tratado de forma especifica. Decíamos que los datos y la
información pueden llegar a constituir el activo más crítico para la entidad, hasta el
punto de que en muchas multinacionales la función genérica de administración de
seguridad tiene la denominación de Data Security.
Los datos, además de alfanuméricos, pueden consistir en imágenes de planos, en

otros diseños u objetos, gráficos, acústicos, y otros, y estar almacenados en medios y
soportes diversos.
La protección de los datos puede tener varios enfoques respecto a las característi-
cas citadas: la confidencialidad, disponibilidad e integridad. Puede haber datos críticos
en cuanto a su confidencialidad, como datos médicos u otros especialmente sensibles
(sobre religión, sexo, raza...), otros datos cuya criticidad viene dada por la
disponibilidad: si se pierden o no se pueden utilizar a tiempo pueden causar perjuicios

graves y, en los casos más extremos poner en peligro la continuidad de la entidad, y

finalmente otros datos críticos atendiendo a su integridad, especialmente cuando su
pérdida no puede detectarse fácilmente o una vez detectada no es fácil reconstruirlos.
Aunque los libros no suelen citarlo así, se hablará de controles en los diferentes
puntos del ciclo de vida de los datos, que es lo que ha de revisarse en la auditoría:
. Desde el origen del dato, que puede ser dentro o fuera de la entidad, y puede incluir
preparación,
autorización, incorporación al sistema: por el cliente, por empleados, o bien ser
captado de otra forma, y
debe revisarse cómo se verifican los errores.
· Proceso de los datos: controles de validación, integridad, almacenamiento: que

existan copias suficientes, sincronizadas y protegidas.
. Salida de resultados: controles en transmisiones, en impresión, en distribución, en

servicios contratados de
manipulación y en el envío; conciliación previa de salidas con entradas, por
personas diferentes, para
detectar errores y posibles intentos de fraude.
. Retención de la información y protección en función de su clasificación: destrucción

de los diferentes
soportes que la contengan cuando ya no sea necesaria, o bien desmagnetización.
Es necesaria la designación de propietarios, clasificación de los datos, restricción

de su uso para pruebas, inclusión de muescas para poder detectar usos no autori-
zados, así como aprovechar las posibilidades de protección, control y auditoría del
Sistema de Gestión de Bases de Datos que se esté utilizando.
En cuanto a la clasificación de datos e información debe revisarse quién la ha

realizado y según qué criterios y estándares; no suele ser práctico que haya más de
cuatro o cinco niveles. En ocasiones la denominación sin clasificar se aplica tanto a los
datos que no requieren protección - en ocasiones incluso conviene divulgarlos - como a
los que están pendientes de clasificar, por lo que es necesario diferenciar las dos
situaciones. También es conveniente que se distinga por categorías, asociadas a áreas
funcionales o proyectos.
Aquellos soportes que contengan datos o información de los niveles más críticos
estarán especialmente protegidos, incluso cifrados. Entre esos soportes pueden estar:
magnéticos, papel, comunicaciones, correo electrónico, fax, e incluso voz.
En algunas entidades tienen etiquetas o carátulas para diferenciar soportes, listados

y documentos cuyo contenido está especialmente clasificado, lo que en ocasiones
puede llegar a alertar incluso a distancia a quienes no estén autorizados.
Respecto a cliente-servidor es necesario verificar los controles en varios puntos, y

no sólo en uno central como en otros sistemas, y a veces en plataformas heterogéneas,
con niveles y características de seguridad muy diferentes, y con posibilidad de
transferencia de ficheros o de captación y exportación de datos que pueden perder sus
protecciones al pasar de una plataforma a otra.
En el caso del contenido de ficheros y bases de datos, las etiquetas debieran

acompañarles incluso en extracciones parciales que variaran de plataforma, lo que en la
actualidad no está plenamente conseguido en todos los casos cuando en las redes
intervienen plataformas y sistemas que no se entienden bien entre sí en cuanto a segu-
ridad; aunque en este momento hay intentos de cierta normalización y van apareciendo
herramientas que van permitiendo la protección en entornos heterogéneos.
También pueden usarse bases de datos distribuidas, lo que puede añadir comple-
jidad al sistema y a los controles a establecer.

La información del nivel más alto de clasificación normalmente se entregará (o

dejará ver) bajo controles estrictos, incluso anotando qué se entregó o enseñó, a
quiénes, cuándo, y con la autorización de quién si este extremo es necesario.
En la auditoría, si entra en los objetivos, se analizará la destrucción de la infor-

mación clasificada: tipo de destructora, tamaño de las partículas, y especialmente dón-
de se almacena hasta su destrucción, que suele ser un punto débil.
En el caso de soportes magnéticos éstos habrán de ser destruidos,

desmagnetizados de forma adecuada, o sometidos a varias grabaciones diferentes
antes de su nueva utilización.
En ocasiones se recomienda en una auditoría que las copias que recibieran distintos
directivos no fueran idénticas - sin afectar a su contenido sustancial- a fin de poder
detectar el origen de fugas o copias, que al parecer se sospechaba que se venían
produciendo.
En el caso de ser necesario el transporte de datos clasificados debe realizarse por

canales seguros, y si es en soporte magnético o por transmisión deben ir cifrados,
además de la posibilidad de transportar soportes magnéticos en compartimentos cerra-
dos y que la llave no esté en poder de los transportistas o esté protegida.
La protección y la confidencialidad de los datos
La protección y el control de la confidencialidad de los datos de la empresa implica

la previsión de tres tipos de manipulaciones:
- El acceso no autorizado a los datos y al software que se encuentran en el

emplazamiento central.
- El robo o la copia de ficheros o software depositado en un soporte magnético de
seguridad.
- La conexión física con las líneas de telecomunicación por las cuales circulan los
datos por copia de éstas.
EL ACCESO NO AUTORIZADO A LOS DATOS QUE SE ENCUENTRAN EN EL

EMPLAZAMIENTO CENTRAL
Este riesgo debe ser estudiado muy particularmente, pues permite al operador
fraudulento no solamente la posibilidad de consultar los ficheros y, si se diera el caso,
los programas, sino también de modificarlos con las consecuencias catastróficas que
pueden tener las manipulaciones, como: malversación de fondos y destrucción del
entorno.
Distinguiremos en las medidas de prevención las siguientes:
- Medidas de prevención de acceso por la identificación del individuo recurrente.

- Medidas de prevención de acceso por la identificación del terminal recurrente.
- Medidas de prevención de acceso a la forma de los datos y su soporte de
almacenamiento.
Medidas de prevención por la identificación del individuo recurrente
Estudiaremos primeramente los modos de identificación del individuo recurrente,

después examinaremos las técnicas de software de protección.
El modo de identificación del individuo recurrente Distinguiremos de nuevo:
- la identificación lógica por contraseña;

- la identificación por cualquier medio físico.
a) La identificación lógica por contraseña

La eficacia de una protección de acceso al entorno informático por atribución de

códigos de usuarios y de contraseñas supone respetar algunas reglas básicas.
. ¿Las contraseñas se atribuyen individualmente a cada usuario?
Las contraseñas colectivas, por ejemplo por servicio o por aplicación, raramente
mantienen su confidencialidad por mucho tiempo.
. ¿Las contraseñas deben ser modificadas regularmente?
Algunos programas dedicados al control de las protecciones de acceso imponen que

la contraseña sea modificada con regularidad por su propietario, condición
indispensable para una confidencialidad real (la obligación de una modificación cada
trimestre parece ser una periodicidad razonable).
. ¿Las contraseñas son suficientemente «sofisticadas»?
Algunas contraseñas son utilizadas tan a menudo que unas cuantas tentativas son
suficientes para dar con ellas. Estas son, por ejemplo, las iniciales de los usuarios, su
fecha de nacimiento, la fecha de la creación de la contraseña, etc. El auditor, por
sondeo, procederá control de la verdadera confidencialidad de algunas de ellas.
. Se protege el cuadro de contraseñas?
Además de la protección del acceso al fichero de contraseñas, el auditor se

asegurará de que éste no sea objeto de ediciones regulares.
¿Es posible detectar las tentativas de acceso no autorizadas?
La identificación, en tiempo real o en tiempo diferido, de las tentativas de acceso no

autorizado permite detectar a tiempo operaciones fraudulentas eventuales.
No obstante, esta identificación no debe llevar a sospechar sistemáticamente de
todos los usuarios sin razón.
. Después de varias tentativas de acceso infructuosas,

¿son desconectados los usuarios?
Por lo general, se prevé una desactivación de un código de usuario después de tres

tentativas de acceso con contraseñas equivocadas. En caso contrario, sería fácil, con
las técnicas disponibles hoy día, programar en un microordenador un algoritmo de
búsqueda de la contraseña.
. ¿Se ha sensibilizado a los usuarios de los riesgos que puede originar el

«préstamo» de sus contraseñas?
Esta pregunta vale a fortiori para las «ventas» de contraseña.
b) La identificación física del individuo que opera
Estas técnicas sustituyen generalmente el uso de contraseñas, y no se acumulan a

ella, salvo aplicaciones de altísima seguridad.
. ¿Existen sistemas de autorización de acceso por medio

de tarjeta magnética?
La tarjeta magnética también se refiere al individuo. Esta técnica, también costosa,

está llamada a desarrollarse en los próximos años.
. ¿Existen otros sistemas de identificación?

A título de ilustración citemos el reconocimiento vocal, la identificación de las huellas

dactilares, del fondo de ojo. Estas técnicas están hoy día en fase experimental y, por
supuesto, reservadas a campos específicos de altísima seguridad (militares, etc.)
Las técnicas de software de protección

a) Los principales modos de acceso a los datos
Una protección eficaz representa que se tiene que conocer perfectamente el

conjunto de los modos de acceso al entorno informático. Estos modos de acceso
pueden ser clasificados en varias categorías.
· El acceso a través de una aplicación transaccional
Para cada una de las aplicaciones procesadas en una empresa (gestión comercial,
gestión de compras, contabilidad, producción, etc.) las transacciones son puestas a
disposición de los usuarios, el acceso inicial se hace, por lo general, a través de menús.
Según sea el caso, las transacciones autorizan la toma de datos, o la consulta sobre la
puesta al día de los datos.
· El acceso a través del arranque de programas en tiempo diferido
Este modo de acceso está, en principio, reservado al personal informático. Implica la

posibilidad de conformar trabajos en el entorno de producción por medio del editor. Los
JCL y los programas a ejecutar son, por lo general, almacenados en las bibliotecas
previamente a su ejecución, pero es igualmente posible, si el autor del programa aspira
a ser discreto, crear y conformar un trabajo en tiempo real, sin ninguna copia de
seguridad en biblioteca.
. El acceso a través de herramientas de sistemas
Siempre por medio del editor, existe software básico que permite consultar y poner
al día los ficheros sin pasar por un programa o una transacción.
Este software básico no deja ninguna pista de las modificaciones llevadas a cabo.
· El acceso a través de herramientas de infocentro
El infocentro pone a disposición de los usuarios todos o parte de los ficheros de

explotación para consultas.
El acceso a las herramientas de infocentro se hace bien por las transacciones
dedicadas a este efecto, o bien por medio del editor.
b) La auditoria de las técnicas de software de protección
A continuación encontraremos un conjunto de preguntas cuya única finalidad es

responder a un objetivo más general: ¿el acceso al entorno informático está limitado
sólo a las personas autorizadas? Las respuestas a las preguntas siguientes, ya sean
positivas o negativas, deben ser también interpretadas en su conjunto.
. ¿El acceso a las aplicaciones transaccionales está protegido por contraseña?
El acceso a las transacciones, en principio, está prohibido al personal informático.

Cada usuario está autorizado a acceder a algunas transacciones, definidas de forma
limitada en función de su perfil.
. ¿Está prohibido a los usuarios el acceso al editor?
Una limitación de acceso eficaz se obtiene orientando a cada usuario, a partir de su

conexión, hacia un menú que contenga sólo las funciones que le están autorizadas.
En algunos casos, la disponibilidad del infocentro implica que los usuarios tengan
acceso al editor. En tal caso, se tendrá en cuenta una limitación a las únicas funciones
útiles de éste.

. ¿Está protegido con contraseña el arranque de programas en tiempo diferido?
No obstante, un control de este estilo representa que la contraseña figure

claramente en el JCL. Por esta razón se puede preferir el control de acceso en el editor.
Por lo menos, el acceso a las bibliotecas que contengan el JCL deberá estar protegido.
. ¿Está estrictamente reglamentado el acceso al software de sistema de actualización

de !os ficheros?
En términos de auditoría, los programas básicos son temibles por su facilidad de

utilización y por la falta de huellas tras cualquier manipulación llevada a cabo.
Si bien no deben estar prohibidos totalmente (se revelan extremadamente útiles en
algunos casos), su uso debe estar reservado a un número extremadamente limitado de
personas, y ser objeto de una formalización muy estricta (cualquier intervención será
referenciada y se indicarán los objetivos y la naturaleza de las operaciones llevadas a
cabo).
. ¿la utilización de las herramientas de infocentro impide toda madificación de los

ficheros de producción?
El infocentro debe excluir cualquier posibilidad de actualización de los Ficheros de
producción. En cambio, es del todo previsible entregar a los usuarios una copia de todo
o parte de estos ficheros para el análisis con un
nuevo proceso eventual. Esta copia estará disponible en el emplazamiento central, o
transferida a un microordenador .
. ¿Está previsto el control de acceso a los datos?
Se pueden prever en este campo:
Controles de acceso a los ficheros; a cada fichero se le asociará una lista de usuarios
autorizados a acceder a él.
Controles de acceso específicos en el interior de un fichero, a ciertos tipos de datos. A
título de ejemplo, en un fichero de personal, distinguiremos tres niveles de autorización:
el más amplio, para los datos administrativos, un segundo más limitado, para el acceso
a las remuneraciones, y un tercero, todavía más reducido, para el acceso a los ficheros
de cuadros superiores y dirigentes; los sistemas de autorización específicos están
previstos en algunos sistemas de gestión de base de datos.
. ¿Están previstos las controles de acceso a las bibliotecas?
Las bibliotecas de programas en explotación, fuente u objeto, serán tratados con

una atención especial.
La protección y la confidencialidad de los datos
. ¿Están previstos los controles de acceso por volumen - disco físico?
De no ser así, seda imposible reconstruir el contenido de un fichero, analizando los

datos que figuran en el disco físico en el que está implantado.
. ¿Los controles de contraseñas están controlarlos en las tablas y no están incluidos

«en bruto» en los programas?
Aunque en los grandes sistemas existan programas dedicados al control de las

protecciones de acceso, no ocurre siempre lo mismo en los microordenadores, donde
los controles algunas veces deben ser programados por los equipos de desarrollo. El
auditor comprobará que las contraseñas estén incluidas en las tablas y fácilmente
modificables, y no directamente incluidas en los programas, en cuyo caso el sistema
sería demasiado rígido para ser eficaz (en efecto, en la segunda hipótesis, es muy
posible que las contraseñas no serían jamás modificadas).

. ¿El software de control de autorización de acceso permite discernir entre la

autorización de consulta de los datos y la autorización de actualización de los
mismos?
Las autorizaciones de consulta pueden estar más ampliamente distribuidas que las
de actualización.
Ejemplo: sólo la contabilidad introduce los asientos contables, pero otros servicios
pueden ser autorizados a consultar las cuentas de terceros.
· P. ¿Se ha implantado un software de control de la seguridad?
Los grandes sistemas IBM son la herencia de un cierto número de programas

dedicados al control de la seguridad. Estos programas tienen en común la ventaja de
controlar la protección del entorno independientemente del modo de acceso.
Desde un terminal, se puede acceder a los ficheros y a las bibliotecas de programas
de aplicación a través de diferentes programas básicos, del sistema de explotación
(MVS), del monitor de teleproceso (CICS), del editor (TSO) o de cualquier programa a
tiempo diferido introducido en la lista de espera.
Un primer método de control de acceso consiste en integrar en algunos de estos
programas básicos un proceso de autorización. De este modo, el monitor de
teleproceso CICS posee sus propias tablas de contraseña.
El inconveniente de este método reside en el hecho de que cada programa básico
sólo controla los accesos que utilizan sus propios procedimientos. Por ejemplo: el
monitor de teleproceso no permitirá a un informático no autorizado la utilización de las
transacciones de consultas de ficheros de personal, pero no le imposibilitará modificar
directamente este fichero con la ayuda del editor.
Por el contrario, los programas de control de seguridad permitirán proteger los
recursos (ficheros, bibliotecas, volúmenes discos físicos, bases de datos, transacciones,
programas), independientemente del modo de acceso utilizado. En la figura 4 se
muestra una ilustración de este método.
Citemos como ejemplos de estos programas los tres más difundidos actualmente en
el gran sistema IBM:
RACF de IBM;
TOP SECRET de COMPUTER ASSOCIATES
ACF2, también de COMPUTER ASSOCIATES, que está avocado a ser abandonado
progresivamente.
c) Los principios funcionales del control de las autorizaciones de acceso
A continuación, volveremos sobre algunos principios fundamentales del control de

las autorizaciones de acceso.
. ¿Hay un responsable de autorizaciones de acceso?
Este responsable podrá crear los perfiles de cada director o jefe de servicio, y les
proporcionará el conjunto de las habilitaciones necesarias para el ejercicio de sus
funciones. A continuación, cada uno de ellos podrá, a su vez, definir las habilitaciones
que concederá a sus colaboradores.
¿Las habilitaciones están acordes con el principio de un buen control interno?
El auditor se interesará en particular por:
- El principio de separación de las funciones.

- El principio de control jerárquico.
Las medidas de prevención de acceso por identificación del terminal recurrente
Cada vez más, las aplicaciones informáticas autorizan, por razones diversas las
conexiones a la unidad central desde terminales no identificados nominativamente
por el sistema:
El ingeniero de sistemas se conecta desde su miniterminal personal para asegurar

un mantenimiento urgente.
El fabricante se conecta con el sistema central para asegurar el
«telemantenimiento», o sea, el mantenimiento a distancia.
La aplicación «administración de ventas» prevé una conexión de los ", vendedores
durante sus viajes desde un microordenador portátil.
Los clientes se conectan desde puestos miniterminal para obtener informaciones
comerciales.
Estos tipos de accesos son extremadamente peligrosos, pues la sola

proteccióncontra intrusiones externas reside en la confidencialidad de las
confidencialidad de las contraseñas.
En algunos casos, las técnicas de identificación del terminal que se conectan

permiten reducir notablemente
el riesgo de intrusión.
. ¿Está previsto un procedimiento de identificación física del terminal que se

conecta?
Cuando los terminales susceptibles de conectarse a la unidad central son conocidos,

es posible memorizar sus señas físicas en una tabla. La tentativa de acceso de
cualquier otro terminal será rechazada.
. En la utilización de redes públicas, ¿se prevén, si esto es posible, procedimientos de

recuperación automática del comunicante?
En algunas aplicaciones, se prevén procedimientos de conexión entre la central y los

terminales o microordenadores a distancia a través de pública (red conmutada,
TRANSPAC, etc.). Citemos por ejemplo:
Las tiendas que se conectan cada tarde con sus centrales para «teletransmitir» el
fichero de ventas de la jornada.
Las direcciones regionales de una empresa que introducen sus pedidos en modo
transaccional en el ordenador de la central.
Estos dos ejemplos tienen en común:
El hecho de que la lista de llamadas posibles (tienda o dirección regional) está

identificada.
Un riesgo de intrusión si un defraudador potencial conociera el número del comunicado
y simulara una llamada desde una tienda o de una dirección regional.
El procedimiento que permite prevenir este riesgo es, por tanto, el siguiente:
- La lista de números (telefónicos o TRANSPAC) de los comunicantes potenciales se

encuentra identificada en la unidad central.
- En el momento de cada llamada, el comunicante se identifica.
- Después del control, la unidad central vuelve a llamar al comunicante al número de
abonado conocido registrado en sus propios ficheros.
. En el caso de la utilización de una red TRANSPAC, ¿se prevé, si esto fuere posible, la
utilización de un grupo cerrado de abonados (GCA)?
El grupo cerrado de abonados es un servicio prestado por TELECOM en las redes
TRANSPAC que permite identificar, para una aplicación dada, la lista de abonados
autorizados a llamar los unos a los otros.
Las medidas de prevención de acceso a las formas de datos y su soporte de

almacenamiento
. ¿Los datos más sensibles son objeto de una codificación?
La codificación consiste en la transformación, con la ayuda de un software

apropiado, de los datos en un formato que les hace totalmente incomprensibles para

una persona que no disponga del software.

La operación inversa consiste en remitir los datos en su formato inicial antes de su
utilización para las aplicaciones.
Veremos que la técnica de la codificación sólo puede ser totalmente eficaz cuando el
acceso a los datos o, por lo menos, al software de codificación, esté también
reglamentado.
. ¿Está previsto para algunos ficheros o programas extremadamente sensibles que sólo
sean cargados en el momento de su ejecución?
Esta solución, debido a lo trabajoso de su puesta en práctica, sólo debe ser

considerada en casos muy excepcionales. Encontraremos a continuación una
ilustración concreta.
Imaginemos que una empresa desea imperativamente mantener confidenciales las
remuneraciones de sus cuadros superiores, pero que, por razones prácticas, desea que
sus fichas de nóminas estén establecidas por los mismos programas y en los mismos
equipos que las de los demás empleados.
El acceso al fichero de personal será, por supuesto, estrictamente reglamentado.
Por precaución complementaria, podemos imaginar que los registros que contengan los
cuadros superiores sean objeto de una codificación. Pero una codificación sólo es
eficaz cuando el software de las codificaciones está también protegido.
Por ello, una solución eficaz consiste en que el software, en vez de estar
almacenado permanentemente en los discos, sea conservado en cinta magnética
(guardada en sitio seguro) y cargado en el momento de la ejecución del programa de
nóminas.
El procedimiento del proceso de la nómina será, en este caso, el siguiente:
- El responsable carga el programa de codificación y después ejecuta la aplicación.

- Recupera también los listados de salida.
- Tras la terminación del proceso, destruye el software de cifrado en el disco.
EL ROBO O LA COPLA DE FICHEROS O SOFTWARE QUE SE ENCUENTRAN EN

UN,SOPORTE DE PAPEL O MAGNETICO
Por soporte magnético, se entiende esencialmente las cintas o cartuchos

magnéticos que sirven para las copias de seguridad o para las transmisiones de datos.
. ¿El acceso al parque de cintas y de cartuchos magnéticos está reglamentado?
Recordemos que gran número de robos de ficheros están relacionados con una
insuficiente protección del acceso a los archivos de cintas.
. ¿Para los ficheros «sensibles» se evitan los procedimientos de envíos de cintas o

cartuchos «por mensajero» ?
La mayoría de los responsables informáticos tienen en mente por lo menos un caso

de ficheros transmitidos por un servicio de entrega (interno o externo a la empresa) y
que no han llegado jamás a su destinatario.
. ¿Se han incluido en los ficheros «sensibles» trampas que

permitan comprobar que no hayan sido divulgados en el exterior?
Cuando algunos ficheros son susceptibles de interesar a otras empresas, de la

competencia o no (por ejemplo, los ficheros de clientes), es útil incluir trampas con el fin
de evidenciar inmediatamente cualquier utilización no autorizada. Se incluirá, por
ejemplo, en el fichero el nombre y la dirección de uno de los directores, voluntariamente
mal ortografiados.

. ¿Están previstos, si fuere necesario, procedimientos de validación de los datos

contenidos en los ficheros sensibles?
El caso más conocido es el de ficheros de remesa de nóminas enviados por las

empresas a sus bancos, los cuales deben tener un registro en cabeza de totalización
que permita validar el contenido de la cinta enviada.
Recordaremos, a título ilustrativo, que aunque este procedimiento sea, por lo

general, conocido por la población informática, ha permitido ya desenmascarar a
defraudadores que habían modificado el importe de su propio salmo en el fichero de
remesas, sin pensar en modificar el registro de totalización.
. ¿Existe un software que permita controlar la lectura y la reescritura de las cintas o

cartuchos magnéticos?
Es de desear que estén previstos, con la ayuda de un programa de control de la

seguridad o de un programa de control del parque de cintas o cartuchos, controles que
impidan:
- la reescritura de cintas que contengan ficheros activos,

- la lectura de ficheros almacenados en cintas por personas no autorizadas a acceder a
estos ficheros.
. ¿Se ha previsto un procedimiento de control específico en el momento de la edición de

listados «sensibles» ?
Para evitar el riesgo de difusión de informaciones confidenciales, se preverá, por

ejemplo, que algunos listados sensibles sean editados en presencia del usuario
responsable de la aplicación.
¿Se ha previsto la destrucción sistemática después de la utilización de los listados que

contengan informaciones «sensibles»?
Hace algunos años, una ESI se hizo involuntariamente bastante célebre cuando
copias de listados confidenciales destinados a uno de sus clientes fueron substraídas
de sus papeleras y difundidas en el exterior.
LA CONEXIÓN FISICA CON LAS LINEAS EN LAS CUALES CIRCULAN LOS DATOS
. ¿Se ha previsto la codificación de las informaciones confidenciales que circulan en las

redes públicas o privadas?
En la medida que es casi imposible controlar la ausencia de conexión no autorizada

en el conjunto de la línea física (incluso en el caso de la utilización de la red
TRANSPAC, la unión entre la empresa y el punto de entrada más próximo es propia de
ésta), la técnica de la codificación es el medio más eficaz de evitar el robo de los datos
que circulan por las líneas.
4.10. AUDITORIA DE LA SEGURIDAD EN COMUNICACIONES Y REDES
En las políticas de la entidad debe reconocerse que los sistemas, redes y mensajes
transmitidos y procesados son propiedad de la entidad y no deben usarse para otros
fines no autorizados, por seguridad y por productividad, tal vez salvo emergencias
concretas si así se ha especificado, y más bien para comunicaciones por voz.
En función de la clasificación de los datos se habrá previsto el uso de cifrado, que

en la auditoría se evaluará o se llegará a recomendar, y se revisarán la generación,
longitud, comunicación, almacenamiento y vigencia de las claves, especialmente de las
maestras.
Cada usuario sólo debe recibir en el menú lo que pueda seleccionar realmente.

Los usuarios tendrán restricción de accesos según dominios, únicamente podrán

cargar los programas autorizados, y sólo podrán variar las configuraciones y compo-
nentes los técnicos autorizados.
Deberán existir protecciones de distinto tipo, y tanto preventivas como de detección,

ante posibles accesos sobre todo externos, así como frente a virus por diferentes vías
de infección, incluyendo el correo electrónico.
Se revisarán especialmente las redes cuando existan repercusiones económicas

porque se trate de transferencia de fondos o comercio electrónico.
Algunos de los puntos complementarios a revisar son:
· Tipos de redes y conexiones.

· Información y programas transmitidos, y uso de cifrado.
· Tipos de transacciones.
· Tipos de terminales y protecciones: físicas, lógicas, llamada de retorno.
· Protección de transmisiones por fax si el contenido está clasificado, si bien es
preferible evitar el uso de este medio en ese caso.
· Protección de conversaciones de voz en caso necesario.
· Transferencia de ficheros y controles existentes.
· Consideración especial respecto a las conexiones externas a través de pasarelas
(gateway) y encaminadores (routers), así como qué controles existen.
· Ante la generalización de modalidades avanzadas de proceso, empiezan a
preocupar y a ser objeto de auditoría aspectos como:
Internet e Intranet: separación de dominios e implantación de medidas espe-

ciales, como normas y cortafuegos (firewall), y no sólo en relación con la se-
guridad sino por accesos no justificados por la función desempeñada, como a
páginas de ocio o eróticas, por lo que pueden suponer para la productividad.
El correo electrónico, tanto por privacidad (PGP, Pretty Good Privacy se está
usando mucho) y para evitar virus como para que el uso del correo sea ade-
cuado y referido a la propia función, y no utilizado para fines particulares, como
se ha intentado hacer en muchas entidades y no siempre con éxito, con otros
recursos anteriores como teléfono, fax, fotocopiadoras, o el uso de los propios
ordenadores.
Otro de los aspectos que preocupan es la protección de programas, y tanto la

prevención del uso no autorizado de programas propiedad de la entidad o de los
que tenga licencia de uso, como la carga o transmisión de otros de los que no se
tenga licencia o simplemente para los que no exista autorización interna.
También preocupa el control sobre las páginas web: quién puede modificarlo y desde
dónde, porque se han dado casos desagradables en alguna entidad que impactan muy
negativamente en su imagen, y no tanto por los que lo ven directamente, sino por la
publicidad que en los medios se pueden dar a estos hechos. Finalmente preocupan
también los riesgos que puedan existir en el comercio electrónico, aunque se están
empezando a utilizar sistemas fiables como SET (Secure Electronic Transaction).
En relación con todo ello, y para facilitar el control y la auditoría, es necesario que
queden registrados los accesos realizados a redes exteriores y protegidos esos
registros, así como la fecha y hora y el usuario o sistema, así como el tipo de
información transferida y en qué sentido.
4.11. AUDITORIA DE LA CONTINUIDAD DE LAS OPERACIONES
Es uno de los puntos que nunca se deberían pasar por alto en una auditoría de se-
guridad, por las consecuencias que puede tener el no haberlo revisado o haberlo hecho
sin la suficiente profundidad: no basta con ver un manual cuyo título sea Plan de Con-
tingencia o denominación similar, sino que es imprescindible conocer si funcionaría con
las garantías necesarias y cubriría los requerimientos en un tiempo inferior al fijado y

con una duración suficiente.
Hablamos de Plan de Contingencia o Plan de Continuidad, frente a otras

denominaciones que en principio descartamos como Recuperación de Desastres o Plan
de Desastres (sí nos parece adecuada Plan de Recuperación ante Desastres, pero las
incidencias a prever son también de otros niveles).
En la auditoría es necesario revisar si existe tal plan, si es completo y actualizado, si

cubre los diferentes procesos, áreas y plataformas, o bien si existen planes diferentes
según entornos, evaluar en todo caso su idoneidad, así como los resultados de las
pruebas que se hayan realizado, y si permite garantizar razonablemente que en caso
necesario, y a través de los medios alternativos, propios o contratados, podría permitir
la reanudación de las operaciones en un tiempo inferior al fijado por los responsables
del uso de las aplicaciones, que a veces son también los propietarios de las mismas
pero podrían no serio.
Si las revisiones no nos aportan garantías suficientes debemos sugerir pruebas

complementarias o hacerlo constar en el informe, incluso indicarlo en el apartado de
limitaciones.
Es necesario verificar que la solución adoptada es adecuada: centro propio, ajeno

compartido o no... y que existe el oportuno contrato si hay participación de otras enti-
dades aunque sean del mismo grupo o sector. No está de más revisar si en el caso de
una incidencia que afectara a varias entidades geográficamente próximas la solución
prevista daría el servicio previsto a la auditada.
Un punto fundamental en la revisión es la existencia de copias actualizadas de los

recursos vitales en un lugar distante y en condiciones adecuadas tanto físicas como de
protección en cuanto a accesos; entre dichos recursos estarán: bases de datos y
ficheros, programas (mejor si existen también en versión fuente), JCL (Job Control
Language) o el equivalente en cada sistema, la documentación necesaria, formularios
críticos y consumibles -o garantías de que se servirían a tiempo -, documentación,
manuales técnicos, direcciones y teléfonos, los recursos de comunicaciones necesarios:
datos y voz, y cualesquiera otros requeridos para funcionar con garantías.
Otros aspectos que hemos encontrado como debilidades a veces son: que exista
copia del propio plan fuera de las instalaciones primarias, que esté previsto ejecutar
determinado software en un equipo alternativo, con identificación específica diferente de
la del equipo primario que es el inicialmente autorizado; y que se tenga copia accesible
del contrato, tanto para demostrar algo al proveedor como para verificar los términos
pactados.
Dentro de la criticidad de las aplicaciones se puede distinguir entre las más críticas,
con impacto muy alto en el negocio y sin alternativa, otras con alternativas, e incluso
diferenciando si con costes altos o inferiores, y aquellas cuya interrupción, al menos en
un número de días fijado, no tiene casi incidencia, y habrá que distinguir qué tipos de
consecuencias e impacto, en función del sector y entidad, y día del mes en que
ocurriera el incidente, y tal vez la hora en algunos casos.
Frente a lo que venía siendo la previsión de contingencias en estos años pasados,

centrándose sólo en el host como gran servidor, hoy en día, con la clara tendencia a
entornos distribuidos, es necesario considerar también éstos en la previsión de las
contingencias.
Es necesario en la auditoría conocer las características del centro o sistema alter-

nativo, y debe revisarse si la capacidad de proceso, la de comunicación y la de alma-
cenamiento del sistema alternativo son suficientes, así como las medidas de protección.
Debe existir un manual completo y exhaustivo relacionado con la continuidad en el

que se contemplen diferentes tipos de incidencias y a qué nivel se puede decidir que se
trata de una contingencia y de qué tipo.

A pesar de la importancia del tema y de las consecuencias nefastas que se pueden

derivar si no se han previsto las contingencias, es un tema no exigido por ley en
Argentina, si bien parece sobradamente justificada su existencia para defender los
intereses de los accionistas, clientes, proveedores, empleados, o ciudadanos en
general según qué tipo de entidad sea; en algún caso se consulta al incluirlo en el
informe como una recomendación -pero qué obliga a tener el plan? Afortunadamente es
un punto fácil de explicar y que la Alta Dirección suele entender y aceptar.
4.12. FUENTES DE LA AUDITORIA
Las fuentes estarán relacionadas con los objetivos, y entre ellas pueden estar:
· Políticas, estándares, normas y procedimientos.
· Planes de seguridad.
· Contratos, pólizas de seguros.
· Organigrama y descripción de funciones.
· Documentación de aplicaciones.
· Descripción de dispositivos relacionados con la seguridad.
· Manuales técnicos de sistemas operativos o de herramientas.
· Inventarios: de soportes, de aplicaciones.
· Topología de redes.
· Planos de instalaciones.
· Registros: de problemas, de cambios, de visitas, de accesos lógicos producidos.
· Entrevistas a diferentes niveles.
· Ficheros.
· Programas.
· La observación: no figura en los manuales pero la consideramos importante.
· Actas de reuniones relacionadas.
· Documentación de planes de continuidad y sus pruebas.
· Informes de suministradores o consultores.
A menudo los clientes ofrecen a los auditores externos los informes de los internos o
de otros externos anteriores, es preferible utilizarlos cuando ya está en vías el borrador
de informe para no verse influido.
4.13. EL PERFIL DEL AUDITOR
El perfil que se requiere para llevar a cabo auditorías de sistemas de información no

está regulado, pero es evidente que son necesarias una formación y sobre todo una
experiencia acordes con la función, e incluso con las áreas a auditar: seguridad física,
sistemas operativos concretos, determinados gestores de bases de datos o
plataformas, e incluso lenguajes si hubiera que llegar a revisar programas, además de
ser imprescindibles en el perfil otras características o circunstancias comunes, como
independencia respecto a los auditados, madurez, capacidad de análisis y de síntesis, e
interés no meramente económico.
En el seno de la ISACA existe un certificado relacionado: CISA (Certified

Information Systems Auditor).
A la hora de crear la función de auditoría interna de sistemas de información se

suele plantear si se forma a auditores ya expertos en otras áreas: auditoría de cuentas
normalmente, o si se forma a técnicos del área de informática, o si se contrata a
auditores de otra entidad, ya experimentados; cada opción tiene sus ventajas e inconve-
nientes, entre los que pueden estar:
Los auditores de otras áreas serán expertos en técnicas generales como entre-
vista, y en redactar informes, pero desconocerán las particularidades y riesgos
de las tecnologías de la información.
Los informáticos y expertos en áreas relacionadas, no serán expertos en técnicas
generales y en control (salvo que provengan de administración de seguridad), si
bien puede ser más fácil que aprendan estos aspectos que enseñar -y
especialmente mantener al día- a un auditor general respecto a novedades tec-
nológicas.

Quien venga de otra entidad puede no tener ni unos inconvenientes ni otros, e

incluso puede conocer el sector; y hay una ventaja más: no conoce a las perso-
nas que tendrá que entrevistar, lo cual es positivo, pero no siempre se quieren
incorporar recursos externos.
Otro aspecto es dónde ubicar la función: encontramos con frecuencia que está
dentro del área de Informática o Sistemas de Información o Tecnologías: en definitiva
dentro del área auditada, por lo que no tiene la independencia necesaria. Es preferible
que esté dentro de la auditoría general o que sea una función staff de algún directivo
por encima de las áreas objeto de auditoría.
Se incluye un cuadro (véase la figura 4.3) con algunas recomendaciones en cuanto

a pautas de conducta.
Fig. 4.3
QUE PUEDEN HACER QUE NO PUEDEN HACER

LOS AUDITORES LOS AUDITORES
Ser independientes y objetivos Actuar en beneficio propio por encima del
interés del cliente
Recomendar Obligar, forzar, amenazar
Ser competentes en la materia (seguridad) Asumir encargos para los que no estén
preparados
Basar sus informes en verificaciones y evi- Basarlos en suposiciones

dencias
Verificar que se evalúan periódicamente Revisar la seguridad "día a día" o

Riesgos o bien evaluarlos administrarla (son funciones de otros)
Conocer perfiles de usuarios Realizar gestiones de perfiles de usuarios
Conocer criterios y prácticas sobre Asignación contraseñas o conocerlas

contraseñas
Verificar que las aplicaciones se desarrollan Realizar funciones de análisis o gestionar

Según normas y se incorporan controles proyectos
Revisar codificación de programas Codificar programas

(seguridad y calidad)
y las pruebas realizadas, o bien probarlos
Revisar la documentación (aplicaciones, Realizar la documentación.

Programas)
Verificar que se sigan los procedimientos Escribir los procedimientos
Responsabilizarse del contenido de sus in- Aceptar presiones de sus jefes o clientes y
formes que el informe no sea veraz
Evaluar riesgos e informes Garantizar que no se puedan realizar/haber

realizado delitos, fraudes o errores
Sustentar los informes con papeles de Enzarzarse en discusiones de diferencias y

trabajo Definiciones
Estar al día en cuanto a avances, riesgos, Auditar con técnicas, métodos o recomenda-
Metodologías ciones obsoletos.

4.14. TÉCNICAS, MÉTODOS Y HERRAMIENTAS
En cada proceso de auditoría se fijan los objetivos, ámbito y profundidad, lo que

sirve para la planificación y para la consideración de las fuentes, según los objetivos,
así como de las técnicas, métodos y herramientas más adecuados. El factor sorpresa
puede llegar a ser necesario en las revisiones, según lo que se quiera verificar.
Como métodos y técnicas podemos considerar los cuestionarios, las entrevistas, la

observación, los muestreos, las CAAT (Computer Aided Auditing Techniques), las
utilidades y programas, los paquetes específicos, las pruebas, la simulación en paralelo
con datos reales y programas de auditor o la revisión de programas.
4.15. CONSIDERACIONES RESPECTO AL INFORME
En él se harán constar los antecedentes y los objetivos, para que quienes lean el
informe puedan verificar que ha habido una comunicación adecuada, así como qué
metodología de evaluación de riesgos y estándares se ha utilizado, y una breve des-
cripción de los entornos revisados para que se pueda verificar que se han revisado
todas las plataformas y sistemas objeto de la auditoría.
Debe incluirse un resumen para la Dirección en términos no técnicos.
Dependiendo de los casos será preferible agrupar aspectos similares: seguridad

física, seguridad lógica... o bien clasificar los puntos por centros o redes, especialmente
en entidades grandes si existen responsables diferentes: en caso de duda será un
punto a comentar previamente con quienes van a recibir el informe, ya que con fre-
cuencia prefieren entregar a cada uno la parte que más le afecta, así como planificar y
controlar área a área o por departamentos la implantación de medidas.
En cada punto que se incluya debe explicarse por qué es un incumplimiento o una
debilidad, así como alguna recomendación, a veces abarcando varios puntos.
El informe ha de ser necesariamente revisado por los auditados, así como discutido
si es necesario antes de emitir el definitivo.
En muchos casos, bien en el propio informe o en otro documento, se recogen las

respuestas de los auditados, sobre todo cuando la auditoría es interna.
La entidad decide qué acciones tomar a partir del informe, y en el caso de los
auditores internos éstos suelen hacer también un seguimiento de las implantaciones.
Los auditados siempre buscan un informe lo más benigno posible, mientras que los
auditores nos proponemos llegar a un informe veraz y útil; estos diferentes puntos de
vista a veces crean conflictos en el proceso de auditoría y en la discusión del informe.
En algunos casos los informes se han usado para comparar la seguridad de dife-
rentes delegaciones, sucursales, o empresas de un mismo grupo, o bien filiales de una
multinacional, pero si los entornos no son homogéneos las comparaciones pueden no
ser muy útiles y llegar a distorsionar.
Con frecuencia quienes han pedido la auditoría quieren conocer la calificación

respecto a seguridad, además de disponer de un informe complementario o resumen en
términos no técnicos; quieren saber si están aprobados en seguridad, así como los
riesgos más destacados.
Es necesario, por tanto, diferenciar puntos muy graves, graves, mejorables... u otra
clasificación, en definitiva establecer algunas métricas de seguridad y clasificar los
puntos según su importancia y prioridad, que pueden ser reconsideradas por la
Dirección de la entidad a la hora de implantar las medidas, y en algunos casos se pue-
de llegar a entregar una lista provisional de proyectos de implantación.

En ocasiones, en el caso de auditoría externa, los clientes que no conocen los

límites habituales de la auditoría sobreentienden que una vez finalizada ésta los
auditores daremos una asistencia más propia de consultores, y que incluso llevaremos
a cabo implantaciones, redactaremos normas, o que al menos en los informes
especificaremos las soluciones: nombre de la herramienta que refuerza la seguridad en
su entorno por ejemplo, cuando a menudo esto requiere un estudio que se sale de los
límites e incluso de la independencia propios de la auditoría. Por ello, es importante que
se delimiten las responsabilidades y los productos a entregar que son objeto de una
auditoría externa en el contrato o propuesta.
Algunos de los puntos importantes que pueden llegar a estar en los informes
respecto a seguridad, y sin que se pueda generalizar porque dependerá de la entidad,
sector y circunstancias, pueden ser la ausencia de:
· Copias de activos críticos en cuanto a continuidad, en lugar diferente y distante.
. Cumplimiento de la legislación aplicable así como de las políticas y normas

internas: en el
caso de la legislación incluso pueden producirse sanciones.
· Diferenciación de entornos de desarrollo y producción, en cuanto a datos y

programas, y control de accesos.
· Involucración de la Alta Dirección, preferentemente a través de algún comité.
· Motivación de los empleados y directivos en relación con la seguridad.
· Evaluación periódica y adecuada de riesgos.
· Segregación de funciones, así como una organización adecuada.
Es frecuente también que quienes han pedido la auditoría quieran conocer después
en qué medida se han resuelto los problemas, a partir de las decisiones tomadas, a
través de los informes de los auditores internos o de quienes implanten las medidas.
Otro deseo frecuente es querer conocer la evolución de la situación en el tiempo,

ya que aparecen nuevos riesgos, se reproducen Otros, y algunos pueden variar de
clasificación en función del cambio de plataformas u otros.
Para ello es útil mostrar en algún informe -principalmente los auditores internos-, al-
gunos cuadros que muestren la evolución, que en algunos casos ha sido útil para de-
mostrar la rentabilidad de una función como administración de la seguridad o auditoría
interna o para evaluar la utilidad de un plan de seguridad.
4.16. CONTRATACIÓN DE AUDITORIA EXTERNA
Se incluye el epígrafe porque consideramos su utilidad en función de las preguntas

que a veces se realizan y de los casos que hemos llegado a conocer: si no se sigue un
proceso de selección adecuado de auditores externos no se pueden garantizar los
resultados y se puede llegar al desencanto al recibir el informe, lo que puede suponer
no llegar a conocer las posibilidades reales de la auditoría de sistemas de información,
sobre todo en un tema tan delicado como la seguridad, o bien tener una visión pobre y
desfigurada, como les ocurre a algunos a partir de experiencias atípicas.
Algunas consideraciones pueden ser:
. La entidad auditora ha de ser independiente de la auditada en el caso de una

auditoría externa: si está ofreciendo otros servicios a la vez, o piensa ofrecerlos
en el futuro, o incluso a veces si ha sido proveedora en el pasado, a menudo
puede encontrar dificultades internas para entregar un informe veraz y completo.

En ocasiones los propios auditores lo han llegado a comunicar, por ética.
. Las personas que vayan a realizar el trabajo han de ser independientes y com-
petentes, según el objetivo: sistemas operativos o plataformas concretas, por lo
que no está de más examinar sus perfiles e incluso mantener alguna entrevista,
sin descartar preguntar por sorpresa en una reunión qué aspectos revisarían y
qué técnicas usarían en el entorno que se les describa.
. No es tan común pedir referencias de otros trabajos similares como en el caso

de consultoría pero se puede hacer, aunque para ello los auditores debieran
pedir permiso previo a sus clientes.
. La auditoría ha de encargarse a un nivel suficiente, normalmente Dirección

General o Consejero Delegado, y a este nivel recibir los informes, porque si no a
veces no se cuenta con el respaldo suficiente en las revisiones, y en todo caso
puede que si el informe no es favorable quede escondido, y se ha perdido el
dinero y a veces la oportunidad.
. Finalmente, a título de curiosidad, en una ocasión se pidió que no figurara la

palabra auditoría en el informe final, porque había aversión por el término, por
asociarse en la entidad a los auditores con los verdugos: no es un caso aislado y
es impropio.
. Recordemos que puede ser necesario dar o mostrar a los auditores todo lo que
necesiten para realizar su trabajo, pero nada más, e incluso lo que se les
muestre o a lo que se les permita acceder puede ser con restricciones: sólo parte
de una base de datos, epígrafes de algunas actas, o simplemente mostrarles
documentación, que no pueden copiar o no pueden sacar de las instalaciones del
cliente: se puede exigir una cláusula de confidencialidad, y raramente se les
deben mostrar datos reales confidenciales de clientes, proveedores, empleados
u otros, aunque se haga en la práctica con frecuencia.
En caso de duda o de conflicto puede decidir un comité de auditoría o el propio

de Dirección.
4.17. RELACIÓN DE AUDITORIA CON ADMINISTRACIÓN DE SEGURIDAD
Se han encontrado en más de una ocasión que la misma persona tenía las funcio-
nes de administración de seguridad y auditoría (informática) interna, lo cual puede
parecer bien a efectos de productividad, pero no es admisible respecto a segregación
de funciones, siendo preferible, si la entidad no justifica que dos personas cumplan en
exclusiva ambas funciones, que se cubra sólo una, o bien que la persona realice otras
funciones complementarias pero compatibles, como podrían ser algunas relacionadas
con calidad.
En entidades grandes la función consta además de corresponsales funcionales o
autónomos.
La función de Administración de Seguridad en parte será interlocutora en los
procesos de auditoría de seguridad, si bien los auditores no podemos perder nuestra
necesaria independencia, ya que debemos evaluar el desempeño de la función de ad-
ministración de seguridad, desde si sus funciones son adecuadas y están respaldadas
por algún documento aprobado a un nivel suficiente, hasta el cumplimiento de esas
funciones y si no hay conflicto con otras.
La función de auditoría de sistemas de información y la de administración de se-
guridad pueden ser complementarias, si bien sin perder su independencia: se trata de
funciones que contribuyen a una mayor y mejor protección, y resultan como anillos
protectores, como se muestra en la figura 4.4.

Entorno
protegido
Fig. 4.4 - Funciones de auditoría de S.I. y auditoría de seguridad como anillos

protectores.
Ambas funciones han de mantener contactos periódicos y prestarse cierta asistencia

técnica.
Normalmente Administración de seguridad habrá de implantar las recomendaciones

de los auditores una vez fijadas las prioridades por la Dirección de la entidad.
Administración de Seguridad puede depender del área de Sistemas de Información,

sobre todo si existe Auditoría de S.I. interna, pero si puede estar en peligro su
desempeño quizá sea preferible que tenga otra dependencia superior, o al menos una
dependencia funcional de áreas usuarias como puede ser de Dirección de Operaciones
o similar; la existencia de un comité de Seguridad de la Información, o bien de una
función de Seguridad Corporativa puede resultar útil.
En ocasiones los administradores de seguridad tienen casi exclusivamente una

función importante pero que sólo forma una parte de su cometido: la administración del
paquete de control de accesos: RACF, Top Secret, u otros, con frecuencia por haber
sido técnicos de sistemas, y en ocasiones porque siguen siéndolo, lo que representa
una gran vulnerabilidad y no siempre bien aceptada cuando la hemos recogido en los
informes de auditoría.
Por otra parte, si la persona que oficialmente administra la seguridad únicamente

incorpora usuarios y asigna contraseñas iniciales en uno de los sistemas, generalmente
el más importante, se trata de una labor necesaria pero en absoluto la única, dándose a
veces una carencia de objetivos de seguridad, de modelos, de planes de seguridad, así
como de seguimiento de transgresiones.
Otra situación que se suele producir respecto al paquete de control de accesos, y a

veces coexistiendo con la señalada, es la que indicábamos: coincidencia de los roles de
administración de seguridad y auditoría interna en la misma persona, relativamente
comprensible porque son papeles que hay que asignar en los sistemas o paquetes. He-
mos conocido situaciones de cierta tensión cuando los administradores han tenido que
crear usuarios con perfil de auditor -por ejemplo cuando éstos asumen sus funciones
respecto al paquete- y quitarse ese perfil a sí mismos.
Ambas funciones han de tener una dependencia jerárquica adecuada, una des-
cripción de funciones idónea, y que las personas cuenten con formación y experiencia
acordes y estén motivadas; cuando a alguien se le asigna una de estas funciones para
que no desaparezca del área o incluso de la entidad, como consecuencia de
reorganizaciones o absorciones, difícilmente va a cumplir bien su papel. Finalmente,
que ambas funciones, sin perder de vista su cometido, quieran colaborar para conseguir
un buen nivel de protección.
Volviendo brevemente a la formación y experiencia, se ha encontrado

vulnerabilidades de distinta índole en individuos con un conocimiento técnico de los

sistemas muy profundo, y probablemente mayores vulnerabilidades cuando se da el
caso contrario: aquellos que administran o revisan sin saber qué hacen, cómo lo hacen,
si afecta en el rendimiento, o si sus recomendaciones o imposiciones respecto a la
seguridad impactan gravemente en la productividad o crean situaciones de verdadero
bloqueo o de auténtica burocracia.
4.18. CONCLUSIONES
Aunque aún no se ha producido en Argentina (y menos aún el la zona) el despegue

de la auditoría ni de la seguridad que esperamos desde hace años, lo cierto es que se
han dado avances, y cabe esperar que siga esta tendencia y las entidades vayan
entendiendo cada vez más la utilidad de la protección de la información y de la
auditoría.
También es cierto que han surgido bastantes entidades suministradoras que han
incluido la seguridad y la auditoría entre sus posibles servicios, o simplemente han
aceptado trabajos, en ambos casos sin disponer de expertos, lo que con frecuencia ha
supuesto un desencanto en la entidad auditada, y a veces resultados penosos, que no
benefician ni a la profesión ni a la auditoría misma.
Por otra parte, los auditados finales, y más los responsables de las áreas que sus
colaboradores, siguen en muchos casos sin entender la esencia y utilidad de la
auditoría, y su obsesión es evitarla y, cuando ya es inevitable, a veces eludirla o al
menos no resultar entrevistados: como que el proceso no fuera con ellos (es del
responsable hacia abajo, pero exclusive, como dijo un Director de Sistemas de
Información en una ocasión), o tal vez para poder alegar que ellos no han facilitado la
información que figura en el informe final.
En otras ocasiones van preparando a los entrevistados respecto a qué deben decir y
qué no en cuanto a riesgos o controles existentes, e incluso han hecho que todas las
entrevistas se mantuvieran en su despacho y en su presencia, por lo que los auditores a
veces han de ser algo psicólogos sin formación para ello e interpretar lo que se nos
dice, lo que se nos quiere decir, y distinguir la versión oficial de la realidad, interpretar
silencios y miradas, entrevistar a varias personas y llegar a evidencias por distintos
medios.
Por otra parte, hemos podido verificar que la auditoría, su filosofía, así como sus
técnicas y métodos, interesan cada vez más a los responsables de Sistemas de Infor-
mación, a veces para conocer cómo pueden evaluar los auditores sus áreas, pero a
menudo para saber cuáles pueden ser los riesgos y qué controles implantar.
Lo que ellos mismos pueden realizar no se puede considerar una auditoría, más por
falta de independencia que por desconocimiento de las técnicas, pero sí pueden
constituir unos autodiagnósticos muy útiles, especialmente cuando se realizan con
ayuda de listas o herramientas adaptadas o adaptables al entorno.
Los cambios en la tecnología influyen en qué auditar y en cómo auditar. En efecto,

en los últimos años han ido apareciendo áreas nuevas, como las mencionadas de
comercio electrónico, cliente-servidor, orientación a objetos, entornos multiplataforma,
teletrabajo y outsourcing, además de otros sistemas operativos o nuevas versiones de
los mismos, lo que viene a suponer novedad en los riesgos y en las medidas y la
necesidad imperiosa por parte de los auditores de estar muy al tanto: como otros
técnicos relacionados con las tecnologías de la información tenemos la tendencia - o el
placer y la oportunidad- de estar permanentemente informados.
Aunque las implantaciones de la seguridad van siendo más sofisticadas y llegando a

áreas o aspectos casi desconocidos hace años, esto no implica que estén plenamente
resueltos los más básicos: encontramos bastantes deficiencias en controles físicos, no
tanto porque no existan cuanto por las brechas o descuidos que se pueden encontrar.
Más preocupante aún es la inexistencia de controles básicos, como en relación con

la segregación de funciones, separación de entornos o casi ausencia de normativa.
La auditoría en sistemas de información no está suficientemente implantada en la

mayoría de las entidades argentinas, si bien supondría una mayor garantía de que las
cosas se hacen bien y como la entidad quiere: en general hay coincidencia entre ambos
puntos. Puede ser también una profesión con futuro cuando la auditoría despegue.
Como función aporta al auditor un conocimiento privilegiado del área de Sistemas de

Información con una perspectiva muy amplia.
La forma de realizar el trabajo va variando y se está llegando a aplicar el control por

excepción y la teleauditoría.
En cuanto a nuevas áreas, surge el auge del comercio electrónico, el control de

páginas WEB: la revisión de quien autoriza, varia y controla los contenidos: en las
entidades por seguridad y productividad, y en los hogares, aunque esto se sale de la
auditoría y queda en el control para evitar que los menores accedan a contenidos con
violencia o pornografía.

Auditoria de Sistema - Tema4

Cargado por

Copyright:

Formatos disponibles

Auditoria de Sistema - Tema4

Cargado por

Información del documento

Título original

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

Auditoria de Sistema - Tema4

Cargado por

Copyright:

Formatos disponibles

AUDITORIA DE SISTEMAS COMPUTARIZADOS

Figura 4.I. Encuentro entre seguridad y auditoría

Lo cierto es que cada día es mayor la importancia de la información, especialmente

Entonces, debemos ir hablando más de Auditoría en Sistemas de Información que

La nueva denominación abarca globalmente los sistemas de información: desde la

Algunas entidades tienen detallados sus costes en la contabilidad analítica, ¿cómo

Volviendo a la seguridad, en la figura 4.2 se observa que los objetivos de la auditoría

. Hugo Ruchinsky 1 Lic. Miguel Badaracco

Objetivos de la seguridad y de la Auditoría de la Seguridad

La expresión seguridad informática, que es la más usada, puede llegar a relacio-

Si no existen suficientes y adecuadas medidas de protección se puede perder in-

Debe evaluarse en la auditoría si los modelos de seguridad están en consonancia

En cuanto a la justificación de la auditoría, basta sólo decir que tanto la normativa

La realidad es que no se conocen datos completos y fiables sobre el nivel de

. Hugo Ruchinsky 2 Lic. Miguel Badaracco

Podemos hablar de Objetivos de Control respecto a la seguridad, que vienen a ser

Cada entidad ha de definir sus propios objetivos de control, en cuanto a seguridad y

En los informes se recomendará la implantación o refuerzo de controles, y en

El sistema de control interno ha de basarse en las políticas, y se implanta con

La realidad es que el control interno no está generalizado en Argentina (y menos

Cuando existe un sistema de control interno adecuado los procesos de auditoría,

4.2. AREAS QUE PUEDE CUBRIR LA AUDITORIA DE LA SEGURIDAD

. Hugo Ruchinsky 3 Lic. Miguel Badaracco

Lo que hemos denominado controles directivos, es decir los fundamentos de la

· El desarrollo de las políticas: procedimientos, posibles estándares, normas y

· Amenazas físicas externas: inundaciones, incendios, explosiones, corte de líneas

. Comunicaciones y redes: topología y tipo de comunicaciones, posible uso de

. Hugo Ruchinsky 4 Lic. Miguel Badaracco

. El entorno de Producción, entendiendo como tal Explotación más Técnica de

· El desarrollo de aplicaciones en un entorno seguro, y que se incorporen controles

· La continuidad de las operaciones.

4.3. EVALUACIÓN DE RIESGOS

Se trata de identificar los riesgos, cuantificar su probabilidad e impacto, y analizar

Desde la perspectiva de la auditoría de la seguridad es necesario revisar si se han

. Hugo Ruchinsky 5 Lic. Miguel Badaracco

La protección no ha de basarse sólo en dispositivos y medios físicos, sino en

El factor humano es el principal a considerar, salvo en algunas situaciones de

Además, es conveniente que haya cláusulas adecuadas en los contratos, sean de

Es necesaria una separación de funciones: es peligroso que una misma persona

En un proceso de auditoría, por tanto, se evaluarán todos estos aspectos y otros,

Algunos manuales hablan de transferir los riesgos, por ejemplo contratando un

Si la entidad auditada está en medio de un proceso de implantación de la seguridad,

La evaluación de riesgos puede ser global: todos los sistemas de información,

. Hugo Ruchinsky 6 Lic. Miguel Badaracco

A menudo en la auditoría externa se trata de saber si la entidad, a través de fun-

La seguridad no es un tema meramente técnico, aunque sean muy técnicas algunas

Al hablar de seguridad siempre se habla de sus tres dimensiones clásicas:

La confidencialidad: se cumple cuando sólo las personas autorizadas (en un

Pensemos que alguien introdujera variaciones de forma que perdiéramos la in-

La disponibilidad: se alcanza si las personas autorizadas pueden acceder a tiempo

El disponer de la información después del momento necesario puede equivaler a la

. Hugo Ruchinsky 7 Lic. Miguel Badaracco

4.4. FASES DE LA AUDITORIA DE SEGURIDAD

Con carácter general pueden ser:

Concreción de los objetivos y delimitación del alcance y profundidad de la auditoría, así

· Análisis de posibles fuentes y recopilación de información: en el caso de los internos

· Adaptación de cuestionarios, y a veces consideración de herramientas o perfi-

· Realización de entrevistas y pruebas.

· Análisis de resultados y valoración de riesgos.