Máster en Ciberseguridad

Área de Normativas de Ciberseguridad 2021

Caso Práctico: Otras Normativas en el Ámbito de
la Seguridad de la Información
Prof. José Antonio Rubio

Guillermo Olivares Calderón

Ejercicio 1
Datos

Una administración pública ha iniciado el proceso de adecuación al Real Decreto

3/2010 por el que se aprobó el Esquema Nacional de Seguridad. La intención de esta
administración es cumplir con los plazos establecidos para el cumplimiento de las
obligaciones y medidas que le impone el ENS.

Para ello, el responsable de seguridad TI quiere conocer primero el estado en el que se

encuentra respecto a los requisitos del Real Decreto y, para ello, ha contratado a una
consultora especializada en la que usted es el consultor asignado al proyecto.

Lo único que de lo que dispone esta administración actualmente es de una normativa

sobre el uso correcto de los recursos informáticos puestos a disposición del personal y
la responsabilidad en que éste incurriría en caso de violación de dicha normativa.

Se pide

1. Explicar las actividades a realizar para proporcionar a la administración la

información sobre su estado actual respecto al Esquema Nacional de
Seguridad.

En consideración a que el estamento público cuenta sólo con una normativa sobre el
uso correcto de los recursos informáticos y las responsabilidades que caben a los
funcionarios en el buen uso de estos recursos; se hace necesario realizar las siguientes
actividades:

• Elaborar y aprobar la Política de Seguridad, incluyendo la definición de roles y la

atribución de responsabilidades. Se debe especificar la forma en que se debe
elaborar.

• Se deben clasificar los sistemas según el valor de la información tratada y de los

servicios prestados. Debiendo especificarse la información que se maneja y los
servicios que se prestan. Se debe considerar la designación de los responsables de
las informaciones o servicios y la valoración de los mismos.

• Se debe efectuar un análisis de riesgos en el que debe incluirse la valoración de las

medidas de seguridad aplicadas. El plan de adecuación incluirá un análisis de
riesgos, según los requisitos exigidos para la categoría determinada para el sistema.
En este análisis deben evaluarse las salvaguardas y los riesgos residuales que
existan en el momento de aprobar el plan de adecuación.

• Elaborar y aprobar la Declaración de Aplicabilidad de las medidas de Seguridad.

Debe indicarse una lista de medidas que se aplicarán al sistema. En caso de que
una medida exigida no se considere aplicable, debe justificarse esta no-
aplicabilidad. Si se recurre a medidas alternativas, se explicará a qué medidas
sustituyen y el motivo.

• Aplicar, operar y evaluar las medidas de seguridad mediante la gestión continuada

de la seguridad.

• Se deben realizar auditorías de seguridad de los sistemas. Pueden localizarse

carencias en el sistema por incumplir las medidas de seguridad o por la aparición de
riesgos inasumibles por el organismo. Los responsables de la Información y
 Servicios afectados, y en su defecto por el responsable de Seguridad, deben aceptar
los riesgos residuales.

• Finalmente se debe informar sobre el estado de la seguridad. Debiendo establecerse

actuaciones orientadas a solucionar las insuficiencias detectadas. Cada actuación
prevista comprenderá información sobre la deficiencia que soluciona, el plazo
previsto de ejecución y una valoración estimada del coste que tendrá.

2. Detallar qué medidas de carácter organizativo del anexo II del ENS

deberían ser implementadas.

Las medidas de carácter organizativo son aquellas medidas relacionadas con la

organización global de la seguridad. Todas ellas aplican en todas las dimensiones de la
seguridad (Disponibilidad, Autenticidad, Integridad, Confidencialidad y Trazabilidad);
así como en todas las categorías de los sistemas de información (Baja, Media y Alta).
Siendo estas las siguiente:

Política de seguridad (org.1).

La cual debe ser aprobada por el órgano competente que corresponda y deberá estar
reflejado en un documento escrito, el cual debe abordar en forma clara los siguientes
considerandos: Objetivos o misión de la organización; Marco legal y regulatorio en el
que se desarrollan las actividades; Los roles o funciones de seguridad, con sus
respectivos deberes y responsabilidades, así como el procedimiento de designación y
renovación; La estructura del o los Comité(s) para la gestión y coordinación,
considerando el ámbito de su responsabilidad, los miembros y la relación con otros
entes de la organización; Las lineamientos para la estructura de la documentación de
seguridad del sistema, su gestión y acceso. En consecuencia, la política de seguridad
debe ser alusivo y consistente con lo establecido en el Documento de Seguridad que
exige el Real Decreto 1720/2007.

Normativa de seguridad (org.2).

Se debe disponer de una serie de documentos que denoten: El uso correcto de
equipos, servicios e instalaciones; así como lo que se considerará de uso indebido y la
responsabilidad del personal con respecto al cumplimiento o transgresión de estas
normas, derechos, deberes y medidas disciplinarias de acuerdo con la legislación
vigente.

Procedimientos de seguridad (org.3).

Se dispondrá de una serie de documentos que aborden detalladamente en forma clara
y precisa: Como llevar a cabo las tareas habituales, así como quien debe realizar cada
tarea y Como identificar y reportar comportamientos irregulares.

Proceso de autorización (org.4)

Se debe establecer un proceso formal de autorizaciones que consideren todos los
elementos del sistema de información, a saber: Utilización de instalaciones (habituales
y alternativas); Paso de equipos a producción, en particular, equipos que involucren
criptografía; Paso de aplicaciones a producción; Establecimientos de enlaces de
comunicaciones con otros sistemas; Utilización de medios de comunicación (habituales
y alternativos); Utilización de soportes de Información; Utilización de equipos móviles
(notebook, smartphone, tablet, u otro de naturaleza análoga)
Ejercicio 2
Datos

La entidad BILLETES PARA TODOS gestiona la venta de billetes de tren mediante pago
electrónico. Dicha empresa se encuentra actualmente certificada en PCI DSS. Tiempo
más tarde, debido a una serie de acuerdos y decisiones por parte de la alta dirección,
se decide externalizar dicha gestión de venta de billetes a un tercero: GESTIONA S.A.

La empresa GESTIONA, que se encargará de gestionar la venta de billetes mediante

pago electrónico utilizando para ello un aplicativo residente en las instalaciones de
BILLETES PARA TODOS, quiere adecuarse a PCI DSS, puesto que la entidad que les ha
contratado se lo exige. Por ello, y para poder delimitar cómo afecta esta norma a la
empresa, se suministran los siguientes datos:
Mapa de red actualizado hoy en día:

Información documental y de utilidad:

• Las compras se realizan de la siguiente forma: el cliente llama a un número de

