¿Por qué la plataforma web para canales de denuncias anónimas es recomendable externalizarla? 4 consideraciones claves

El 25 de noviembre del 2009 se promulgó en Chile la ley 20.393 de responsabilidad penal de las personas jurídicas en los delitos de lavado de activos, financiamiento al terrorismo y cohecho. A partir de esta ley comenzó a proliferar la implementación de canales de denuncias anónimas, con el fin de dar cumplimento a uno de los requerimientos de este marco legal.

Antes de la promulgación de esta ley ya existían empresas multinacionales y algunas multilatinas que contaban con un canal de denuncias por medio de una plataforma web o correo electrónico y las entidades locales prácticamente no contaban con este tipo de plataformas, salvo algunas empresas que cotizan en bolsa local y que se adhieren generalmente a buenas prácticas globales o cumplen con alguna normativa como la ley Sarbanes Oxley por ejemplo por cotizar a su vez en la bolsa de Nueva York.

Cuando diversas entidades comenzaron a implementar el modelo de prevención de delitos, conforme a lo que estipula la ley 20.393, los canales de denuncias anónimas comenzaron a aumentar en formar exponencial en organizaciones de diversas industrias. 

Así es como se ven ciertos protocolos de denuncias que están relacionados con un simple correo electrónico de la empresa en donde los denunciantes pueden registrar sus denuncias y en otros casos, algunas entidades han implementado plataformas tecnológicas web desarrolladas y alojadas en sus servidores.

A continuación les comentaré las 4 desventajas y riesgos de contar con un canal de denuncias anónimas instalado en los servidores de las empresas, sea web o un correo electrónico:

1.- Existe desconfianza de parte de los denunciantes (internos y externos) cuando la plataforma es proveía por la empresa. Ej. Temores de seguimientos de IP por parte de la entidad y por ende perdida del anonimato, lo cual vulneraría la confidencialidad de la denuncia.

2.- No es recomendable colocar un correo electrónico de la empresa o entidad como canal de denuncias anónimas, ya que cualquier denuncia quedará en los servidores de la entidad siendo susceptibles de ser alterados en su integridad y/o confidencialidad antes de llegar a los miembros del comité de ética o de prevención de delitos.

3.- Al ser el canal de denuncias una plataforma web de la entidad, podría ser susceptible a alteraciones. Surgen cuestionamientos tales como: 

¿Qué pasa si las denuncias son alteradas o eliminadas antes de que llegen a los responsables de prevención de delitos u oficial de ética? 

¿Cómo se obtiene seguridad razonable respecto a la integridad y confidencialidad de las denuncias?

4.- Siempre las denuncias deben llegar de manera integra a más de 1 interlocutor, a fin de mantener un control por oposición de intereses. Esto se tiende a perder cuando existe sólo un correo electrónico o las plataformas web no cuentan con los "workflows" apropiados que contemplen a todos los interlocutores en un flujo de trabajo del canal de denuncias.

Adicional a lo antes mencionado, es importante tener siempre presente de que el éxito de los canales de denuncias anónimas, estará directamente relacionado con la difusión interna y la visibilidad que tenga para que los "stakeholders" externos puedan hacer sus denuncias de manera práctica y bajo un protocolo probado y divulgado. Al respecto, me he podido percatar que hay empresas que colocan el canal de denuncias lo menos visible posible, lo cual conlleva a no cumplir el objetivo, no siendo una buena práctica.

Finalmente, tengamos presente que el canal de denuncias anónimas, es el mejor aliado de las 3 líneas de defensa en la organización y opera como un muy buen control disuasivo generalmente.

Solución SAP Audit Management. Lo nuevo de la suite GRC

Hace muy poco tiempo SAP ha liberado la solución SAP Audit Management como parte de un nuevo módulo de la suite Governance, Risk & Compliance (GRC).

