Tiene preguntas sobre para qué sirve una matriz de riesgo o cuándo usarla? En esta serie de artículos sobre el tema Matriz de segregación de funciones (SoD Risks) responderás muchas de tus dudas.
Segregation of Function, (que proviene del término en inglés “Segregation of Duty” (SoD) o “Separation of Duty”) es el concepto de tener más de una persona necesaria para completar un conjunto de tareas consideradas críticas. En los negocios, la segregación al compartir a más de un individuo en una sola tarea es un control interno diseñado para prevenir fraudes y errores. El concepto se denomina alternativamente segregación de funciones o, en el campo político, segregación de poderes. – Fuente de Wikipedia.
La estructura técnica de la matriz de riesgo a continuación ilustra los principales atributos necesarios para definir un riesgo de Segregación de Función (SoD) y / o Transacción de Acceso Sensible (SAT) y, por lo tanto, la composición del conjunto de reglas llamado Matriz de Riesgo. Este marco es parte del método TrustSis para definir, crear, ajustar la matriz de riesgo SoDs / SAT y compensar los controles.
Figura: Estructura de la matriz de riesgo de SoD
Para qué sirve la matriz de riesgos y debo utilizar las que ya están en el mercado?
Es muy común que las empresas preocupadas por evitar fraudes, errores o incluso simplemente querer conocer mejor sus procesos, cuenten con una matriz de Riesgo con varias reglas de Segregación de Funciones (SoD) para identificar qué individuos pueden realizar tareas consideradas críticas y conflictivas. Si estas tareas se segregan en diferentes personas, no se violará ninguna regla de SoD y, por lo tanto, no hay riesgo de que se produzcan fraudes o errores.
Un análisis de riesgo de SoD busca identificar y señalar a los usuarios de un sistema que se está monitoreando que puedan estar violando las reglas de riesgo de SoD. Usemos como ejemplo la regla de riesgo SoD que busca identificar a los usuarios, en un sistema monitoreado, que pueden realizar compras y al mismo tiempo también tienen acceso para realizar pagos por estas compras. Para este escenario, el usuario de ejemplo estaría violando una regla de riesgo de SoD y, por lo tanto, se señalaría en el informe de resultados del análisis. Con base en este resultado del análisis, apuntando a una violación a la norma, se inicia el proceso de reconocimiento de la legitimidad de la violación identificada, evaluando de acuerdo con los siguientes criterios:
La regla de riesgo violado indica usuarios con poder de compra y pago, sin embargo, por definición del negocio de la organización, este riesgo es legítimo y aceptable por el área, gerencia, controles, auditoría, etc. En este caso se aplica un control compensatorio.
La regla de riesgo violada indica un usuario con poder para comprar y realizar el pago, sin embargo, por definición del negocio de la organización, este riesgo no es aceptable por el área, gerencia, controles, auditoría, etc. En este caso, se aplican los pasos de remediación.
-
- Determine si la regla de riesgo de SoD realmente representa el conjunto correcto de privilegios en conflicto para identificar violaciones de riesgo de SoD y, por lo tanto, incumplimientos. Ajustar las reglas, si corresponde, y realizar un nuevo análisis de riesgo de SoD;
- Determine si los privilegios del perfil de usuario se pueden corregir para eliminar la infracción de las reglas de riesgo de SoD. En este escenario, se debe observar si los perfiles de acceso del usuario se comparten con otros usuarios, para determinar si los ajustes no los afectarán, quienes pueden necesitar mantener los privilegios que ahora se están modificando.
- Evaluar si las tareas y / o transacciones y / o acciones no permiten la ejecución de actividades conflictivas (por ejemplo, comprar y pagar) intrínsecamente por definición del proveedor del sistema. Esta situación es más difícil de mapear, sin embargo, algunos proveedores (por ejemplo, SAP) tienen notas informativas que detallan estas «anomalías».
Dependiendo del resultado del análisis de riesgo de SoDs, se recomienda un proyecto para rediseñar los perfiles de acceso y / o evaluar y ajustar el proceso para administrar el acceso y monitorear los riesgos de SoDs. Cuando el resultado del análisis indica que la mayoría de los usuarios del sistema evaluado violaron los riesgos de SoD, esto generalmente implica, en la gran mayoría de los casos, que el modelo de perfil de acceso (e incluso el proceso de gestión de acceso y monitoreo de riesgos de SoD) debe ser revisado y mejorado para obtener una mayor efectividad del control deseado.
Las matrices de riesgo de SoD que ofrecen las empresas de consultoría o las herramientas de GRC pueden ser utilizadas por mi empresa?
La respuesta a esta pregunta es SÍ y NO. Y todo dependerá de la evaluación de los siguientes criterios, utilizados para la toma de decisiones.
Cada matriz de riesgo de SoD «lista para usar«, las que ofrecen las empresas de consultoría o las herramientas de GRC (por ejemplo, SAP GRC Access Control) traen un conjunto de reglas que representan la combinación crítica de tareas y / o transacciones y / o acciones de un determinado sistema empresarial (por ejemplo, SAP ECC, S4 / HANA, Oracle, Ariba, TOTVS Protheus, TASY, RM, HCM, CRM, SRM, HR, Factor de éxito, etc.). Estas combinaciones se basan en procesos y / o módulos activos de los sistemas empresariales en cuestión. Por lo tanto, la matriz será totalmente compatible o no, si los ERP (en nuestro ejemplo) tienen las mismas tareas y / o transacciones y / o acciones que se utilizan.
Cómo puedo determinar si la matriz de riesgos cumple al 100% con mi empresa?
La forma más sencilla de evaluar si las matrices de riesgo de SoD listas para usar que ofrecen las empresas de consultoría o las herramientas de GRC (por ejemplo, SAP GRC Access Control) se adhieren al sistema de negocios de su empresa es considerar y buscar las respuestas a las siguientes preguntas: El riesgo de Sod Matriz,
-
- Tiene las tareas y / o transacciones y / o acciones equivalentes a la versión de lanzamiento de mi sistema empresarial?
- Representa todos los procesos y módulos activos de mi sistema empresarial?
- Presenta procesos y módulos que no tienen sentido para mi sistema empresarial?
- Las personalizaciones realizadas por mi empresa deben incluirse en esta matriz de riesgos “lista para usar”?
- Las combinaciones de riesgos de las SoD representan las particularidades de mi negocio para evitar falsos positivos en los resultados del análisis de riesgos?
Ejemplo: las aprobaciones fluyen donde es obligatorio que cualquier pago se presente sistemáticamente para su aprobación y liberación.
-
- Tiene la descripción del riesgo un lenguaje que los usuarios de mi organización puedan entender?
- La criticidad de los riesgos de la matriz está alineada con la criticidad deseada por nuestra organización?
- Nuestra organización ha reconocido todos los riesgos de la matriz como legítimos?
Estas, entre otras preguntas, son extremadamente importantes para determinar si la matriz de riesgo de SoD que ofrecen las empresas consultoras o las herramientas de GRC (por ejemplo, SAP GRC Access Control) se adhiere a su sistema empresarial y se puede utilizar sin pasar por un proceso de revisión y adecuación.
Cabe recordar que para tener una Matriz de Riesgos de SoD a cualquier costo para resolver un GAP de auditoría, realizar un rediseño de perfiles de acceso o incluso intentar establecer un proceso de gestión de acceso y monitoreo de riesgo de SoD, se puede – en consecuencia – generar un ciclo de otros problemas cuando no se observan los problemas señalados anteriormente. Se recomienda comprender la estructura de la Matriz de Riesgos de SoD adquirida y para no establecer una hoja de ruta de mejora que pudiera empeorar el escenario de riesgo de su organización, es importante consultar a un socio de servicio experimentado para proponer las mejores prácticas de ajustes, adecuación y proceso. de uso de la matriz de riesgo de SoD.
Ponte en contacto con nosotros y cuenta con profesionales altamente cualificados para ayudarte en esta elección!
