Monitoreo continuo de riesgos de segregación de funciones (SoD)

La mayoría de las entidades hoy en día utilizan un sistema de información del tipo ERP o sistema integrado de gestión, que integra los diversos procesos en un mismo aplicativo, posibilitando que la información sea más exacta, completa, válida y oportuna.

La exactitud, completitud y validez, se dará en la medida que los registros en el sistema sean realizados de forma íntegra por los usuarios finales, pero eso no depende necesariamente de entrenamiento a los usuarios, sino que también será posible en la medida que los controles de estos sistemas estén debidamente configurados, puesto que los controles automáticos tienden a ser preventivos y mucho más eficaces.

Es por esto que, se requiere que los controles automáticos a nivel de procesos, estén debidamente diseñados e implementados, a fin de que sean eficaces en la mitigación de los riesgos y es por eso que se requiere que estos propósitos los lleve a cabo la primera línea de aseguramiento, con un trabajo colaborativo con los especialistas en riesgos y controles localizados en la segunda línea, los cuales podrían ser internos o externos.

Al respecto, se puede identificar los controles automáticos relacionados con el otorgamiento de privilegios para que los usuarios transaccionen en el sistema de información, donde suelen existir errores u omisiones en la configuración, lo cual potencia vulnerabilidades en los accesos que realizan los usuarios y en los privilegios que les son otorgados, donde hay tareas críticas y conflictivas, que son susceptibles de asignar, potenciándose la materialización de los riesgos.

Es por ello que, el monitoreo continuo que debe realizar la primera línea de aseguramiento y el debido cuidado que debe colocar en las autorizaciones que otorga, debe ser una tarea mandatoria, sistemática y continua, apoyada con alguna herramienta automatizada que permita analizar los riesgos que implican los permisos autorizados y que solicitan continuamente los usuarios finales. Estas herramientas, deben permitir analizar las combinaciones críticas y conflictivas, alertando al aprobador de forma preventiva antes de que autorice el otorgamiento de un privilegio riesgoso.

Al respecto, generalmente se puede observar que los aprobadores o dueños de procesos y que son los responsables de gestionar los riesgos, aprueban cualquier cosa que se les solicita y sin mayor cuestionamiento, lo que representa la causa del potenciamiento de los riesgos y en muchos casos el efecto es la materialización de algún ilícito que incluso podría constituir una estafa o fraude, con el consiguiente perjuicio financiero y daño reputacional para la entidad.

Ejemplos de este tipo de perjuicios, existen y en variadas industrias, por lo que es necesario tomar conciencia y sumado también a los riesgos de ciberseguridad, que se adicionan a las vulnerabilidades del ambiente de control en materia de seguridad de la información de los sistemas, con especial énfasis en aquellos sistemas core o que integran los procesos más críticos de la entidad.

Finalmente, es importante considerar que esas aprobación que hacen los responsables y sin considerar los factores de riesgo, se da en muchas ocaciones por la ausencia de una herramienta que le alerte de manera proactiva o por desconocimiento y para no entorpecer un potencial impacto en la operación de la entidad, terminan aprobando los requerimientos que solicitan los usuarios finales sin mayor cuestionamientos o filtro.

Fraude por más de $ 2.000 millones en empresa naviera, por falla de segregación de funciones (SoD) en SAP ERP

El fraude por más de $ 2.000 millones que nos hemos enterado en estos días, donde la víctima fue una empresa naviera multinacional con filial en Chile, cuyo nombre ya da vueltas en diversos medios noticiosos en Chile y Latam, con el consiguiente daño financiero, reputacional, de imagen y que comenté hace unos días, a partir de comunicado emanado del Poder Judicial.

Esto se da principalmente, por la ausencia de monitoreo eficaz de controles relativos a riesgos de segregación de funciones (SoD) en los sistemas de información como SAP ERP, lo cual se refleja en la definición de los privilegios que deben utilizar los usuarios en el sistema aplicativo y cuyo monitoreo continuo, está localizado tanto en la primera como segunda línea de aseguramiento, cuestión que falló o simplemente no existió y que además, debería ser parte de un modelo de Gestión Integral de Riesgos (ERM), a nivel de procesos.

Asimismo, estas fallas se exacerban cuando no existen funciones de segunda línea, especialistas en monitoreo continuo de este tipo de riesgos, los cuales es necesario monitorear por medio de herramientas o sistemas expertos automatizados, que posean las combinatorias de riesgos que tienen estos aplicativos ERP, que se exponencian por la cantidad de posibilidades de permisos y variantes de transacciones. Nótese que SAP ERP en su versión S/4HANA, posee más de 130.000 posibilidades de transacciones o privilegios.