Esta nueva solución estará destinada a ayudar a las áreas de auditoría interna a gestionar el ciclo completo de auditoría, que nace desde el plan anual de trabajo, pasando por la desagregación de unidades organizativas, procesos de negocio, objetivos de control, riesgos, actividades de control (manuales, automáticas, semiautomáticas), pruebas de auditoría, observaciones de control, planes de acción de remediación y seguimiento de los mismos.

Lo bueno de esta nueva solución, es que se integra de forma natural con el resto de las componentes de la suite GRC: Access Control, Process Control y Risk Management, por lo que los auditores internos podrán desarrollar sus planes anuales de auditoría, a partir de las evaluaciones de riesgos realizadas a través de Risk Management. 

Es importante tener presente, que Risk Management permite realizar evaluaciones de riesgo "top-down", es decir, partiendo de los riesgos estratégicos pudiendo bajar a los riesgos a nivel de procesos de negocio en la entidad (tácticos u operativos).

Asimismo, los auditores podrán vincular sus pruebas tanto sustantivas como de cumplimiento de controles configurados y automáticos, aprovechando la integración con SAP GRC Process Control y Access Control (a nivel de controles de segregación de funciones).

Ahora bien, las entidades que no tengan implementado algún otro componente de la suite SAP GRC, podrán utilizar tanto Fraud como Audit Management, ya que si bien funcionan integradas pero una no es condición para que funcione la otra.

Seguridad en Maestro de Usuarios SAP ERP

El maestro de usuarios es tan crítico como cualquier otro y es necesario resguardarlo y monitorearlo en forma continua, sobre todo en los ambientes de desarrollo y productivo del sistema SAP ERP.

En los foros constantemente hay preguntas tales como: ¿Qué pasa con la cuenta de usuario SAP ERP si un empleado deja la entidad? La respuesta a esta recurrente pregunta es clara y desde el punto de vista de control interno es recomendable bloquearla y desvincularle la totalidad de sus roles, perfiles y autorizaciones. Asimismo, es recomendable asociarla a un grupo de usuarios como por ejemplo denominado ExEmpleados o uno que sea representativo, a fin de mantenerlos fácilmente monitoreados y clasificados.

Otra de las preguntas que surge es: ¿Por qué no es recomendable eliminar los usuarios en el sistema SAP ERP? Esto porque al eliminar a los usuarios existe el riesgo de alterar la trazabilidad histórica de la cuenta eliminada. Esto dado a que generalmente los User Id son creados entre una mezcla de la inicial del nombre y apellido por ejemplo JPEREZ para asociar la cuenta del usuario Juan Pérez, entonces si el empleado Juan Pérez abandona la entidad o es desvinculado y si su cuenta es eliminada, en un futuro y dado al dinamismo de las entidades, podría darse el caso que llegue un nuevo empleado Jorge Pérez y le sea asignado el User Id JPEREZ que alguna vez fue usado por Juan Pérez y tratándose de usuarios con roles claves en la organización, la trazabilidad asociada a las transacciones realizadas por este User Id si bien no se pierde pero se podría ver alterada en las bases de datos físicas (tablas) y lógicas donde se ha almacenado las transacciones realizadas por el usuario.

Por esta razón, no es recomendable eliminar las cuentas de usuario, sobre todo considerando que frente a un juicio o investigación forense pericial en donde se requiera obtener evidencia fehaciente de transacciones ejecutadas por los usuarios, esta información se podría ver alterada como medio de prueba y por ende, desacreditada o desechada.

Lo otro que es importante, es mantener monitoreados y resguardadas las transacciones que permiten crear, modificar y/o eliminar las cuentas de usuario (transacción SU01) con la restricción y/o segmentación de sus respectivos objetos de autorización que permiten ejecutar alguna de estas acciones.

Por cierto, ideal sería si las entidades tuvieran implementado el módulo HCM (Human Capital Management) de SAP y vincular los empleados del maestro de personal a los User Id de SAP ERP, por medio de las posiciones y/o funciones de recursos humanos, lo cual permite desvincular o vincular los roles, perfiles y autorizaciones de usuarios a partir de los movimientos de recursos humanos o usar el modelos de roles vinculados a perfiles estructurales en HCM, lo cual es un tanto más complejo de construir y mantener.