teléfono y es atendido por un operador. El operador, siguiendo las indicaciones del
cliente, selecciona el billete que más se adecue a las necesidades del mismo.
Seguidamente, el cliente procede a suministrar los datos de su tarjeta de crédito al
operador, quien los introduce en la aplicación. Los datos introducidos serán el
nombre el titular y el PAN. El PAN aparecerá codificado en pantalla en el momento
de su introducción, tal y como viene reflejado en la política de seguridad.
• Los operadores se conectan a la aplicación de BILLETES PARA TODOS utilizando un
navegador web (URL por HTTPS), previa validación en el directorio activo de
GESTIONA (usuario: GESTXX donde XX es un número secuencial. La contraseña es
de 8 caracteres, debiendo contener cifras y letras). Los datos de las tarjetas de
crédito se almacenan siempre en el servidor de BILLETES PARA TODOS y en ningún
caso en los equipos de GESTIONA S.A. La aplicación remota solicita un usuario único
para cada persona (BILLXX, donde XX es un número secuencial) y una contraseña
(8 cifras con caracteres y letras. Obligación de cambiarla cada 90 días, y que sea
diferente de las 4 anteriores. Bloqueo de 30 minutos tras 4 intentos fallidos, y logoff
tras 15 minutos de inactividad). Este sistema de validación está gestionado por
BILLETES PARA TODOS, y su correcto funcionamiento se comprueba con frecuencia
(aplicación y directorio activo). Todos estos puntos se encuentran documentado en
la política de seguridad.

• Con cierta periodicidad, se realizan auditorías de seguridad, generando un informe

de resultados. Las fechas de las auditorías se guardan en un registro de auditorías
con el objetivo de llevar un control estricto sobre la realización de las mismas, así
como sobre la solución de las deficiencias detectadas. Como parte complementaria a
este análisis, se realizan análisis de vulnerabilidades cada 4 meses aproximada-
mente.

• En la política, se explica que el almacenamiento de datos de las tarjetas se realiza

únicamente en las instalaciones de BILLETES PARA TODOS.

• Existe una política de seguridad que tiene mapeados los controles de PCI con cada
apartado correspondiente. Esta política tiene detalladas las reglas de firewall cor-
porativo implementadas para limitar y asegurar el entorno de las tarjetas. Además,
en la política se indica que estas reglas son revisadas cada 6 meses como mínimo.
Las restricciones implementadas incluyen restricción de información sobre direc-
cionamiento interno y sobre enrutamiento.

• En la política, se describe el procedimiento para extraer la configuración de los

routers, y el guardado de la misma. También se describe cómo sincronizar la confi-
guración de estos dispositivos.

• En la política, se detalla que no existen servicios publicados de cara al exterior. En

el entorno de tarjetas sólo se tiene acceso a la aplicación de BILLETES PARA TODOS
a través de la VPN. En el entorno de tarjetas no existe conexión a Internet.

• En la política, se han definido con detalle los parámetros de seguridad comunes que
se aplican a los componentes del sistema, así como las funcionalidades utilizadas en
cada caso.

• En la política, viene especificado que todos los accesos administrativos que no son
por consola utilizan una encriptación fuerte (SSH, VPN, SSL/TLS).

• La propia aplicación de BILLETES PARA TODOS dispone de un módulo de ticketing

específico que cubre las incidencias que puedan ocurrir en el sistema. Todo esto se
encuentra documentado en la política.

• En la política se ha definido un punto de retención de datos con los aspectos que se

describen a continuación. Los datos de las tarjetas de crédito sí quedan almacena-
das en las conversaciones telefónicas que los clientes mantienen con los operado-
 res, las cuales son grabadas. Se confirma que se almacenan datos de voz, por lo
que no existe ningún mecanismo automatizado que permita recuperar dichos datos,
o buscarlos. También se ha definido una cláusula de prohibición de acceso a esta
información por parte de trabajadores. Los datos de los soportes que almacenan la
voz son destruidos de forma segura utilizando un formateo a bajo nivel.

• Los equipos del entorno de tarjetas están protegidos con la solución McAfee EPO
(módulos de antivirus, antispyware y HIPS). Tanto la versión utilizada como los
procedimientos relacionados (actualización, mantenimiento, despliegue, logs, aná-
lisis, etc.) se encuentran documentados en la política.

• En la política se ha definido una gestión de vulnerabilidades robusta, con el objetivo

de que los sistemas siempre tengan los últimos parches y actualizaciones
instalados. Por otro lado, también se ha definido un proceso para identificar nuevas
vulnerabilidades de seguridad, siendo categorizadas por riesgo.

• Existe un sistema maduro y eficiente de gestión documental implantado en la

empresa, realizándose control de cambios, versiones de documentos y aprobación
de los mismos.

• En la política, se encuentran definidos en detalle los roles de la aplicación de

BILLETES PARA TODOS, y la asignación de los mismos a cada usuario (asignación
realizada en función de cargo desempeñado), previa autorización documentada por
parte de los responsables.

• Las medidas de seguridad especificadas en la política son transmitidas a los tra-

bajadores para que las conozcan y las respeten. Este conocimiento por parte del
trabajador está plasmado en la política.

• Los equipos del entorno de las tarjetas se encuentran en una sala específica prote-
gida mediante acceso por tarjeta. Cada operador tendrá una tarjeta de acceso que
le permitirá acceder a esta sala. Estas tarjetas de acceso serán específicas para el
entorno de las tarjetas. Además, existen cámaras que graban a todos los que
entran o salen de la sala. Estas grabaciones se almacenan durante 4 meses. Las
visitas se autorizarán previamente con una hoja de autorización (esta hoja se
almacenará durante 3 meses a modo de bitácora de visitas). Para identificar a un
visitante, se le dará una tarjeta de visita que le identifique y que tendrá que
devolver al finalizar la visita (caducará el acceso otorgado por la misma).

• El acceso físico a los puntos de conexión se encuentra controlado y está restringido.

• Se ha implementado un sistema de correlación y colección de logs SIEM, que per-

mite recopilar los logs de todos los dispositivos y elementos del sistema. El sistema
guarda los logs con fecha y hora de accesos, registro de auditoría, acciones
realizadas por el root, de carácter informativo, de creación y borrado de objetos del
sistema, de eventos (incluido su origen) y de errores. Los logs y alarmas generados
se revisan de forma diaria. Se guardan los registros de auditoría de los últimos 12
meses.

• El acceso a los registros de auditoría se encuentra limitado a los administradores de

los sistemas. Estos ficheros se encuentran protegidos contra modificaciones no
autorizadas.
• Se encuentra implementado un mecanismo IDS/IPS de red capaz de detectar y
bloquear dispositivos inalámbricos que intenten establecer una red ad hoc contra la
red de tarjetas.

• Se ha implementado un sistema de control de dispositivos que impide que los ope-

radores pinchen dispositivos USB no autorizados en sus equipos.

• En la política, se ha definido un procedimiento de destrucción de materiales que