A lo anterior, súmele la falta de especialistas que dominen técnicamente estos temas en las áreas de Auditoría Interna como función de tercera línea de aseguramiento e independiente, cuestión que debe ser revisado mandatoriamente como parte de la ejecución de los planes anuales de auditoría convencionales y de auditoría continua de realización paralela, apoyados por herramientas analíticas automatizadas, que posean las reglas de segregación de funciones, a lo menos para los procesos más riesgosos relacionados con los sistemas ERP.

Estas materias las revisamos en profundidad en nuestro Diplomado en Auditoría y Seguridad SAP ERP, de GRC Academy (Latam).

Consultas a: contacto@grclatam.com

SAPAudit #SAPInternalControl #SAPRiskManagement

Responsabilidades de la primera y segunda línea en el control de accesos

El control de accesos en los sistemas aplicativos es parte de todo modelo de control interno, donde la primera línea de control tiene la responsabilidad de gestionarlo desde una perspectiva de los riesgos de procesos que se deben abordar en forma continua, considerando que los dueños de procesos son los que deben hacerse cargo de esto y no la función de seguridad de la información o el área de control de accesos como parte de la segunda línea.

Estas funciones de seguridad de la información y control de accesos, como parte de la segunda línea de control, en rigor deben colaborar con los dueños de procesos localizados en la primera línea, en lo que respecta a la gestión de los riesgos y control, pero en ningún caso son los responsables de aprobar los accesos que los usuarios de los sistemas aplicativos como SAP ERP deben tener como parte de sus privilegios.

En mi experiencia, me he encontrado en varias ocasiones con entidades de diversas industrias y tamaños, que localizan la responsabilidad de aprobar el otorgamiento de privilegios del sistema aplicativo en la segunda línea de control y no en la primera línea, lo cual es un error considerando los marcos de referencia o las buenas prácticas que proporcionan directrices en este contexto, tales como: ISO 27.001, ISO 31.000, COSO, Ley Sarbanes Oxley, etc.

Es así como surge la necesidad de contar con modelos GRC (Governance, Risk & Compliance), de control de accesos, los cuales contribuyen con normar estos ámbitos, darles sostenibilidad en el tiempo e incorporarle tecnología analítica, de manera tal de que las distintas líneas de control de una entidad, puedan gestionar los riesgos y controles de procesos relativos a control de accesos y cada cual cumpliendo con sus roles y responsabilidades, en un adecuado marco de segregación de funciones, posibilitando tanto el monitoreo continuo de la primera y segunda línea, como la auditoría continua independiente de la tercera línea.

Estas y otras materias de control de acceso, revisamos y analizamos en los cursos de Seguridad, Administración de Roles y Perfiles de Usuario, Contron Interno y Auditoría SAP ERP que ofrece nuestra Academia.

Aspectos a considerar al evaluar una solución automatizada de análisis de segregación funcional (SoD) en sus siglas en inglés (Segregation of Duties)

‪Al evaluar una solución de este tipo debe preocuparse que a lo menos cumpla con lo siguiente: ‬

‪- Que haga análisis de transacciones conflictivas.‬

‪- Que haga análisis de transacciones criticas (no es lo mismo que transacciones conflictivas) ‬

‪- Que permita hacer análisis desde 1 a muchos usuarios en tiempo real.‬

‪- Que permita hacer análisis desde 1 a muchos roles/perfiles en tiempo real.‬

‪- Que el nivel de análisis sea fino, es decir, que llegue a las capas más especificas de autorización (denominadas 3 capas de seguridad de autorización en SAP).  De lo contrario, los resultados son falsos positivos y eso contamina la evidencia (invalida los resultados)‬

‪- Que entregue los riesgos SoD, es decir, si son altos, medios y bajos, con la descripción de estos, a fin de que los Process Owners y Role Owners, sepan claramente a los riesgos que se exponen en la medida que autorizan un acceso.  No basta con que indique si el nivel de riesgo es alto, medio, bajo, es muy importante que indique la implicancia o el concepto del riesgo. ‬

‪- Que permita hacer análisis en tiempo real o sacar una foto en el momento que se estime pertinente. ‬

‪- Que ofrezca funcionalidades para incorporar los controles de mitigación de los riesgos aceptados por los dueños de la información. ‬

‪- Que tenga reglas de segregación funcional de clase mundial (buenas prácticas)‬

‪- Que permita agregar reglas de segregación funcional a la medida del negocio (adhoc a la industria en la que está la empresa por ejemplo)‬

‪- Que permita customizar o adaptar las reglas SoD estándares.‬