Asimismo, se debe tener mucho cuidado respecto a la asignación a un mismo usuario de la transacción SU01, SU02 y PFCG dado a que genera un conflicto de segregación de funciones (SoD en sus siglas en inglés) pudiendo con estos privilegios crearse un usuario en forma indebida y asignarle roles, perfiles y autorizaciones amplios en el sistema SAP ERP.

Esta última consideración se debe tener en cualquier ambiente SAP ERP, pero el monitoreo y control es con más énfasis en el ambiente de desarrollo y productivo.

En resumen, aquí van las 10 consideraciones claves a tener en cuenta en materia de seguridad del maestro de usuarios en SAP:

1.- No eliminar el usuario SAP cuando deja de pertenecer a la entidad, sea este interno o externo.

2.- Se debe bloquear al usuario inmediatamente al momento de que deja la entidad.

3.- Se debe desvincular inmediatamente la totalidad de los roles, perfiles y autorizaciones de la cuenta de usuario que deja la entidad.

4.- Se debe clasificar a estos usuarios en un grupo especial y representativo, a fin de mantenerlos fácilmente monitoreados.

5.- Se debe restringir y monitorear los privilegios para la creación, modificación y/o eliminación de usuarios en el sistema.

6.- Se debe restringir y monitorear los privilegios para la creación de roles, perfiles, autorizaciones y su asignación a un User Id en SAP ERP y segregar los mismos para crear usuarios y/o mantener roles, perfiles y autorizaciones.

7.- Se debe vincular los roles, perfiles y autorizaciones al maestro de personal en HCM, a fin de automatizar los movimientos de usuarios desde la alta o baja de personal.

8.- Se debe monitorear continuamente el maestro de usuarios en los mandantes de desarrollo, prueba y productivo, pero con énfasis en los ambientes desarrollo y productivo por razones obvias.

9.- Se debe usar cuentas de usuario que sean representativas de quién la usara y evitar el uso de cuentas genérica en aquellos que ejecutan transacciones de creación, modificación, actualización, eliminación. Eventualmente se podría usar cuentas genéricas restringidas con privilegios de visualización, pero con el debido resguardo de la confidencialidad de la información.

10.- Se debe monitoreará continuamente la integridad en la creación de datos maestros de usuarios y que exista una política y procedimiento que regule todas estas consideraciones, la cual debe ser aplicada, revisada y actualizada en forma permanente por la entidad.

A lo menos abordando estas 10 medidas, se puede contar con una seguridad razonable del maestro de usuarios en SAP ERP.

¿Qué es SAP Audit Information System (SAP AIS)? ¿Por qué los auditores no usan esta funcionalidad?

Algunos se preguntan ¿Qué es SAP AIS? sobre todo auditores que se ven enfrentados a tener que auditar procesos de negocio donde el sistema SAP ERP pasa a ser clave en el flujo de información o en los "Input, Process & Output" que fluyen en forma sistemática en esos procesos, pero para entender bien qué es realmente esta funcionalidad que posee el sistema SAP, a continuación les comentaré algunos tips y buenas noticias que de seguro les ayudará a comprender mejor esta funcionalidad.

SAP Audit Information System (en sus siglas en inglés AIS) es una funcionalidad  de auditoría que le permite evaluar los procesos implementados en SAP ERP, pudiendo ser utilizada con mucho énfasis en los procesos "BackOffice", es decir, procesos asociados a los módulos FI-CO-MM-SD-HR y procesos tecnológicos asociados al aplicativo que se implementan en el módulo BC (Basis Components) de SAP, por lo que puede ser utilizada tanto por auditores de sistemas como de procesos, debido a la  gran cantidad de variadas funcionalidades que ofrece, tales como para auditar:

Ámbito Auditoría de Sistemas ==>