puedan contener algún tipo de dato de tarjetas de crédito.

• Se encuentra implantado el sistema de inventario OCS inventory, con el que se

obtiene información a bajo nivel sobre los programas instalados.

Se pide:

1. ¿Realmente es necesario que la empresa GESTIONA S.A. se adecue a PCI

DSS? Razone su respuesta.

La empresa GESTIONA S.A. debe adecuarse a la Norma PCI DSS, no sólo por una
exigencia de BILLETES PARA TODOS que la contrato. Sino porque el consorcio PCI
define claramente que no importa el tamaño de la organización, independiente de si
vende productos o servicios, o si es una organización con o sin fines de lucro, mientras
la entidad “utilice este tipo de datos” debe cumplir con el estándar,

La norma es clara en definir a todas las entidades que participan en el proceso de las
tarjetas de pago y que le es aplicable la Norma de Seguridad de Datos. Como son las
entidades que almacenan, procesan o transmiten datos; tal es el caso de BILLETES
PARA TODOS, empresa Contratante, como aquellas que son “proveedoras de
Servicio”, que es el caso de GESTIONA S.A.

En resumen, GESTIONA S.A. es un proveedor de Servicio del tipo de CALL Center de

atención telefónica que gestiona la venta de pasajes de Tren a través de tarjetas de
Pago, utilizando los datos del cliente; como mandante de BILLETES PARA TODOS. por
lo que también debe adecuarse a la norma PCI DSS.

2. De ser así, indique el tipo de cuestionario SAQ que utilizaría, y por qué.

Teniendo ya la premisa que GESTIONA S.A. es un proveedor de Servicios

subcontratada, que debe adecuarse a la norma PCI DSS; deberá utilizar el cuestionario
SAQ-A.

