# Año Observación

1 2015 Observaciones en la documentación de los procedimientos del Grupo Gloria.

(1) Las políticas y procedimientos no han sido actualizadas.
(2) El organigrama no ha sido actualizado.
(3) No se cuenta con políticas de revisión de logs.
(4) No se cuenta con revisiones sobre la adecuada ejecución del bloqueo de cuentas de usuarios
inactivas, a fin de verificar que todo el personal que no ha iniciado sesión en más de 45/90 días y en
coordinación con la jefatura del área sean bloqueadas/eliminadas en el sistema oportunamente.
(5) No se cuenta con una aprobación formal del área de seguridad donde se evidencie la revisión de
los accesos que se asignan/restringen a los usuarios.
(6) No se cuenta con un organigrama actualizado según las personas que actualmente pertenecen al
área de sistemas del Grupo.

2 2016 No se cuenta con un procedimiento de modificación de accesos por movimientos de personal.

A partir de nuestro entendimiento de lo procedimientos de la gestión de Accesos,
en especifico, en la revisión de modificación de cuentas por movimiento de personal.
Identificamos que la modificación de cuentas no tiene un procedimiento establecido y difundido a los
usuarios de negocio, debido que los usuarios al cambiar de área o empresa (sociedad) no informan a
mesa de ayuda o seguridad de la información para el retiro de los accesos o cese de la cuenta anterior.
Ante la situación presentada, podemos identificar el posible riesgo de accesos no autorizados a la
información del negocio, accesos no correspondientes al cargo actual del usuario o posibles conflictos
de segregación de funciones. Por lo cual, recomendamos al negocio definir un procedimiento formal y
difundirlo a los usuarios para su concientización. Como también, establecer controles automático para
el posible bloqueo de cuentas que hayan sido modificadas por cargo, sociedad o área.

3 2015 Se identificó que no se ha definido un control de monitoreo de cuentas privilegiadas del sistema
SAP.
Esta situación incrementa el riesgo de accesos no autorizados sin ser detectados.
Se recomienda evaluar la posibilidad de implementar un control de monitoreo.
Las cuentas de usuarios con perfil SAP_ALL: DDIC, SAP* y USRCPIC
Las cuentas de usuarios que se les asignó SAP_ALL udrante el 2016: ASANCHEZ y SOPORTE01
Las cuentas de usuarios con acceso a un amplio rango de transacciones:
CJARA, RSANCHEZC, JSANCHEZC, AZAVALA, LNOVOA, ASANCHEZ, BASIS_TDP, ATANIGUCHI, LDIAZM,
MCOLINA, LVALENCIA, JCARDENASD, ACOASACA, VCURO, JDELACRUZI, SAP*, DDIC, MMOSCOSOA,
JBENAVIDES y
JPINO
4 2015 Observaciones en la configuración general de seguridad de SAP
1.- Se Identificó un total de 423 usuarios con acceso a ejecutar programas de forma directa desde la
opción “System status” y sobrepasar la verificación del acceso a transacciones con la habilidad
S_DEVELOP. Entre dichos usuarios, se encuentran usuarios funcionales de negocio.
Esta situación incrementa el riesgo de accesos a funciones no autorizadas en el sistema mediante
evasión de verificación de acceso a la transacción.
Se recomienda restringir el acceso de sobrepasar la verificación del acceso a la transacción con la
habilidad S_DEVELOP solo al personal autorizado
2.- Se Identificó un total de 20 usuarios con acceso a ejecutar programas de forma directa desde la
opción “System status” y sobrepasar la verificación del acceso a transacciones con la habilidad
S_DEVELOP. Entre dichos usuarios, se encuentran usuarios funcionales de negocio.
Esta situación incrementa el riesgo de accesos a funciones no autorizadas en el sistema mediante
evasión de verificación de acceso a la transacción.
Se recomienda restringir el acceso de sobrepasar la verificación del acceso a la transacción con la
habilidad S_DEVELOP solo al personal autorizado
3.- Se encontró:
- 645 usuarios con acceso a ejecutar Jobs a nombre de otro usuario.
- 642 usuarios con acceso a procesar Batch imput a nombre de otro usuario.
Esta situación incrementa el riesgo de ejecución de Jobs y Batch imputs no autorizados en SAP.
Se recomienda restringir el acceso a ingresar y ejecutar procesos en lote y batch inputs con el uso de
otro usuario en el sistema.
4.- Verificamos que existen muchos usuarios con acceso a ejecutar commandos de BD desde SAP.
5.- Identificamos 2592 usuarios que tienen asignados los objetos de autorización. S_RFC y/o
S_RFCACL los cuales permiten ejecutar conexiones RFC. Esta situación incrementa el riesgo de
actividades no autorizadas en SAP a través de conexiones remotas.
Se recomienda configurar usuarios RFC de manera que estos no sean de tipo dialogo.