‪- Que permita realizar aprovisionamiento de accesos a través de un workflow en forma automática. (provisioning) con análisis de riesgo SoD en forma simultánea.‬

‪- Que permita hacer análisis SoD a nivel de roles/perfiles (intrarol) y roles a usuarios (por usuarios)‬

‪- Que almacene automáticamente la evidencia de las aprobaciones de acceso por parte de los dueños de la información.‬

‪- Que la evidencia de aprobaciones almacenada sea auditable.‬

‪- Qué permita monitorear los accesos amplios de los súper-usuarios y que la solución deje evidencia automática de los cambios realizados. (ejemplo: cambios sobre campos críticos de ciertas tablas o customizing SAP)‬

‪A lo menos estas funcionalidades deberían tener una buena herramienta de análisis SoD, para poder obtener resultados razonables, en forma eficiente y rentabilizar la inversión, de lo contrario es muy probable que se deba volver a los mecanismos manuales de análisis.  ‬

‪Otro factor no menor, es elegir un partner implementador que cuente con credenciales concretas y validables, dado a que como son soluciones relativamente nuevas, el riesgo que se corre al hacerlo con partners sin experiencia es muy alto y el proyecto puede tender al fracaso. (este es un factor crítico de éxito)‬

Las 6 herramientas que el auditor SAP debe dominar

Actualmente un número importante de empresas de gran tamaño y de diversas industrias, han implementado el sistema ERP SAP en todo el mundo, lo cual implica que los auditores internos y externos para poder estar a la altura de las circunstancias y ejecutar auditorías con base en la fuente confiable e ir al origen de la información, requieren dominar el uso de ciertas herramientas estándar que posee este sistema de clase mundial, considerando a su vez que el escepticismo profesional es esencial en todo auditor.

A continuación les mencionaré las 6 herramientas de auditoría para SAP ERP, que todo auditor debe conocer:
1.- Sistema de Infomación de usuarios y autorizaciones – Transacción SUIM: Esta herramienta le permite al auditor poder efectuar pruebas de auditoría orientadas al maestro de usuario y a los roles, perfiles y autorizaciones.  Asimismo, permite revisar los parámetros de seguridad del sistema relacionados con la autenticación de usuarios en SAP entre otros.
2.- Sistema info de tablas del sistema – Transacción SE16 en modo Display: Esta herramienta le permite al auditor poder obtener tablas de las bases de datos del sistema SAP y poder realizar pruebas relacionadas con las transacciones en los ciclos de negocio y los aspectos propios de la configuración del sistema.  En la medida que esta herramienta es usada con precaución, el auditor no debería tener inconvenientes, pero se recomienda bajar tablas masivas en procesos de fondo, a fin de no mermar el performance en ambiente productivo de SAP.  Se pueden hacer pruebas relacionadas con parámetros de controles configurados, revisión de los libros contables: Libro Diario, Centralizaciones Contables, Procedimientos de Detección de Fraudes, etc. complementado con herramientas tales como: ACL, IDEA, EXCEL, etc.
3.- Sistema info de diccionario de datos y programas ABAP – Transacción SE15 en modo Display: Permite en modo display revisar las bases de datos lógicas que contienen las tablas físicas del sistema SAP y comprender la relación entre estas y los procesos de negocio implementados.  Asimismo, se puede revisar las sentencias de programación de los programa ABAP de SAP y así verificar que las mismas, cumplan con los estándares y buenas prácticas definidos en las políticas y procedimientos de la organización.
4.- Sistema info de customizing o configuración del sistema SAP – Transacción SPRO en modo Display: Permite revisar la configuración funcional de los procesos parametrizados en SAP, de esta forma el auditor podrá revisar los controles configurados de cada proceso por ejemplo: Estrategias de liberación o aprobación en compras, límites de tolerancia en compras y gestión de stock, clases de documentos, etc.
5.- Trace o tracking de log de autorizaciones y transacciones – Transacciones ST01 y ST03 Display: Estas transacciones permiten obtener evidencia de las ejecuciones tanto de transacciones como autorizaciones que han efectuado los usuarios en SAP, por lo que le permitirá al auditor recabar información clave respecto a los privilegios que los usuarios han usado y si los mismos, corresponden estrictamente a lo que deberían tener.  La interpretación del trace de la transacción ST01 es muy técnica y requiere de conocimientos experto del concepto de autorización en SAP.
6.- Sistema info de auditoría AIS – Basado en roles de auditor actualmente: Esta herramienta es altamente útil y prácticamente contiene las 5 herramientas antes mencionadas y viene configurada por defecto en modo display, lo que hace mucho más fácil su uso.  La gran particularidad que tiene esta herramienta, es que cubre aspectos de implementación técnica del módulo BC de SAP y aspectos funcionales, por lo que es muy completa, ya que trae grupos de reportes predefinidos que entregan evidencia de auditoría en forma inmediata.  Ver presentación de AIS: https://www.slideshare.net/pdhernandez/presentacin-audit-information-system-sap-ais-56224867

