Puntos de Control

# 1 Año 2015 Observación Observaciones en la documentación de los procedimientos del Grupo Gloria. (1) Las políticas y

Views 68 Downloads 2 File size 67KB

Report DMCA / Copyright

DOWNLOAD FILE

Recommend stories

Citation preview

# 1

Año 2015

Observación 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