5 2015 Observaciones en la documentación de modificación y ceses de usuarios.

A. Para el caso de la asignación de perfil para la cuenta SPRINCIPE, identificamos que la fecha de
modificación (28.05) se realizó antes de la autorización respectivo. Esta autorización se registro en el
Formato F009 cuya fecha es 30.06.
B. De una muestra de 15 asignaciones de accesos, identificamos que 10 casos de asignación no
cuentan con la aprobación de Antonio Díaz - Jefe de Seguridad de Información, lo cual no se alinea al
procedimiento de altas de la entidad.
C. De una muestra de 15 asignaciones de accesos, identificamos que 5 casos de asignación fueron
atendidos por los Analistas de Segurida de Información, y luego se solicito la creación del ticket de
atención. Esto evidencia no se alinea al procedimiento establecido por la entidad.
 A. En la revisión de la cuenta LFLORESB, identificamos que fue cesada por RRHH el 16.03, sin embargo
no se identificó el bloqueo respectivo y fue borrado luego de 29 días por el área de Seguridad de la
Información. Al revisar los posibles motivos del retraso, identificamos que el Job automático que
informa sobre los ceses realizados en el día por RRHH no indicó el cese del usuario LFLORESB, por lo
cual, se evidencio que el cese no se realizó en el tiempo oportuno por la inefectividad del job.

Update testing

A. De una muestra de 10 asignaciones de accesos, identificamos que 3 casos de asignación no cuentan

con la aprobación de Antonio Díaz - Jefe de Seguridad de Información, lo cual no se alinea al
procedimiento de altas de la entidad.
B. Para el caso de la asignación de perfil para la cuenta CRODRIGUEZH, identificamos que no se creo el
ticket de atención por mesa de ayuda sin embargo se brindo la atención. Esto evidencia que no se
cumple el procedimiento establecido por la entidad.
C. De una muestra de 10 asignaciones de accesos, identificamos que 7 casos de asignación fueron
atendidos por los Analistas de Segurida de Información, y luego se solicito la creación del ticket de
atención. Esto evidencia no se alinea al procedimiento establecido por la entidad.

Update testing
A. La cuenta FROJAS del usuario ROJAS BONILLA FELIX RENZO fue cesado en el sistema el 16.08 y el
área de Seguridad de Información realizo el borrado el 24.08, lo cual indica que hubo un retraso de 8
días y la cuenta estuvo vigente. Cabe indicar que la cuenta no fue bloqueada.

6 2015 Observaciones en la configuración de seguridad de los sistemas operativos HPUX

Para el servidor glsapap3: se identificó 28 usuarios cuya contraseña se encuentra encriptada y esta
almacenada en el archivo \etc\ passwd.
Para el servidor glsapdba: se identificó 30 usuarios cuya contraseña se encuentra encriptada y esta
almacenada en el archivo \etc\ passwd.
Dicha situación incrementa el riesgo de vulnerabilidad de contraseñas por parte de personal no
autorizado.
Se recomienda almacenar las contraseñas encriptadas en el archivo /etc/shadow.

7 2015 Cambios a programas sin conformidad de los usuarios de negocio previo al pase a producción
Se identifició que las ordenes de transporte DEVK9A2YUM y DEVK9A2Z46 no contaron con una
conformidad por parte de los usuarios de negocio previo al pase a producción.
Este hecho se encuentra asociado al riesgo de posibles pases a producción no autorizados
Se recomienda evaluar la posibilidad de reforzar el cumplimiento de la fase de certificación por parte
de los usuarios de negocio con el fin de minimizar el riesgo identificado.
8 2015 Observaciones en los accesos a realizar cambios directos a los programas y datos

1. Se identificó que los usuarios HSAJAMI y SOPORTE05 no se encuentran autorizado a modificar la

protección del mandante ( ambiente de datos) de producción de SAP.
Dicha situación incrementa el riesgo de cambios no autorizados en la protección del mandante del
sistema.
Se recomienda quitar dichas facultades a esos usuarios.

2. Se identificó que el usuario SOPORTE05 no se encuentra autorizado a modificar la protección del

mandante y hacer customizing en el sistema de producción.
Dicha situación incrementa el riesgo de cambios no autorizados en el sistema.
Se recomienda quitar dichas facultades a esos usuarios.