Trace de autorizaciones por medio de la transacción ST01 – una muy buena herramienta para auditores y administradores de seguridad SAP

Esta herramienta posee características que la hace ser una de las más importantes para auditar y obtener evidencia de accesos de los usuarios del sistema SAP: 

– Herramienta de fácil uso y es recomendable dominar el concepto de autorización para su utilización e interpretación adecuada (capa 1, 2 y 3 de seguridad de autorizaciones) 

– Herramienta que no merma el performance de la operación del ambiente en donde se tenga activada (no es invasiva). Este es el típico motivo por el cual se le bloquea el acceso a los auditores, perdiendo la oportunidad de obtener evidencia de muy buena calidad para la auditoría.  Si el trace está activo solamente para la verificación de autorizaciones, no habría merma de performance.  Eventualmente podríamos tener impacto, en la medida que activemos todas las opciones del trace (RFC, tablas, etc.) 

– Ocupa espacio en disco que se puede ir reciclando por medio de uso de dispositivos externos (discos de respaldo externos) y así no merma el espacio en disco. Esto se puede ir haciendo día a día, dado a la cantidad de información que almacena el trace y se recomienda dejarlo en 99MB de almacenamiento (máximo), a fin de que cada archivo genere la mayor cantidad de información posible. 

– Para un eficiente procesamiento y análisis de la evidencia, se recomienda trabajar el resultado del trace apoyado de un CAATs (técnicas de auditoría asistidas por computador) – ACL, ACCESS, EXCEL 