- Configuración de bases de datos.

- Configuración de sistema operativo.

- Configuración de parámetros de seguridad de accesos.

- Rendimiento del sistema "performance".

- Procesos de fondo.

- Seguridad de roles y perfiles de usuario (incluida una herramienta de análisis de segregación de funciones SoD) a la cual se le puede incorporar reglas SoD.

- Monitoreo de ejecución de transacciones en línea e históricas.

- Activación de log de auditoría para el tracking de información de ciertos usuarios.

- Trace de seguridad de usuarios y autorizaciones.

- Auditoría de tablas y diccionario de datos.

- Auditoría a los programas ABAP y control de cambios (desarrollos Z).

- Etc...

Ámbito Auditoría de Procesos ==>

- Revisión de controles configurados o automáticos de los procesos de negocio. Ejemplo: límites de tolerancia en la gestión de stock de materiales o para desviaciones entre pedidos de compra y facturas de proveedor.

- Revisión de reportes de excepción relacionados con chequeos de consistencia de los flujos de información de procesos.

- Revisión de reportes de gastos y aprobaciones de los mismos.

- Revisión de movimientos de activos fijos.

- Revisión de ajustes de inventarios.

- Revisión de transacciones inusuales con indicios de fraude.

- Revisión de la segregación funcional de los privilegios otorgados a los usuarios de los procesos por medio de roles y perfiles.

- Revisión de ajustes de inventario y desviaciones del físico versus el teórico.

- Revisión de las propuestas de pago masivo a proveedores.

- Revisión de aspectos tributarios.

- Etc...

Estos ejemplos, representan algunas de las herramientas que SAP AIS le ofrece al auditor para que pueda desarrollar auditorías independientes y obtener la información desde la fuente de origen, pensando en el "escepticismo profesional" y en la mitigación de los riesgos de detección y auditoría.

Con la funcionalidad SAP AIS, los auditores podrán realizar auditorías tanto para la ejecución de pruebas de cumplimento o sustantivas en el ámbito de sistemas de información o de procesos de negocio.

Las ventajas que ofrece el uso de SAP AIS para los auditores:

- Funcionalidad es parte de SAP ERP, por lo que no se compra por separado.

- Podrá ser utilizado por auditores externos, internos (sistemas / procesos) y oficial de seguridad de la información CISO.

- El uso de SAP AIS no depende del área de sistemas de la empresa, por lo que el auditor podrá utilizarla y obtener información cuando quiera.

- Los reportes que posee SAP AIS son bastante intuitivos y con la misma interfaz gráfica de usuario que ofrece SAP ERP.  Salvo que se trate de reportes relativos al módulos BC que es tecnológico y el análisis e interpretación de los resultados debe ser revisado por un auditor de sistemas y/u oficial de seguridad de la información.

Algunas consideraciones importantes:

- SAP AIS si bien es una funcionalidad propia de SAP ERP, debe ser configurado por un equipo de especialistas con expertise en SAP AIS, antes de ser utilizado por los usuarios finales (auditores, seguridad de la información, etc.)

- Los usuarios finales de SAP AIS deben entrenarse antes de utilizar sus funcionalidades.

- Se debe acotar el uso de herramientas a utilizar y es recomendable partir por las más esenciales y poco a poco ir sumando otras más específicas. Esto en materia de ejecución de reportes estándar que ofrece SAP AIS.

- El área de TI también debe ser entrenada en SAP AIS, a fin de que pueda cubrir los requerimientos posterior a la configuración y go live (salida a productivo de SAP AIS)

- La ejecución de log de auditoría debe ser coordinado con las áreas de TI, a fin de definir un almacenamiento masivo de información de log práctico, certero y eventualmente apoyado con un dispositivo de almacenamiento externo.  

- No es recomendable hacer log masivos y se debe acotar con la ayuda de especialistas tecnológicos o especialistas en SAP AIS.