3. Se identificó que el usuario ASANCHEZ presenta un conflicto de segregación de funciones ya que

cuenta con llave desarrollador y puede modificar la protección del mandante y puede realizar
modificaciones en la configuración del sistema.
Dicha situación incrementa el riesgo de cambios no autorizados en el sistema.
Se recomienda tener dichas funciones segregadas.

9 2015 No se cuenta con un estándar formalmente establecido para la descripción de los órdenes de
transporte

10 2015 Observaciones en los accesos a administrar procesos

Se identificó que 14 usuarios cuentan con acceso no autorizado a administrar procesos en el sistema
SAP

Se identificó que 23 usuarios cuentan con acceso a bloquear datos que son actualizados por otros
usuarios.

Se identificó que más de 600 usuarios cuentan con acceso a administrar, liberar y eliminar procesos
job de fondo.

Se identificó que 141 usuarios cuentan con acceso no autorizado a configurar archivos del sistema SAP.

El riesgo es de naturaleza operativa y no representa riesgo para la información de estados financieros.

Recomendación: Se recomienda restringir los privilegios sólo a personas autorizadas.

11 2015 Observaciones en la configuración de los Sistemas Operativos Windows Server (Directorio activo
que controla el acceso a la red interna de la compañía)

1: Se identificó que el parámetro AuditBaseObjects en la llave de registro

HKLM\SYSTEM\CurrentControlSet\Control\Lsa se encuentra establecido con el valor de 1, lo cual no
está acorde a las buenas prácticas.
Dicha configuración incrementa el riesgo de la generación de un gran número de eventos de
seguridad, lo cual puede causar que los servidores respondan lentamente y fuercen el registro de
seguridad para grabar numerosos eventos de poca importancia.
Se recomienda establecer el parámetro AuditBaseObjects con el valor de 0.

2: Luego de la revisión de los usuarios en el servidor se identificó lo siguiente:

• Existen 112 usuarios que nunca se han logueado.
• Existen 267 usuarios que no se han logueado por más de 105 días.
• Existen 350 usuarios con contraseñas que no expiran.
• Existen 428 contraseñas que no han sido cambiadas en más de seis meses
Dicha situación incrementa el riesgo que usuarios malintencionados puedan acceder con mayor
facilidad al directorio activo.
Se recomienda realizar un monitoreo sobre los usuarios del directorio activo.

12 2016 Ausencia de documentación sobre los acuerdos en las reuniones mensuales - Telefónica

En nuestra revisión de auditoría sobre el monitoreo de los servicios tercerizados, identificamos que se
realizan reuniones mensuales con el equipo de Telefónica y los acuerdos se registran en Actas de
Reunión. Sin embargo, en el caso de Setiembre 2016, no se evidenció el acta de acuerdos de la
reunión sostenida.
El presente caso demuestra la ausencia de no contar con el adecuado seguimiento sobre los servicios
prestados por Telefónica, y por ello, no garantizar el cumplimiento de los indicadores de los servicios.
Recomendamos poder registrar los acuerdos en un acta de reunión como también en una bitácora de
proyectos o servicios prestados para realizar un adecuado seguimiento por parte de Gloria.
Adicionalmente, almacenar los reportes, actas y otros documentos sustentarios en un repositorio de
información.
Procedimiento Adicional
(1) y (2) Estas debilidades no representan un riesgo para nuestro enfoque dado que se cuenta con otros controles
implementados por la compañía que responden al riesgo, asimismo el procedimiento que sigue la compañía para
los diferentes procesos se encuentran implementados correctamente.
(3) En la revisión de Basis se ha revisado los logs de las cuentas privilegiadas, las cuales representan el mayor
riesgo por los accesos que cuentan, como resultado no encontramos ocurrencia de accesos no autorizados. Así
mismo se revisó que las cuentas tengan los accesos acorde a las funciones que desempeñan en la compañía.
(4) Se revisará las bajas oportunas del SAP en el ega de ceses, en estos se detallaran los procedimientos
adicionales en caso no se haya efectuado oportunamente. Ver: APD002 - Los usuarios cesados son eliminados
oportunamente.
(5) Se revisará en el testing de modificaciones que sólo usuarios autorizados, es decir del área de seguridad de la
información hayan modificado perfiles de usuarios, ya que esta área tiene a cargo la evaluación de la factibilidad
(se encuentra autorizado, con el formato debidamente aprobado, no generaría un conflicto SOD). Ver: APD001 -
Las solicitudes de asignación de accesos son debidamente aprobadas.
(6) La situación reportada es una oportunidad de mejora, la cual no amerita la ejecución de procedimientos
adicionales.