– La evidencia obtenida llega a nivel de capa 3 de seguridad de accesos (capa 1 S_TCODE, capa 2 TSTCA y capa 3 USOBT, por lo que la enriquece para evitar falsos positivos.
– Para un modelo de prevención de delitos (Ley 20.393) y/o fraudes (procedimientos de detección de fraudes en el marco de las auditorías internas o externas) es muy recomendado, debido a la calidad de la evidencia. 
– Para el monitoreo del modelo de control interno de segregación funcional SoD-SOX Compliance, es muy recomendado, ya que nos permite obtener evidencia del monitoreo que hacen los dueños de procesos (process owners) o dueños de roles (role owners) en relación a los accesos bajo su responsabilidad. 
– Se puede complementar con los resultados de otras herramientas tales como: Ejecución histórica de transacciones ST03, STAD, SM04, SM20 log de auditoría con obtención de usuario, transacción y terminal (estas herramientas solamente llegan a nivel de capa 1 de seguridad, es decir, a nivel de transacción ejecutada por usuarios y no cubren los objetos de autorización. (Son susceptibles de levantar falsos positivos), pero complementado con el trace de autorizaciones se enriquece la evidencia.

IT Risk Management solutions

Les comparto el último cuadrante mágico de Gartner, acerca de IT Risk Management solutions, basado en estudio realizado que considera aspectos tales como:

– Funcionalidades acorde a buenas prácticas

– Versatilidad

– Usabilidad

– Intuitividad

– Potencial data analytics

– Potencial robótica e inteligencia artificial

– Implementación y soporte post go live

#ERM #GRC #RiskManagement

Los problemas y soluciones que identifica el asesor presidencial en ciberseguridad

En entrevista realizada hoy al asesor presidencial en ciberseguridad Mario Farren, por el Diario Financiero, se refiere a los problemas y soluciones que identifica en relación a la implementación de medidas tendientes a mitigar riesgos relativos a ciberseguridad en entidades tanto públicas como privadas y hace mención al estado del arte en que nos encontramos en Chile, resaltando la ausencia de modelos de gestión de riesgos robustos y maduros.

En definitiva, mientras no exista orgánica, marco normativo robusto, eficaz y cambio cultural que potencie la función de gestión integral de riesgos en las organizaciones y de manera holística, difícilmente prosperarán iniciativas orientadas a la gestión del riesgo de ciberseguridad, driver que por cierto, es uno más de los que se debe gestionar en el ámbito operacional y cuyas repercusiones pondrían mermar de sobremanera a entidades, sobre todo en donde las tecnologías son dominantes para el core business, impactando también a nivel estratégico.

Aquí no se trata de pensar en el ROI (retorno sobre la inversión), sino que más bien, hay que pensar en el costo total de falla para avanzar con estas inversiones, donde muchos ejecutivos se pierden en la búsqueda del ROI asociado a la implementación de un modelo de gestión integral de riesgos (ERM) y las iniciativas tienden a quedar en nada, a medias y/o abandonadas.

Tal como dice Mario Farren: ”desde el punto de vista organizacional es que quizás, antes de comenzar a comprar herramientas tecnológicas, tenemos que hacer cambios organizacionales»; esto implica que si no se cuenta con un modelo de riesgos que cumpla con las buenas prácticas, ni las herramientas más sofisticadas le harán gestionar los riesgos de ciberseguridad de forma eficaz.

https://www.df.cl/noticias/mercados/banca-fintech/los-problemas-y-soluciones-que-identifica-el-asesor-presidencial-de/2019-08-02/133452.html

Riesgos de ciberseguridad en industria financiera

A propósito de la noticia que el portal de Radio Biobío, ha dado a conocer hoy, respecto a que la empresa Redbanc admite que le robaron información de casi 300 mil tarjetas de crédito y débito, comentar que las inversiones en medidas de ciberseguridad, claramente no han sido suficientes para mitigar este tipo de riesgos, que repercuten en la imagen y reputación de la entidad, golpea fuertemente la confianza de la ciudadanía en relación al uso de estas tarjetas y quedan mantos de dudas entre el regulador, los bancos y los diversos actores de la industria.

A este respecto, es importante señalar que la evidencia da cuenta que la industria financiera es de las más maduras en nuestro país en materia de gestión de riesgos e incluso varias entidades han implementado modelos de gestión integral de riesgos, basados en ISO 31.000, ISO 27.001, COSO ERM y Basilea I y II, pero a todas luces falta para llegar a un estado del arte que permita estar relativamente tranquilos.

Quizás las entidades de apoyo al giro bancario, están un poco más atrás en la rigurosidad de estos modelos, que deben ser holísticos y apuntar con énfasis a los procesos core business, pero claramente están por sobre la media del resto de las industrias en relación a iniciativas de gestión de riesgos y automatización de las mismas.

Esto nos lleva a reflexionar respecto a que definitivamente la robótica e inteligencia artificial de la mano de data analytics, juegan y seguirán jugando un rol esencial en relación con la implementación de medidas mitigatorias basadas en smart risk, para disminuir este tipo de riesgos, que día a día se hacen más sofisticados y complejos de controlar.

Aquí es donde están los grandes desafíos de la ciberseguridad para la revolución digital que estamos viviendo, es decir, en el uso de big data, data analytics, robótica e inteligencia artificial, lo que debe ser parte de la arquitectura de los modelos de monitoreo continuo preventivo.

La primera y segunda línea de defensa (gerencias operativas y funciones de aseguramiento respectivamente), tienen un desafío no menor y no solamente en la industria financiera, sino que en todas aquellas industrias expuestas con tecnologías dominantes y para la tercera línea de defensa, no deja de ser un gran reto todo esto sin duda alguna, pensando en modelos de auditoría continua.

Consideraciones implementación de solución Risk Management (ERM)

Les comparto último reporte de Gartner respecto a soluciones de clase mundial para la Gestión Integral de Riesgos, lo cual da cuenta de funcionalidades alineadas con buenas prácticas como COSO ERM 2017.

Hay que recordar que antes de implementar una solución para la Gestión Integral de Riesgos (ERM), es importante considerar:

– Alto estándar de cumplimiento respecto a prácticas de ciberseguridad, puesto que si se trata de soluciones SaaS (Software como servicio), si no cuenta con altos estándares de seguridad, la información estratégica y confidencial de las entidades queda absolutamente expuesta. Esta condición debería ser certificada en materia de ciberseguridad.

– Niveles de respaldo adecuados y certificados.

– Alta usabilidad, es decir, que sea una solución intuitiva para los usuarios finales.

– Interfaz gráfica compatible con reportabilidad para los niveles de alta dirección y el directorio.

– Que se pueda integrar a las diversas funciones de la organización de forma holística. Primera, segunda y tercera línea de defensa.

– Que se pueda generar indicadores claves de riesgo (KRI) y que los mismos sea posible vincularlos con los indicadores claves de gestión (KPI) de la organización, conforme a como lo establece COSO ERM 2017.

Ver último reporte de GARTNER https://grclatam-my.sharepoint.com/:b:/p/phernandez/EQ7Lu4pSh71NuGzmMWxJqskBDj-DnmzlMgBBHRaHfGIX5w?e=nvwhod

Crea un blog o un sitio web gratuitos con WordPress.com.

Subir ↑