- Se debe auditar los ambientes Desarrollo, Prueba y Productivo, por lo que SAP AIS debe estar activado en los 3 ambientes de SAP ERP.

- La obtención masiva de información de tablas se debe hacer con mucho cuidado para no mermar el performance de SAP ERP. Se recomienda obtener información masiva en procesos de fondo. (Tablas con más de 100.000 registros)

Algunos auditores me han comentado que cuando le piden al área de TI la configuración de SAP AIS para ser utilizado en las auditorías de proceso o sistemas, por desconocimiento se le responde: "no se puede porque merma el performance, hay que comprar el módulo y no fue presupuestado, no es parte del alcance de la implementación SAP y no se puede usar, están prohibidos los log de auditoría, etc." Muchas de estas respuestas son por desconocimiento, ya que ni siquiera la gran mayoría de los implementadores de SAP ERP saben configurar SAP AIS o no saben de su existencia y es por eso que el uso que se le da a esta funcionalidad es muy limitado o nulo.

Por último, se debe tener presente que SAP AIS se complementa muy bien con las Computer-assisted audit techniques (en sus siglas en inglés CAATs) ACL, IDEA, ACCESS, etc., para la obtención de tablas que serán utilizadas para ejecución de pruebas sustantivas o analíticas y/o procedimientos de detección de fraudes, pero una no reemplaza a la otra. 

Para más información me pueden escribir a: pdhernandez@deloitte.com

6 lecciones aprendidas de implementaciones de reglas automáticas de monitoreo continuo en SAP GRC Process Control

Ya muchas empresas durante el 2013 ejecutaron proyectos de implementación de modelos de monitoreo continuo a través de la solución SAP GRC Access y/o Process Control.

En el caso de SAP GRC Access Control, este tipo de iniciativas han sido más sencillas, dado a la madurez del producto con sus reglas de segregación funcional (siglas en inglés SoD), las cuales generan conexiones con SAP ERP de forma mucho más natural y estable, pero tratándose de SAP GRC Process Control, la experiencia ha sido distinta y un tanto más compleja, es así como a partir de las vivencias en implementación de reglas de monitoreo continuo en SAP GRC Process Control, les comparto las siguientes lecciones aprendidas:

1.- Privilegios adecuados en ambiente de Desarrollo SAP GRC Process Control y SAP ERP.

Se debe contar con un mandante de Desarrollo SAP GRC Process Control y SAP ERP con privilegios adecuados para el diseño, construcción y pruebas unitarias de las reglas. El no contar con este requisito esencial, pone en serio riesgo el éxito del proyecto y el cumplimiento de las expectativas del mismo.

2.- Apoyo de equipo funcional SAP ERP.

Otros de los factores críticos de éxito tratándose de implementación de reglas automáticas de monitoreo continuo, es el involucramiento de los líderes funcionales o key users de los módulos SAP ERP a los que se les aplicará reglas, de lo contrario el diseño de estas reglas puede ponerse en riegos por el conocimiento funcional específico que se requiere de los modelos de datos de cada aplicación funcional de SAP ERP.  

El diseño y construcción de reglas requiere de mucho conocimiento del modelo de datos del módulo (bases de datos lógicas, tablas físicas, campos claves, etc.).

En algunos casos, es necesario crear ciertos controles automáticos que emanan de programas y tablas Z (desarrollos no estándar a la medida), ya que las reglas de control estándar que vienen con SAP GRC Process Control, eventualmente puede que no cubran  completamente la necesidad de monitoreo de la entidad y en ese caso, se hace necesario crear un control más ad hoc.

Nos podríamos preguntar. ¿Por qué debemos diseñar y construir reglas de controles para el monitoreo continuo con SAP GRC Process Control, si el producto las trae incorporadas de forma estándar?. La respuesta es, porque simplemente las reglas estándar no necesariamente cubren todas las necesidades de reglas de control que requieren las entidades y de ahí nace la necesidad de tener que crear reglas más acorde a los procesos de negocio.