Si bien identificamos la posibilidad de accesos no autorizados o conflictos de segregación de funciones, como

parte de nuestra auditoría, revisamos los accesos restringidos a transacciones críticas de los principales procesos
de negocio , y en los casos en que se encontraron accesos no autorizados o conflictos SoD se revisaron logs y se
verificó que no se presentaron accesos o transacciones no autorizadas.
Asimismo, como parte del proceso de asignación de accesos el equipo de seguridad verifica la asignación de
acceso podría representar un conflicto SoD o un acceso no autorizado, ellos son finalmente los responsables de
asignar los accesos

Para los usuarios con altos privilegios identificados, revisamos los siguientes logs:
- Change Document Summary Analysis.
- Posting Creatio Analysis.
- E0070 y TPLOG
1. Para ejecutar un programa de manera no autorizada se debe conocer la opción de system status, así como se
debe saber el ID del programa el cual debe ser ejecutable. Asimismo para ejecutar un programa además del
acceso a la transacción el SAP valida los objetos de autorización.
Revisamos con apoyo del log de las pruebas ACE y verificamos que ninguno de los usuarios ha ejecutado las
transacciones relacionadas a la habilidad S_DEVELOP.
Adicionalmente, se extrajó el log de contabilización; y sobre las transacciones que hayan venido de
transacciones Zetas e Ys se verifico que hayan sido realizadas por usuarios autorizados.
2. Para ejecutar un programa de manera no autorizada se debe conocer el acceso a la transacción con la
habilidad S_PROGRAM, así como se debe saber el ID del programa el cual debe ser ejecutable.
Se reviso el transaction log y se verificó que no se ha utilizado las siguientes transacciones: EWFM, EWFZ o SA38.
Adicionalmente, se extrajó el log de contabilización; y sobre las transacciones que hayan venido de
transacciones Zetas e Ys se verifico que hayan sido realizadas por usuarios autorizados.
3. Se procedió a descargar la tabla TBTCP y se identifico que hubó 61 usuarios en el periodo de revisión que
ejecutaron jobs con privilegios de otros.
Sin embargo, se identificó que los jobs son en su mayoría de tipo mensajes (ACTFIN), relacionados a bloqueos o
de programación de las áreas de logística y despacho.
Cabe mencionar que para poder ejecutar un programa a nombre de otro usuario, debe conocer el ID del
programa y el ID del usuario que tienen los privilegios para ejecutar dicho programa, lo cual incrementa la
complejidad para ejecutar dicho tipo de operación.
4. Con apoyo de los archivos QJF procedimos a revisar los reportes ACETLD, y comprobamos que no se ha
ejecutado el programa RSDU_EXEC_SQLen el periodo de revisión.
5. Se identificó que de los usuarios identificados con acceso no autorizado no tienen acceso al host de
producción.

A. Si bien la autorización mediante el formato F009 se realizó en una fecha posterior a la fecha de asignación del
acceso, identificamos que el flujo cumple con las autorizaciones correspondientes, es decir, cumple con la
autorización de Mercedes Loaiza Robles - Superintendente de Planta Trupal y Antonio Díaz - Jefe de Seguridad de
la Información. Cabe indicar que este caso fue regularizado.
B. Si bien verificamos que en 10 casos no se contó con la autorización del Jefe de Seguridad de Información,
identificamos que estos fueron solicitados por una necesidad del negocio y cuentan con la aprobación de la
gerencia respectiva, como también la aplicación o asignación del acceso lo realizó un miembro del área de
Seguridad de Información.
C. Si bien los 5 casos son regularizaciones para el registro de la solicitud en ticket, la solicitud como las
autorizaciones del negocio se realizaron. Cabe mencionar que estos requerimientos fueron atendidos por el área
de Seguridad de Información.
Adicionalmente a los puntos antes mencionados, es importante resaltar que los analistas de seguridad antes de
brindar/asignar los accesos solicitados, revisan el rol/perfil actual del usuario con el fin de evitar un conflicto en
la segregación de funciones. A partir de lo mencionado, no se identificó algún riesgo que impacte a la presente
auditoría.
Asimismo los analistas observan/revisan si el acceso solicitado antes de asignarlo, presentan un conflicto,
asimismo se ha observado que habian correos cuestionando los posibles conflicto SoD
Se revisó el archivo Posting Log, y se verificó que el usuario no ha tenido ocurrencia alguna.