Cuestionario utilizado para entidades que manejan solamente transacciones con tarjeta
ausente (no presencial-física), operando de esta forma a través de comercio
electrónico y órdenes por correo y/o teléfono. Como es el caso de los operadores
telefónicos disponibilizados por GESTIONA S.A., quienes operan remotamente en la
aplicación residente en la Red y plataforma de BILLETES PARA TODOS. Recordando,
que en GESTIONA S.A no se almacena, ni procesa los datos del titular de la tarjeta de
pago.
3. Rellene el cuestionario SAQ conforme a la información de la que se
dispone (si no existe dato sobre algún punto, se entenderá que no se
encuentra implementado o que falta información por parte del cliente, por
lo que se contestará indicando que no se encuentra información en la
política. Utilizar la plantilla adjunta.

En el caso de incumplimiento de un control, especificar el motivo de forma breve

en la columna “especial” y la solución, en la columna “solución”. Se recuerda que,
si un control no aplica al supuesto, esto se indicará en la columna “especial”.

DESARROLLAR Y MANTENER UNA RED SEGURA

Requisito 1: Instalar y mantener una configuración de firewall para proteger los datos.

Respuesta a la pregunta de PCI DSS Si No Especial Solución

1.1. ¿Están las normas de configuración del
firewall y router establecidas e
implementadas para incluir lo siguiente?
1.1.1. ¿Existe un proceso formal para aprobar y

✓
probar todos los cambios y las conexiones
de red en las configuraciones de los
firewalls y routers?
Se debe actualizar
diagrama con todos los
El diagrama no CI existentes, Ej.
1.1.2. ¿Existe un diagrama de red actual que refleja todos los IDS/IPS.
documenta todas las conexiones entre el componentes
entorno de los datos de titulares de
tarjetas y otras redes, incluso cualquier
✓ descritos, por lo
cual no se
Mantener un
Procedimiento de
red inalámbrica? encuentra actualización, frente a
actualizado la ocurrencia de los
cambios y/o
actualización de la Red.
1.1.3. ¿Existe un diagrama actual que muestra
todos los flujos de datos de titulares de
tarjetas entre los sistemas y las redes?
✓
1.1.4. ¿Se tiene un firewall implementado en

✓
cada conexión a Internet y entre
cualquier DMZ (zona desmilitarizada) y la
zona de la red interna?
La Política debe
La política no incorporar dicha
declara la descripción. Pero
1.1.5. ¿Existe una descripción de grupos, roles y
existencia de los además estos usuarios
✓
responsabilidades para una
entes citados la asociados a grupos y
administración lógica de los componentes
administración roles deben estar
de la red?
de los creados según su perfil
componentes y nivel de acceso en los
componentes (Firewall)
1.1.6. ¿Las normas de configuración del firewall
y del router incluyen una lista
documentada de servicios, protocolos y
puertos, incluida la justificación y la
✓
aprobación comercial para cada una?
1.1.7. ¿Requieren las normas de configuración

✓
de firewalls y routers la revisión del
conjunto de reglas de éstos, por lo
menos, cada seis meses?
1.2. ¿Restringen las configuraciones para
firewalls y routers las conexiones entre
redes no confiables y cualquier sistema
en el entorno de los datos de titulares de
tarjeta de la manera siguiente?
1.2.1. ¿Está restringido el tránsito entrante y

✓
saliente a la cantidad necesaria para el
entorno de los datos de titulares de
tarjetas?
La política
Se debe definir
declara que los
claramente en la
archivos de
1.2.2. ¿Están los archivos de configuración del política, el resguardo
configuración se
router seguros y sin riesgo de acceso no de este archivo.
encuentran
autorizado y sincronizados, por ejemplo, Además de incorporar
✓
guardados, pero
la configuración en ejecución (o activa) un control de
no se hace
coincide con la configuración de inicio versiones; para
mención en
(que se utiliza cuando se reinician las asegurar que lo que se
cuanto a su
máquinas)? ejecuta coincide con la
seguridad y el
configuración de inicio,
quienes tienen
a nivel de seguridad
acceso.
1.2.3. ¿Hay firewalls de perímetro instalados
entre las redes inalámbricas y el entorno
de datos del titular de la tarjeta y están
estos firewalls configurados para negar o,
si el tráfico es necesario para fines
comerciales, permitir solo el tráfico
✓
autorizado entre el entorno inalámbrico y
el entorno de datos del titular de la
tarjeta?
1.3. ¿Se prohíbe el acceso directo público
entre Internet y cualquier componente del
sistema en el entorno de datos de los
titulares de tarjetas de la manera
siguiente?
La política no
describe la
1.3.1. ¿Se implementó un DMZ para limitar el
implementación
tráfico entrante solo a aquellos
de la DMZ. No
componentes del sistema que
se informa sobre
proporcionan servicios, protocolos y
“servicios
puertos con acceso público autorizado?
publicados de
cara al exterior”
No se dispone
información en
1.3.2. ¿Está restringido el tránsito entrante de la política. No
Internet a las direcciones IP dentro del hay claridad en
DMZ? la definición
sobre lo
señalado.
Se requiere
validar
(pruebas) con
Cliente; a fin de
determinar si las
1.3.3. ¿Hay implementadas medidas
restricciones
antisuplantación para detectar y bloquear
implementadas
direcciones IP manipuladas a fin de que
sobre
no ingresen a la red?
direccionamiento
(Por ejemplo, bloquear el tráfico
interno citadas,
proveniente de Internet con una dirección
cubre el bloqueo
interna).
de tráfico
proveniente de
Internet con una
dirección
interna.
1.3.4. ¿Está el tráfico saliente desde el entorno La Política
de datos del titular de la tarjeta a declara que en
Internet expresamente autorizado? el entorno de
tarjetas no
existe conexión
a Internet
1.3.5. ¿Sólo se permite la entrada a la red de
conexiones establecidas? ✓
1.3.6. ¿Se colocaron componentes del sistema
que almacenan datos de titulares de
tarjetas (como una base de datos) en una
zona de red interna, segregada desde un
✓
DMZ y otras redes no confiables?
En la Política no
hay
antecedentes
que puedan
confirmar lo
señalado. Aun
1.3.7. ¿Se implementaron métodos para
cuando debe ser
prevenir la divulgación de direcciones IP
validado
privadas e información de enrutamiento
(pruebas) con el
desde en Internet?
Cliente, ya que
los métodos
pueden estar
implementados,
pero no
informados.
Se declara la
existencia de un
mecanismo
IDS/IPS. No
obstante, no se
registra la
1.4. ¿Hay instalado en forma activa software
existencia de
de firewall personal (o una funcionalidad
firewall o ajustes
equivalente) en todos los dispositivos
de
móviles (incluidos los de propiedad de los
configuraciones
trabajadores y/o de la empresa) que
especificas en
tengan conexión a Internet cuando están
dispositivos
fuera de la red (por ejemplo,
móviles de la
computadoras portátiles que usan los
empresa o de
trabajadores), y que también se usan
los empleados,
para acceder al CDE?
que son
necesarios para
acceder al CDE,
tal como lo
establece la
Norma
1.5. ¿Las políticas de seguridad y los
procedimientos operativos para la
administración
documentas, en
de
uso
firewalls
y son
están
de
✓
conocimiento de todas las partes afectas?
Ejercicio 3
Datos

Una organización ha implantado ISO 20000 para la prestación de sus servicios de

hosting y housing y quiere someter su Sistema de Gestión de Servicios de TI (SGSTI)
a la correspondiente auditoría de tercera parte para obtener la certificación.

Para ello, el responsable del SGSTI se pone en contacto con varias entidades de certi-
ficación de las existentes en el mercado y presenta las ofertas de cada una de ellas a
la Dirección de la empresa para que seleccione una.

Examinadas las propuestas económicas, la organización se decanta por una entidad de

certificación de la que usted forma parte como auditor.

EL SGSTI de la organización se encuentra en un grado de implantación notable, si bien

no se ha previsto un procedimiento de control de la documentación por no considerarlo
necesario.

Se pide

1. Detallar al menos cinco requisitos generales del SGSTI que habría que
auditar.

Entre los requisitos generales que habría que auditar se encuentra:

Responsabilidad de la Dirección,
En consideración a que es la alta dirección quien deberá proporcionar evidencia de su
compromiso con la planificación, establecimiento, implementación, operación,
monitoreo, revisión y mantenimiento y mejora del SGS y los servicios, mediante: el
establecimiento y comunicando el alcance; la política y los objetivos para la gestión de
servicio; creando un plan de gestión del servicio; comunicando la importancia de
cumplir con los requisitos del servicio y cumplir con los requisitos reglamentarios,
legales y contractuales; asegurando la provisión de los recursos; planificando y
realizando auditorías internas y revisiones de la administración y asegurar los que los
riesgos a los servicios sean evaluados y gestionados.

Política de Gestión de Servicio.

Considerando el alcance y límites del SGS en términos de los procesos de negocio, se
definirá la Política de Gestión de Servicios, de acuerdo con los procesos y actividad(es)
seleccionadas. Es la dirección quien debe establecer la política, velar por su difusión y
distribución. Esta debe estar en concordancia con el propósito y misión de la
organización. Siendo revisada cada vez que se genere un cambio.

Representante de la Dirección.
Este responsable del SGS es asignado por la dirección y tiene la responsabilidad del
sistema de gestión. Teniendo la libertad y autoridad para: Asegurar, Participar,
promover, generar, informar, elaborar, convocar y otras acciones que buscan
establecer, implementar y mantener los procesos necesarios para el correcto
funcionamiento del SGS

Gestión de la Documentación.
El proveedor del servicio debe establecer y mantener los documentos, incluyendo
registros, para garantizar una planificación, operación y control efectivos del SGS.
Deberá incluir como principales elementos: declaración documentada de las políticas
de gestión de servicios, los SLA acordados con los clientes, planes de la gestión de
servicios y procedimientos generales o de gestión.
Competencia, concientización y formación.
Se debe determinar y proporcionar los recursos humanos, técnicos, de formación y
financieros necesarios para establecer, implementar y mantener el SGS. Considerando
que uno de los pilares para conseguir la provisión de servicios de calidad es disponer
del personal con las competencias necesarias para las tareas que desarrollan, en
función de su educación, formación, habilidades y experiencias. Sin duda alguna, la
responsabilidad por conducir y registrar este requisito tan vital es el responsable de
recursos humanos de la organización.

Finalmente, es de menester señalar que los tres requisitos o aspectos esenciales claves
para que la mejora de los servicios se produzca y por tanto debiesen ser el albo de
cualquier auditor son:
• La Participación y Compromiso de la Dirección en el Proceso de Cambio
(apartador de responsabilidad de la dirección)
• La Definición de la documentación del sistema de gestión (apartado de requisitos
de la documentación) y
• La importancia de la gestión de los recursos humanos para que se produzca el
cambio (apartado de competencia, concientización y formación).

2. Decidir sobre la conveniencia de incluir una no conformidad en el informe

de auditoría respecto a la ausencia de un procedimiento de control de la
documentación.

En consideración al caso planteado y teniendo presente que es una Empresa de TI, que
entrega servicios en el área de hosting y housing, a través de su Data Center. Resulta
inconcebible que, en el Proceso de Implementación, no se haya considerado un
Procedimiento de Control de Documentación. Por lo que es necesario considerar una no
conformidad, en el Informe de Auditoria.

3. Justificar, en su caso, la no conformidad anterior con la referencia o

referencias concretas de la norma que no han sido observadas por la
organización.

En el apartado alusivo al Control de la Información documentada se establece que la

información documentada requerida por el SGS, se debe controlar para asegurar que:
esté disponible y sea idónea para su uso, dónde y cuándo se necesite; la cual a su vez
debe estar protegida adecuadamente. Contra pérdida de la confidencialidad, uso
inadecuado o perdida de integridad.

Para el control de la información documentada, la organización debe haber abordado

las siguientes actividades con relación a la documentación, partiendo desde su
distribución, acceso, recuperación y uso; teniendo preocupación por su
almacenamiento y preservación; dejando registro de los controles de cambios que
ameritaban y por consiguiente procurando siempre su preservación y disposición de la
misma.

Resultes evidente que la organización no cumplió ninguna de las actividades

mencionadas, porque “no lo consideró necesario”. Argumento que no es sustentable
para una organización que busca la Certificación de la Norma. Maxime cuando la
norma por si establece que toda organización que implementa la ISO 20000 deberá
tener establecido y mantener al día, un procedimiento para controlar los documentos y
registros incluidos en su SGS, situaciones no observadas por la organización.
Ejercicio 4
Datos

Una empresa de ingeniería y fabricación de piezas para aviones tiene 250 empleados y
el siguiente organigrama:
• (1) Director general.
• (2) Director financiero.
• (3) Jefe de contabilidad.
• (3) Jefe de informática.
• (2) Director comercial.
• (2) Director marketing.
• (2) Director recursos humanos.
• (2) Director industrial.

El director general ha pedido la realización de una auditoría de sistemas de información

con el siguiente objetivo y alcance:

• Objetivo:
• Emitir una opinión sobre el entorno de control en el desarrollo e implantación
de sistemas que asegure la correcta funcionalidad de estos y la disponibilidad
de los mismos, y la fiabilidad y exactitud de la información.
• Alcance:
• Todos los sistemas que dan servicio a la compañía y usuarios externos.

La empresa tiene un departamento de proceso de datos compuesto por 6 personas:

• 2 Analistas programadores.
• 2 Programadores.
• 1 Responsable de seguridad.
• 1 Técnico de sistemas.

Existen cuatro servidores de aplicaciones:

• Servidor (General 01):

• Sistema operativo Windows 2008.
• Base de datos SQL-SERVER.
• Aplicaciones desarrolladas internamente:
• Contabilidad; financiero; comercial; marketing.
• Acceso mediante modelo Cliente/Servidor.
• Aplicaciones desarrolladas en .NET.

• Servidor (General 02):

• Sistema operativo Windows 2008.
• Base de datos SQL-SERVER.
• Aplicaciones desarrolladas internamente:
• Industrial: acceso mediante Terminal Server, aplicaciones desarrolladas en
.NET, alojadas en el Servidor.

• Servidor (General 03):

• Sistema operativo Windows 2008.
• Aplicación de correo electrónico Exchange 2007.
 • Servidor (General 04):
• Sistema operativo Windows 2008.
• Servidor WEB (IIS).
• Servidor de base de datos SQL-SERVER.
• Con acceso al Servidor (General 02).
• Servicio de acceso de clientes a la extranet.

Equipo cortafuegos de la Red.

200 equipos PC individuales con acceso a las aplicaciones.

La información recogida en la etapa preliminar de esta auditoría, mediante la revisión

de documentación y entrevistas, ha sido:

• Existe un procedimiento formal:

• Copias de seguridad diarias.
• Documentación del sistema operativo y parches actualizados.
• Documento de solicitudes de cambio que rellena el analista.

• El administrador de seguridad:
• Realiza el alta de usuarios en los distintos sistemas.
• Actualiza las aplicaciones que los analistas entregan para puesta en
producción.
• Actualiza los sistemas operativos y los parches.
• Conexiones ODBC para Cliente/Servidor.

• No realizan:
• Auditorias de sistemas de información.
• Archivado de las solicitudes de cambios.
• Análisis coste/beneficio de las solicitudes.

• No cuentan con:
• Políticas organizativas para sistemas de información.
• Plan para cambios de emergencia.
• Entorno separado para desarrollo.
• Proceso formal de implantación de parches.
• Estudio de impacto en las solicitudes.

En el plan de prioridades para realizar solicitudes:

• Se han dado de alta:

• Aplicaciones desarrolladas en ACCESS, por el departamento de marketing con
acceso en lectura y escritura vía ODBC, accediendo, modificando y dando de
baja a registros de clientes de comercial.

• Se revisa periódicamente:
• Actualizaciones de los sistemas operativos y del software de desarrollo.

• Cualquier proyecto nuevo:

• Es encargado al analista y este lo documenta y desarrolla según el orden de
solicitud.
Se pide:

1. Un informe de riesgos potenciales detectados, indicando el impacto de estos riesgos en la entidad, según sus
objetivos de negocio.

# Riesgo Impacto en En Detalle

Entidad
• Desconocimiento de situación actual de la organización y existencia de brechas, que permiten abordar
acciones necesarias para la protección de la información confidencial, sistemas críticos, y gestión de la
Daño a la
confidencialidad.
Empresa y
No realización de • No contar con una evaluación periódica para exponer el estado de la organización. Que permita realizar
Marca,
1 Auditorias de Sistemas de las mejoras y acciones correspondientes frente a los riesgos, amenazas y vulnerabilidades.
Interrupción del
Información • No permite generar y estructurar un apropiado plan de riesgos y considerar la incorporación de
Negocio y
controles internos y controles generales.
Fraude.
• Alta exposición a fraudes, robos de datos, ataques, accesos no autorizados, fallos en la operación,
ciberataques, etc.
No se consideran en las
Interrupción del • Al no contar las solicitudes con análisis de costo-beneficio se pierde la visibilidad del cambio.
solicitudes de Cambio el
negocio, Desconocimiento de impacto para el negocio en sistemas críticos.
2 análisis costo-beneficio y
Incrementos de • No se realizar un proceso de evaluación de riesgo, de manera de poder tratar los riesgos y ver como
el impacto de dichos
Costos proceder frente a los eventuales impactos.
cambios
Las solicitudes de Cambio • No se puede realizar seguimientos a los cambios realizados.
Interrupción del
3 no quedan registradas • No se tiene la visibilidad, en cuanto a que las solicitudes hayan sido abordadas previamente. No
Negocio
(archivado) sabiendo si estas solicitudes apuntan a acciones correctivas o nuevas funcionalidades.
No se tiene definido ni
Interrupción del • Al no tener política no se tienen control de los accesos, normas, procedimientos, etc. Por lo que no se
establecido políticas
4 Negocio, Delito tienen definiciones establecidas.
organizacionales para los
Informático • No se puede realizar una gestión centralizada a no disponer de herramientas-políticas.
sistemas de información
Interrupción del • No es posible responder a situaciones no prevista o de emergencia. No hay controles de cambio y el
No se cuenta con un Plan Negocio, Daño a impacto que estos pueden generar en los ambientes productivos.
5
de Cambio Emergencia la Empresa y • Gastos innecesarios ante la necesidad de atender cambios de emergencia, pero sin un apropiado plan,
marca previamente revisado y probados.
Interrupciones
No se tiene Ambientes de Servicio • Fugas y Robos de información, ante accesos facilitados por entornos mixtos
declarados, separados de: (Virus, Malware, • Interrupciones en la operación dado posibles “pasos involuntarios” hacia Producción, al no tener
6
Desarrollo – Testing - QA Hacking), ambientes separados y procedimientos para estos
- Producción Inconsistencia de • Inconsistencia de Programas en los distintos ambientes. Información disponible puede no ser fiable.
Información.
Interrupción del
No se cuenta con un • Fallos en Sistemas Empresariales, sin opciones de recuperación inmediata, afectando la operación y
Negocio, Daño a
7 Proceso/Procedimiento de continuidad operativa del negocio.
la Empresa y
aplicación de Parches • Ausencia de Plan de recuperación/Vuelta atrás, ante fallos o ventana de tiempos agotadas.
marca
2. Un programa de auditoría, indicando los procesos según COBIT 5 a
auditar.

Descripción de actividades Cobit 5

I Gestión Inicio de Auditoria
1. Carta inicio de Auditoria
2. Recepción de notificación de inicio de auditoria
3. Carta de resguardo de la empresa
4. Carta de responsabilidad
II Obtención de Información General
Antecedentes generales para la gestión estratégica
a. Plan estratégico de TI de la Organización APO02
b. Plan informático APO02
c. Nómina de personal del Área de Desarrollo APO07
d. Procedimiento y Normas e Desarrollo APO01
e. Procedimientos de Pasos a Producción APO01
f. Planes de emergencia, contingencia y continuidad de la DSS04
información de la organización.
III. Obtención de Información específica
Antecedentes para gestión de objetivos específicos
a. Estructura funcional del área de desarrollo, APO01
herramientas, directrices y personal APO07
b. Plan informático respecto a la organización, relacionado APO02
con el área de desarrollo
c. Información de registro o software de seguimiento, BAI03
detalle de actualizaciones (desarrollos-cambios) del BAI03
área, a partir de solicitudes realizadas. MEA01
d. Procedimientos de control interno aplicados durante la DSS02
ejecución de las tareas del área de desarrollo
e. Reportes estadísticos de problemas frecuentes y DSS03
soluciones entregados a los clientes, de acuerdo con los
desarrollos (cambios solicitados)
f. Políticas y Procedimientos de solicitudes de cambios BAI06
IV Obtención de Información complementaria
a. Contrato de mantención de servicio externos APO10
b. Seguridad físicas y accesos al o los ambientes de DSS05
desarrollo
V. Procedimiento de auditoria información General
a. Comprobar la existencia del plan estratégico y su APO02
aplicación al interior del área de TI.
b. Verificar el cumplimiento de seguridad en la DSS05
autenticación de los usuarios en los ambientes de
desarrollo
c. Evaluar y validar el tiempo y nivel de respuesta del área DSS03
de desarrollo
d. Evaluar el recurso humano del área de desarrollo en APO07
base a su función y cargo
e. Verificar los recursos tecnológicos existentes utilizados BAI03
por el área de desarrollo (infraestructura, ambientes,
aplicaciones), son adecuados.
VI. Procedimiento de auditoria información especifica
a. Comprobar que exista un registro de todas las peticiones DSS02
de servicio (cambio/desarrollo, mediante la solicitud de
bitácora o registro histórico ingresos de incidentes de
desarrollo
b. Verificar la correcta aplicación de la normativa interna, en DSS02
cuanto a la clasificación de las solicitudes y/o peticiones de
servicio de cambio/desarrollo identificando tipo y categoría.
c. Verificar las peticiones de solicitudes de DSS02
modificación/desarrollo mediante los acuerdos de niveles
de servicio según impacto de tiempo y prioridad.
d. Verificar que las aplicaciones desarrollas por otras áreas BAI01
cumplen con los estándares y procedimientos del Área de
TI
e. Las aplicaciones desarrolladas cumplen con necesidades de BAI02
la organización.
f. Verificar qué los cambios de emergencia son documentos y BAI06
controlados adecuadamente.
g. Evaluar la suficiencia de los recursos de TI del área de BAI03
desarrollo.
h. Confirmar la existencia de planes de respaldo de los DSS01
ambientes de desarrollo
VII. Procedimiento de auditoria información complementaria
a. Verificar los procedimientos de manejo de documentos DSS05
electrónicos.
b. Revisión de informes de auditorías anteriores MEA02
VII. Procedimiento de auditoria información complementaria
Preparación Informe Preliminar
1. Objetivo General
2. Objetivos específicos
3. Alcance de la Auditoria
4. Metodología aplicada
5. Opinión general
3. Diseñar las pruebas a realizar (objetivo y alcance).
# Prueba
Revisar Plan Estratégico y validar el
P01
grado de aplicación en Área de TI
Verificar la aplicación de definiciones,
P02 acuerdos y compromisos de TI, con la
Dirección de la Organización
Validar Políticas para la Gestión TI y que
P03
las mismas se encuentren vigentes
Verificar la existencia de una Estructura
P04 Organizacional con roles,
responsabilidades y dependencias en TI
Comprobar la Integridad y completitud
P05 de datos usados en los flujos
organizacionales
Validar que el Procedimiento de Gestión
P06 de Usuarios y Gestión de Ambiente, sea
aplicado.
Revisar Política y aplicabilidad del
P07 Procedimiento de Desarrollo de
Aplicaciones
Validar el cumplimiento de la Políticas de
P08 Seguridad, en cuanto a su uso en los
Ambientes y Sistemas Productivos.
Objetivo
Tomar conocimiento del Plan, haciendo
seguimiento a que el mismo haya sido
aplicado, de acuerdo con los
compromisos establecidos. Diferencia
entre lo realizado y lo planificado
Determinar el grado de cumplimiento
de los temas tecnológicos y seguridad
de TI. Enmendar omisiones que se
hayan cometidos
Tomar conocimiento, si las Políticas
que se han elaborado para la gestión
de TI, se encuentran actualizadas para
dar respuestas a las necesidades de la
organización.
Determinar la existencia de esta
definición, la cual debe estar plasmada
en un documento conocido por la
organización.
Confirmar que los datos se encuentren
donde corresponda para su
correspondiente uso y tratamiento por
parte de la organización
Tomar conocimiento del Procedimiento
de Gestión de Usuarios y de
Ambientes. A fin de determinar su
apropiada utilización; evidenciada en
registros y documentos de respaldo.
Asegurar que el Procedimiento de
Desarrollo en conocido y utilizado por
los Equipos de Desarrollo. Verificando
su utilización y la adecuada
capacitación para internalizar las
mejores prácticas y metodologías.
Obtener la evidencia que denote el
grado de cumplimiento de la Seguridad
de la Información en los Ambientes.
Proceso
Alcance
COBIT
Determinar grado de aplicabilidad del Plan y la
gestión de los recursos del área; con la
estrategias y prioridades del negocio APO02
establecidas. La validación debe realizarse vía
entrevista y revisión de documentación existente.
Revisión de Actas de Reuniones del Área Ti con
Dirección, del último período, asociada a temas APO01
de tecnología. Seguridad física y lógica
Evaluar la eficiencia de las políticas elaboradas
para la gestión, administración y recursos de TI y
APO01
que las mismas se encuentran fines a la
organización
Solicitar la definición de los perfiles de cargo del
personal de TI. Permitiendo determinar si la
misma es conocida por los colaboradores; así APO01
como si la misma se adecua a las necesidades de
la organización
Validar la adecuada existencia y calidad de los
controles de Datos. De manera que los mismos
sean autorizados, completos y exactos; para DSS06
asegurar el cumplimento del flujo definido por la
organización.
Solicitar la Política de Seguridad de TI que debe
considerar, los Procedimientos en los cuales se
sustentas. A saber: Alta, modificación y baja de APO13, BAI03
Usuarios; Separación de Ambientes y Pasos a
Ambiente Productivo.
Verificar y validar el Procedimiento, el cual debe
contener todos los Ciclos de Vida de los
BAI03
Aplicativos. Debe considerar las normas de las
mejoras prácticas y metodologías utilizadas
Solicitar la Pautas de trabajo, Formularios,
Niveles de autorización, esquema administrativo
de trabajo, formularios, niveles de autorización y BAI03
flujo de información de los aplicativos que se
encuentran en Ambiente Productivo.
# Prueba
Verificar y comprobar el cumplimiento d
de los niveles de acceso y seguridad de
P09
los Ambientes: Desarrollo, QA, Testing,
Producción.
Validar el Procedimiento de Control de
P10
Cambio y su uso.
Verificar y validar la existencia de un
P11 registro de Solicitudes de Modificación
de Aplicaciones
Validar que las piezas-componente de
P12 Software y Aplicativos cumplen con los
objetivos del Negocio.
Verificar los resultados y acciones
correctivas, consideradas y levantadas a
P13
partir de las Pruebas de Continuidad de
TI realizadas.
Objetivo
Asegurar que las Políticas de Seguridad
para control de accesos a Ambientes y
Sistemas estén operativos de acuerdo
a lo establecido.
Certificar que el Procedimiento de
Control de Cambio se cumpla en todas
en todas sus etapas y que es conocido
por partes interesadas
Tomar conocimiento si los eventos e
incidentes asociados a los aplicativos
son registrados.
Verificar si existe algún registro
(formulario) de Solicitudes de
Modificación y/o Desarrollo de nuevas
Aplicaciones por parte de los usuarios
funcionales del negocio.
Hay que asegurar que el Plan de
Continuidad de Negocio, contiene las
observaciones encontradas durante las
Pruebas de TI realizadas
Alcance Proceso COBIT
Con la información de Control de Accesos a los
APO01, BAI03,
Sistemas y aplicativos, se debe realizar una
APO13, DSS05
muestra de acceso aleatorio a los Ambiente.
El Procedimiento debe cubrir todas las APO01, APO06,
necesidades de Cambio que requiere la APO12, BAI06,
organización: Código Fuente, Aplicativos, Bases BAI07, DSS01,
de Datos, Infraestructura DSS05
El Sistema de Registro, debe evidenciar los
errores presentados y levantado por los usuarios;
APO01,
de manera de poder validar qué % de estos
APO011, BAI03
incidentes implican modificaciones o nuevos
desarrollos y si los mismos son abordados
Se deben verificar los registros existentes, a fin
de determinar si la Solicitudes realizadas al Área
de Desarrollo de TI, corresponden a las APO02, APO11,
necesidades del negocio y si ellas cumplen con BAI01, BAI02,
los objetivos planteados. Lo que debe estar BAI03, BAI06
plasmado en la conformidad dada por el usuario
en la Solicitud.
Se deben verificar si las estrategias de
Continuidad y Disponibilidad de los Sistemas DSS04;
críticos TI para la operación de la organización, se APO12;
encuentran actualizados. Siendo que estos son MEA01; MEA02
parte del Plan de Continuidad del Negocio
Ejercicio 5
Datos

La serie de fallos en los negocios que empezaron con Enron a finales de 2001 pusieron
de manifiesto serias debilidades en el sistema de contabilidad y auditoría que
intentaban proteger los intereses de los accionistas, beneficiarios de planes de
pensiones y empleados de compañías públicas —y proteger la confianza del público
general—.

Por ello, el 30 de julio de 2002, fue promulgada una ley para proteger a los inversores
mejorando la exactitud y la confianza de los informes y comunicaciones corporativas
realizadas cumpliendo con las leyes financieras y otros propósitos, denominada SOX
(Sarbanes Oxley).

El ámbito de aplicación de la ley son todas aquellas empresas cuyos valores, acciones
y obligaciones coticen en Wall Street.
Interpretada y reglamentada por la SEC (Securities and Exchange Commission) y el
PCAOB (Public Company Accounting Oversight Board), dispone de varias secciones en-
tre las que destacan:

• Sección 302. Corporate responsibility for financial reports: requiere que el conse-
jero delegado y el director financiero certifiquen trimestral y anualmente que el
control interno de la entidad es efectivo.
• Sección 404. Management assessment of internal controls: requiere que
anualmente la Dirección prepare, para que lo revise y evalúe su auditor, un
informe de control interno que:
• Determine su responsabilidad en establecer y mantener una adecuada
estructura de control interno y unos adecuados procedimientos para la
elaboración en tiempo, forma y contenido de la información financiera de la
sociedad.
• Contenga una evaluación de la efectividad de la estructura de control interno y
los procedimientos.

Una empresa que cotiza en la Bolsa de Nueva York se ha planteado implantar un

sistema IT GRC que permita unificar esfuerzos a la hora de garantizar los objetivos de
negocio, dar cumplimiento a la totalidad de regulaciones a las que están sometidos, y
en definitiva mejorar las prácticas de gobierno y de gestión de riesgo.

Después de un breve análisis, la mayor preocupación de la Dirección son los siguientes

elementos:

• Entorno de control de IT.

• Controles generales de IT.
• Controles automáticos.
• Procesos externalizados.
• Hojas de cálculo y bases de datos de usuarios.
Se pide

1. Indicar al menos 5 motivos por los que las tecnologías de la información

son importantes a la hora de implantar un sistema IT GRC.

Entre los motivos podemos citar lo siguientes:

• La mayoría de los datos que soportan el modelo de GRC residen en aplicaciones
tecnológicas.
• La incorporación de las tecnologías de información permite transformar los
datos en información poderosa para la toma de decisiones y monitorear su
comportamiento con indicadores de riesgo.
• Las tecnologías de información permiten sustentar el cumplimiento de las leyes,
regulaciones, estándares y políticas.
• La utilización extensiva de las tecnologías de información nos entrega (provee)
información de alta calidad para un gobierno corporativos y administración del
riesgo efectivo.
• Nos permite disminuir el impacto e implicancias de los aspectos de
gobernabilidad, administración de riesgo y cumplimiento.
• Al utilizar las tecnologías de información se pueden gestionar de una forma más
oportuna y eficaz los riesgos en materia de seguridad de la información.

En definitiva, todos ellos considerando el grado de dominancia que poseen las

tecnologías de información en las organizaciones, las hacen tener un rol centran en la
implantación de un sistema IT GRC.

2. Definir los controles internos que diseñaría para aplicar al entorno de

control IT y los controles generales de IT que aplicaría.

El control Interno en COBIT es definido como las políticas, procedimientos, prácticas y

estructuras organizacionales diseñadas para brindar la garantía razonable de que los
objetivos de negocio se alcanzarán y de que los eventos indeseables serán prevenidos
o detectados y corregidos.

En base a esta definición, los controles internos por considerar serían los siguientes:
1. Comprobar si se dispone de una política de seguridad de la información,
aprobada por la Dirección, comunicada a todo el personal de la organización.
2. Comprobar si la Organización ha establecido un mecanismo de
identificación/autenticación para los sistemas de información, que proporcione
responsabilidad individual (cuentas individuales por usuario).
3. Comprobar si la organización ha definido controles de autenticación basados en
la existencia de contraseñas.
4. Comprobar si existen controles para garantizar que las altas, bajas y
modificaciones de usuarios se gestionan de manera oportuna para reducir el
riesgo de accesos no autorizados o inapropiados.
5. Comprobar que la Organización dispone de programas de protección frente a
códigos maliciosos (virus, troyanos, escaneo de información).
6. Comprobar si la Organización ha establecido controles para garantizar que los
cambios/desarrollos realizados sobre los sistemas son aprobados por los
responsables del departamento al que va dirigido la modificación, una vez han
sido probados.
7. Comprobar si Organización ha implementado controles para garantizar que los
cambios de emergencia se realizan de forma adecuada y controlada.
 8. Comprobar si la Organización dispone de procedimientos para evaluar cómo
afectan los nuevos desarrollos o la adquisición de paquetes de software que se
realizan, al funcionamiento habitual de los sistemas de información,
considerando el impacto en los procesos de negocio y la información generada.
9. Comprobar si la Organización prueba las copias de seguridad de forma periódica
para asegurarse de que son utilizables en caso de emergencia.
10. Comprobar si la Organización ha implementado controles para garantizar que
las incidencias de integridad de datos y de control de accesos son registradas,
analizadas, resueltas oportunamente y reportadas a la Dirección.
11. Comprobar si la Organización ha establecido controles sobre documentos de
usuario importantes, como hojas de cálculo, que intervienen en la elaboración
de la información financiera.

Por otra parte, los Controles Generales a ser desplegados serían los siguientes:

1. Establecer monitoreos sobre la plataforma, aplicaciones-sistemas y bases de

datos que no hayan sido considerados por las Gerencias respectivas para su
utilización laboral. Para evitar mantener conexiones activas que pueden ser
puntos de entradas no deseados o accesos vulnerables.
2. Establecer monitoreos y controles sobre el equipamiento EndPoint (PC,
Notebook y otros) que se encuentra conectados a la red corporativa, para
validar que disponen de una adecuada instalación y configuración dentro de la
plataforma de protección para EndPoint, levantándose las alertas
correspondientes y/o desconexiones de la plataforma cuando esto no se
presente (Antivirus, bloqueos de puertos USB).
3. Establecer rutinas de desconexión (logoff) de la Red, Plataforma, Sistemas,
Aplicaciones, Sistemas de Remotas; antes tiempos de inactividad. Lo que
implica habilitar y establecer dichos tiempos de desconexión y comunicarlos a la
organización.
4. Establecer un proceso automático de validación y verificación de los usuarios
activos-inactivos. De manera que los usuarios inactivos que cumplan la
condición de no pertenecer ya a la organización, sus cuentas sean dadas de
bajas de todos los Sistemas (RRHH-TI)
5. Establecer cambios de contraseña en forma periódicas a las plataformas
tecnológicas provistas por la organización (Redes, Sistemas, Aplicaciones
Corporativas). Proveyendo herramientas que facilitan la interacción con varios
accesos con una sola instancia de identificación-autenticación única (Single
Sign-On). Dichos cambios y utilización de contraseñas deben ser consecuentes
con las establecidas en el Procedimiento de Cambio y utilización de
Contraseñas.
6. Establecer un proceso de monitoreo y control de las cuentas de superusuario
(root) en transacciones y ejecución de procesos, que nos alerten sobre cambios
no autorizados o que hayan sido informados debidamente; de acuerdo con los
procedimientos establecidos.
.
3. Diseñar al menos 10 controles internos necesarios para el resto de los
elementos de preocupación de las partes interesadas de la organización.

Los Controles por considerar son los siguientes:

1. Revisar los contratos aplicables para asegurar que se identifiquen

adecuadamente todos los productos entregables. Requisitos y responsabilidades
pertinentes al compromiso de la empresa.
2. Revisar y evaluar el proceso utilizado para seleccionar al proveedor, al cual se
le externalizaran los procesos.
3. Revisar y evaluar como los datos, se encuentra segregados de los datos de
otros clientes.
4. Verificar que los datos que eventualmente se encuentren almacenados en las
ubicaciones del Proveedor estén protegidos de acuerdo con las políticas de la
empresa (mandante).
5. Determinar cómo el cumplimiento de las leyes de privacidad aplicables y
eventualmente otras regulaciones es asegurado.
6. Revisar y evaluar los procesos de la empresa para monitorear la calidad de los
servicios-procesos externalizados (cumplimientos de SLA, Disponibilidad, etc.)
7. Revisar y evaluar los planes existentes, en caso de un término esperado o
inesperado de la relación contractual con proveedor (mandatario)
8. Verificar si existen aplicaciones (hojas de cálculo y bases de datos) de usuarios
que respalden procesos de negocios importantes y/o informes financieros.
9. La integridad lógica de las aplicaciones de usuarios críticas debe ser evaluada, a
fin de sentar las bases adecuadas de funcionalidad de las aplicaciones
existentes.
10. Considerar la reconstrucción de aplicaciones de usuarios críticas, incorporando
controles en las mismas aplicaciones y las mejoras prácticas en el uso de las
mismas.