3.- Conocimiento de los módulos funcionales de SAP ERP del equipo implementador y de la empresa donde se implementarán las reglas de control.

A lo menos se debe involucrar como parte del equipo de consultores, un especialista conocedor del módulo funcional donde se aplicarán las reglas, es decir, dentro de este equipo debe existir un grupo multidisciplinario entre consultores especialistas en SAP GRC Process Control y un especialista funcional del módulo SAP ERP que corresponda aplicarle reglas.

Es importante que el equipo multidisciplinario conozca de modelos de control interno y de esa forma se facilita de sobremanera el éxito de las reglas de control. 

Respecto a este punto, es importante saber que hay empresas que si cuentan con equipos de consultores funcionales internos (módulo FI, CO, MM, SD, etc.) y que conocen muy bien los atributos funcionales de estos, pero es factible encontrarse con empresas donde no necesariamente existirá este tipo de especialistas y eso implica un riesgo para el proyecto, salvo que este se mitigue con la incorporación de un consultor externo funcional y el conocimiento de los procesos de negocio se obtiene de los "key users", líderes funcionales o dueños de procesos de la entidad.

4.- Claridad en el diseño de los controles y el objetivo que se quiere cubrir sobre los procesos de negocio.

En algunas situaciones se tiende a diseñar controles que no necesariamente cubren lo que se desea controlar y este tipo de issues puede impactar en la relación del control con la regla SAP GRC  Process Control, por lo que es necesario validar con los dueños de proceso de forma exhaustiva el diseño y la relación de este con la regla de control automático que quedará asociada a SAP GRC Process Control.  

Recordemos que cuando los auditores internos o externos, auditen estos controles de procesos, lo harán sobre la base de validar en primera instancia el diseño de los mismos y si este es deficiente, estaremos frente a una debilidad de control que puede ser alta, media o baja (leve, material o significativa), dependiendo de que tan clave es el control y el proceso para la entidad.

5.- Conocimiento funcional especialista de SAP GRC Process Control.

Es factor relevante el hecho que los consultores asesores conozcan las funcionalidades de la solución SAP GRC Process Control en lo relativo a creación de frameworks, manejo de los workfkows, alertas, configuración de las reglas de controles automáticos estándar y cuatomizadas (Z). No basta involucrar a consultores especialistas en SAP GRC Access Control, ya que se trata de funcionalidades distintas y que apuntan a otros ámbitos distintos a los que cubre Access Control y en eso debe ser cuidadoso y el perfil de profesionales que debe involucrarse en proyectos de SAP GRC Process Control, es más relacionado con procesos de negocio de diversas industrias que tecnológico, por lo que es importante involucrar a profesionales con dichas skills y formar equipos multidisciplinarios.

6.- Diseñar escenarios de pruebas integrales de los controles automáticos y ejecución de las mismas en un ambiente de prueba (QAS).

La confección de escenarios de pruebas integrales y el hecho de ejecutar las mismas en un ambiente QAS, es de suma importancia en un proyecto de implementación de controles automáticos en SAP GRC Process Control y en algunas implementaciones me ha tocado ver, que ciertas empresas no contemplan un ambiente "QAS" de pruebas dado a que ven erróneamente que es un sistema que no lo requiere y en rigor si lo requiere alineado con buenas prácticas de control de cambios.

Lo otro, se debe contar con datos de prueba funcionales adecuados para verificar que las reglas de controles automáticos interactúan adecuadamente con el modelo transaccional funcional de SAP ERP, de lo contrario es factible que la información que arroja la regla, fracase y no cumpla el objetivo de mantener un adecuado monitoreo continuo de los controles claves de SAP ERP.

De no considerar estos factores críticos de éxito, es probable que su proyecto de implementación de reglas de controles automáticos en SAP GRC Process Control, no llegue a cubrir las expectativas deseadas y no sólo para SAP GRC Process Control, sino que para cualquier iniciativa de implementación de controles automáticos de monitoreo continuo, se deben tener estas consideraciones.