En relación a las observaciones identificadas, podemos mencionar lo siguiente:

A. Si bien verificamos que en 3 casos no se contó con la autorización del Jefe de Seguridad de Información,
identificamos que estos fueron solicitados por una necesidad del negocio y cuentan con la aprobación de la
gerencia respectiva, como también la aplicación o asignación del acceso lo realizó un miembro del área de
Seguridad de Información.
B. Si bien no se creo un ticket de atención sobre la modificación de la cuenta CRODRIGUEZH como indica los
procedimientos de la empresa, se identificó que se cuenta con las aprobaciones correspondientes y
lamodificación es realizada por el personal autorizado.
C. Si bien los 6 casos son regularizaciones para el registro de la solicitud en ticket, la solicitud como las
autorizaciones del negocio se realizaron. Cabe mencionar que estos requerimientos fueron atendidos por el área
de Seguridad de Información.
Adicionalmente a los puntos antes mencionados, es importante resaltar que los analistas de seguridad antes de
brindar/asignar los accesos solicitados, revisan el rol/perfil actual del usuario con el fin de evitar un conflicto en
la segregación de funciones. A partir de lo mencionado, no se identificó algún riesgo que impacte a la presente
auditoría.

Se procedio a revisar el change document log y sólo se encontró al usuario en el mes de agosto (mes de cese) y la
transacción es VA02 (change sales order) la cual está autorizada a ejecutar según su función. Por otro lado,
revisamos el Posting creation log y no encontramos ocurrencia de contabilizaciones por dicho usuario en el
periodo de revisión.

En el control 8 de las revisiones técnicas se pudo identificar que los parámetros de cambio de contraseña se
encuentran de acuerdo a las buenas prácticas( tamaño de 8 caracteres y cambio cada 60 días) , reduciendo de
esta manera el riesgo de vulnerabilidad de las mismas.
Asimismo, se cuenta con restricción del acceso al sistema operativo

Se contó con la conformidad de los usuarios de negocio a modo de regularización, con lo cual se mitiga el riesgo
de que el pase a producción no se encuentre alineado a lo solicitado por personal del negocio.
DEVK9A2YUM - Cambio para liberar un pedido en el ciclo de distribución - Deprodeca y DEVK9A2Z46 - Cambio
refernte al proyecto MTO de Trupal.
1: Se verificó en el BPCC014 que la única apertura del mandante fue realizada por el usuario ASANCHEZ el 22 de
Mayo del 2016 y dicho usuario es autorizado y la apertura del mandante fue una apertura controlada.

2: Se verificó en el BPCC014 que la única apertura del mandante fue realizada por el usuario ASANCHEZ el 22 de
Mayo del 2016 y dicho usuario es autorizado y la apertura del mandante fue una apertura controlada.

3: Se verificó en el BPCC014 que la única apertura del mandante fue realizada por el usuario ASANCHEZ el 22 de
Mayo del 2016 y dicho usuario es autorizado y la apertura del mandante fue una apertura controlada.

Asimismo, no identificamos que se hay realizado cambios directos a programas en el ambiente de producción.

Se ha revisado el control de cambios a los programas, y verificado el correcto flujo de aprobación, pruebas y
aprobación para el pase a producción.

El riesgo es de naturaleza operativa y no representa riesgo para la información de estados financieros.

Asimismo, se validó el control de monitoreo de errores.
1: Se cuenta con un log de seguridad máximo de 2 GB, lo cual mitigaría el riesgo de que los servidores puedan
colapsar por la cantidad de logs; cabe mencionar que los objetos del sistema operativo no son manipulados con
frecuencia.

2: Se cuenta con controles de acceso por aplicación a SAP que limitan el riesgo de acceso a información sensible
de la compañía.

En la revisión identificamos que no se contó con un acta de reunión del mes de Setiembre 2016, sin embargo, se
realizaron las actividades de los acuerdos de forma individual por cada responsable de TI, los cuales son
presentados en cada comité de sistemas. Estas reuniones son internas y a demanda, remitiendo los principales
acuerdos y lineamientos que se pactaron durante el comité a las jefaturas del área de sistemas de Gloria vía
correo electrónico. La correspondiente validación, se encuentra en el siguiente EGA:
Reuniones periódicas de la Gerencia de TI
Resultado
Satisfactorio

Satisfactorio

Satisfactorio
Satisfactorio

Satisfactorio
Satisfactorio

Satisfactorio

Satisfactorio

Satisfactorio

Satisfactorio
Satisfactorio

Satisfactorio

Satisfactorio
Satisfactorio

Satisfactorio