in 2013 tr ds 01 02 - documento soporte isaca-atl-auditing sap grc-081712
TRANSCRIPT
DOCUMENTO SOPORTE TRAINING
SESION “AUDITING SAP
GRC”
Tlf: (+34) 886 113 106 - E-mail: [email protected] - twitter: @Inprosec
www.inprosec.com
1
AUDITING SAP GRC
INTRODUCCIÓN
Este un documento de soporte para la presentación de ISACA sobre “Auditing SAP GRC” de Cocacola que data del 17 de Agosto de 2012.
SAP SECURITY
OVERVIEW
PIRÁMIDE DE ACCESO (BOTTOM -> UP)
Tlf: (+34) 886 113 106 - E-mail: [email protected] - twitter: @Inprosec
www.inprosec.com
2
En la siguiente pirámide podemos ver los diferentes niveles en los que se diseñan y se asig -nan los accesos a los usuarios en SAP. Empieza desde la base (desde abajo) con los campos de autorización de los objetos de autorización, a los cuales hay que darle valores concretos (authorization field values):
CONCEPTOS BÁSICOS
Presentamos los conceptos básicos en los que se basa el acceso de usuarios de SAP (real):
Cuando un usuario se conecta (“loggea”) a SAP, todos los objetos de autorización y sus campos con los valores correspondientes (que han sido previamente asignados al usuario a través de roles o perfiles) se cargan en su “user master record” (se le podría llamar también “authorizations buffer”).
Cuando un usuario intenta ejecutar una acción (transacción) en SAP, los objetos de autorización y sus objetos dentro del buffer se verifican de manera programática.
Con los campos de los objetos de autorización se pueden restringir los accesos de un usuario en base a tres áreas clave:
1. Display vs Maintain2. Información Organizativa (Organizational Values: Company Codes, Sales/
Purchase Organizations, …).3. Otros campos y valores de restricción para objetos de autorización
individuales y concretos (por ejemplo: tipo de documento, tipo de operación, nombre de archivo, de grupo de usuario,…).
PROBLEMAS HABITUALES
Listamos aquí los 6 problemas principales que afectan al área de Roles y Autorizaciones en SAP (el detalle se encuentra en la presentación a la que referencia este documento):
Tlf: (+34) 886 113 106 - E-mail: [email protected] - twitter: @Inprosec
www.inprosec.com
3
Inheritance Broad Access Designed in Roles Assignment of Roles with Broad Access Segregation of Duties and Sensitive Access No Visibility into Potential Issues No Prevention of New Problems
SAP GRC OVERVIEW
HISTORIA Y MÓDULOS
En la siguiente tabla podemos ver los nombres que las 4 herramientas de SAP Access Con-trols han tenido en versiones anteriores y tienen actualmente en la última versión v10:
Tlf: (+34) 886 113 106 - E-mail: [email protected] - twitter: @Inprosec
www.inprosec.com
4
FUNCIONALIDAD POR MÓDULO
En la siguiente tabla podemos ver descripción y principales funcionalidades de cada una de las herramientas, pero prestando especial atención a ARA (Access Risk Analysis) y EAM (Emergency Access Management).
FUNCIONALIDAD Y TERMINOLOGÍA
Algunos conceptos son:
En ARA se tratan 2 tipos de Riesgos:o Riesgos de SoD o SoF (Segregación de Funciones/Duties): Combinaciones
críticas de 2 o más actividades (o funciones) concretas.o Riesgo de Acceso Sensible (o Crítico según terminología SAP): El riesgo de
que un usuario (o grupo usuarios o roles) tengan acceso a una actividad (o función) crítica concreta.
Conjunto de Reglas (Ruleset):o Se trata de una agrupación concreta de riesgos. Se utiliza para hacer
referencia a todo el conjunto de riesgos (de una organización) o para diferenciar un conjunto de riesgos de otro, porque aplican a distintas organizaciones o divisiones,…
o Los riesgos están formados por agrupación de funciones (GRC functions).o Las funciones están formadas por agrupación de varias/os transacciones
y/o (otros) objetos de autorización. Firefighter:
Tlf: (+34) 886 113 106 - E-mail: [email protected] - twitter: @Inprosec
www.inprosec.com
5
o Es el primer nombre para la herramienta relacionada con accesos de emergencia. Firefighter -> SPM -> EAM.
o También hace referencia al usuario de un acceso de emergencia.o Es una ruta alternativa para proporcionar un acceso elevado
temporalmente y tenerlo monitorizado (mediante notificaciones y resgistros/logs).
SOD RISK Y SENSITIVE ACCESS RISK
En la presentación se presentan gráficamente los dos conceptos con sus características, que las diferencias a la una de la otra.
PIRAMIDE DE UN CONJUNTO DE REGLAS / RULESET (TOP -> DOWN)
A continuación se presenta en una pirámide que nos muestra como se divide el conjunto de reglas (ruleset) en elementos hasta llegar a los permisos (autorizaciones concretas: valo-res para los campos de los objetos):
ÁREAS DE RIESGO DE SAP SECURITY QUE CUBRE SAP GRC
El uso de SAP GRC (principalmente ARA) permite tener visibilidad sobre los conflictos de SoD, los problemas por “herencia” (acumulación) de accesos y puede prevenir la asignación de roles que provocan riesgos/problemas:
Comprobar que no existen conflictos de SoD en roles simples (Single Roles) Identificar y revisar el Acceso Sensible (Sensitive Access) asignado a usuarios.
Tlf: (+34) 886 113 106 - E-mail: [email protected] - twitter: @Inprosec
www.inprosec.com
6
Un proceso / fujograma (de ARM o BRM) puede permitir la realización obligatoria del análisis de riesgos antes de asignar accesos a usuarios (prevención).
Tlf: (+34) 886 113 106 - E-mail: [email protected] - twitter: @Inprosec
www.inprosec.com
7
PROBLEMA HABITUALES
Listamos aquí los 6 problemas principales por áreas que afectan a SAP GRC:
Governance (Gobierno)o Identificar e incorporar nuevas funcionalidadeso Establecer propiedad/responsabilidad (“ownership”) sobre riesgos, roles y
controles Seguridad
o Limitar y controlar el acceso a la configuración y realización de cambios Configuración
o Los parámetros clave están configurados correctamenteo Los cambios son documentados y monitorizados (gestión del cambio)
Change Managemento Los cambios al conjunto de reglas (ruleset): riesgos y funciones, son autori-
zados y aprobados.
AUDITANDO SAP GRC
Hemos llegado a la sección principal y que da el nombre a la sesión de formación.
AUDITANDO SAP GRC: GOBIERNO
El Gobierno es fundamental para GRC en el largo plazo: un GRC sostenible y continuamente mejorable. Permite o facilita:
La realización de cambios al entorno GRC. Establecer las propiedades y responsabilidades necesarias. Conducir las decisiones con acciones concretas (“remediation”).
Las áreas clave a considerar para el equipo de Gobierno son las siguientes: Propiedad (“Ownership”) sobre Riesgos (de GRC), Roles (de SAP) y Controles Com-
pensatorios (“Mitigating Controls”). Nivel de Riesgo para los Riesgos de GRC y Expectativas (propuestas de tolerancias). Nuevas funcionalidades (a incorporar).
Gobierno: Propiedad (“Ownership”)
¿Quién aprueba el acceso? (y a qué nivel):
Basado en roles (aprobación sobre datos/información: roles) -> Role Approver (como “Data Owner”: propietario de los datos).
Manager (Line Manager: Superior gerárquico) Riesgo GRC Asignación de un Control Compensatorio (“Mitigating Control”)
Tlf: (+34) 886 113 106 - E-mail: [email protected] - twitter: @Inprosec
www.inprosec.com
8
Quién define los riesgos y las funciones y aprueba los cambios a los y las mismas?:
¿Qué se incluye dentro de un riesgo de GRC y dentro de una función GRC (como se determina)?
¿Cuál es el nivel de riesgo correspondiente?
Gobierno: Niveles de Riesgo
¿Qué significa cada nivel de riesgo? (criterio):
Tienen que tener los usuarios acceso a las transacciones relacionadas? Cuáles son las expectativas para cada nivel de riesgo?
o Número de conflictos (ocurrencias) de riesgo permitidas (límite/umbral).o Periodo (máximo) de corrección (“remediation”).
Gobierno: Nueva Funcionalidad
¿Cuál es el proceso para identificar nuevas funcionalidades (funciones) que han sido añadi-das al sistema?:
Transacciones (Standard) Módulos Transacciones “Custom” y/o Objetos de Autorizaciones standard nuevos o Custom.
¿Cómo se analizan y posteriormente se incluyen (si fuesen necesarias) dentro del ruleset? (quién es el responsable de que esto ocurra).
Gobierno: Procesos permanentes
Aprovisionamiento de Accesos (o de Usuarios)o Análisis de Riesgos (SoD / Sensitive) preventivo.o Aprobaciones apropiadas (Propietario del Role, Manager)
Accesos Periódicos de Usuarioso Análisis de Riesgos (SoD / Sensitive) detectivo.
Revisión de Controles Compensatorioso Revisar usuarios con Accesos Sensible (Sensitive) por necesidad del nego-
cio.
Tlf: (+34) 886 113 106 - E-mail: [email protected] - twitter: @Inprosec
www.inprosec.com
9
AUDITANDO SAP GRC: FUNCIONALIDAD STANDARD DE SAP
Auditando SAP GRC: Seguridad ABAP
La version 10 de SAP GRC se ejecuta en ABAP.
Hay que revisar IT Sensitive Access (como en cualquier sistema SAP ABAP):
User Management (SU01, PFCG, etc.) Change Management (STMS, SCC4, etc.) Configuration Management (SPRO, etc.)
Otras áreas de alto riesgo deben de ser revisadas, como en cualquier auditoría de seguri -dad de un sistema SAP (SAP Security Audit)
Auditando SAP GRC: Gestión de Cambios de Aplicación
Los procesos típicos de revisión de Gestión del Cambio (Cambios a Sistemas/Programas) para sistemas SAP se deben de llevar a cabo en GRC 10 (sistema ABAP). Es decir, se revisa -rán transportes:
Usar la STMS (Import Overview > Import History) para verificar la población de cambios (transportes) pasados a producción durante el período revisado/auditado.
Siempre que el cliente esté bloqueado (otro punto a revisar: si ha sido desbloquea-do y cuando), todos los cambios a la configuración, riesgos y funciones deben de ser transportados.
Revisar el estado (de bloqueo) del mandante (client) y el historial de cambio a tra-vés de la tabla T000 (y relacionadas).
AUDITANDO SAP GRC: AUDITANDO ARA (ACCESS RISK ANALYSIS)
Auditando ARA: Seguridad ARA
ARA es el Intefaz Web a SAP GRC para análisis de riesgos.
Roles de ARA y GRC (a revisar):
SAP_GRAC_ALL (application administrator role) SAP_GRAC_SETUP (access to setup and customize GRC AC) SAP_GRAC_RULE_SETUP (define and update rules)
El acceso más restringido debe de ser el del Administrador GRC (SAP_GRAC_ALL).
Auditando ARA: Configuración ARA
Tlf: (+34) 886 113 106 - E-mail: [email protected] - twitter: @Inprosec
www.inprosec.com
10
A continuación presentamos la configuración clave (valores por defecto y recomendados):
Toda la configuración se realiza desde la transacción SPRO, por lo tanto ya tenemos otro acceso a revisar.
Se pueden cambiar los valores por defecto! (al hacer el análisis de riesgos)
Otra configuración clave (registro de cambios):
Tlf: (+34) 886 113 106 - E-mail: [email protected] - twitter: @Inprosec
www.inprosec.com
11
Cambio de los valores por defecto:
Tlf: (+34) 886 113 106 - E-mail: [email protected] - twitter: @Inprosec
www.inprosec.com
12
Auditando ARA: Cambios al Conjunto de Reglas de ARA
Cambios al conjunto de reglas:
Se ejecuta el Informe: “Reports and Analytics > Audit Reports > Change Log Report”o Filtrar por Función, Riesgo, Conjunto de reglas (ruleset) y Regla de Organi-
zación (Organization Rule).o Filtrar por campo “Changed On” (en función del período auditado).o Esto nos da la población de cambios a revisar
Los cambios deben haber seguido el procedimiento de gestión de cambios corres-pondiente (primero “walkthrough” y luego “testing”): aprobaciones por parte de las personas autorizadas.
AUDITANDO SAP GRC: AUDITANDO EAM (EMERGENCY ACCESS MANAGEMENT)
Auditando EAM: Seguridad EAM
EAM es Emergency Access Management, el módulo de Gestión de Accesos de Emergencia de SAP GRC. Se conoce comunmente como Firefighter (bombero o “apaga-fuegos”).
Roles de EAM (a revisar):
SAP_GRAC_SUPER_USER_MGMT_ADMIN (EAM Administrator role)
Auditando EAM: Configuración EAM
A continuación presentamos la configuración clave (valores por defecto y recomendados):
Auditando EAM: Otras áreas de EAM a auditar
Otros elementos a revisar son los siguientes:
Análisis del número de IDs (EAM IDs), EAM Owners y EAM Controllers; con los si -guientes informes clave:
o “Setup > Superuser Assignment > Owners”o “Setup > Superuser Assignment > Controllers”o “Reports and Analytics > EAM Reports”
Tlf: (+34) 886 113 106 - E-mail: [email protected] - twitter: @Inprosec
www.inprosec.com
13
Usar los siguientes criterios para el análisis:o Número de Owners y Controllers únicos (distintos).o EAM IDs con el mismo Owner y Controller.o Número de EAM IDs únicos (distintos) en todos los Sistemas y Mandantes.o Los 5 Owners con más EAM IDs y el número de IDs bajo su supervisión.o Número de Logins por EAM ID.o Tiempo medio, máximo y mínimo para revisar los Registros de Auditoría
(Audit Logs).o Número de Registros (logs) por Controller.
AUDITANDO SAP GRC: PROBLEMAS HABITUALES AL AUDITAR
Sobre el Conjunto de Reglas y los cambios al mismo: Los cambios al ruleset necesitan documentación de soporte válida (evidencias)
o Normalmente eliminar o deshabilitar un elemento provoca que la regla se haga más amplia (más abierta) pudiendo incrementar el número de falsos positivos.
Los cambios necesitan consenso (y aprobación) por parte del comité de gobierno.o Ya que tienen un impacto importante sobre el “reporting” y los Controles
compensatorios necesarios.Los Controles Compensatorios no corrigen o eliminan los riesgos de SoD (solo el “remedia-tion” lo previene):
Ejemplo: Control Compensatorio de Riesgo de SoD “PO Maintenance vs PO Appro-val”
o Un Control Compensatorio erróneo es: Las compras son aprobadas antes de ser realizadas. Si la compra ya ha sido aprobada (por el mismo usuario) el riesgo ya ha ocurrido!
o El correcto sería: Se revisan los pedidos para comprobar que los pedidos son aprobados por un usuario distinto del que lo ha realizado.
Respecto a los Procesos de Negocio (distintos): Intentar resolver riesgos de SoD en o con áreas en concreto (cuando pueden ser
cross área o cross proceso). Diferentes métodos de aprovisionamiento (como opuesto a un solo proceso que
asegura la aplicación de los controles). Corrección (Remediation) de Conflictos:
o ¿Es la mitigación un proceso periódico o se revisa?o ¿Existen controles de aplicación como prevención? ¿Se verifica su
eficacia/eficiencia?
Respecto a las configuraciones: No están configuradas para registrar todos los cambios (todos los tipos).
Tlf: (+34) 886 113 106 - E-mail: [email protected] - twitter: @Inprosec
www.inprosec.com
14
No revisar los usuarios bloqueados por defecto (pudiendo ser una situación tempo-ral).
Algunos problemas habituales en EAM son: Abuso de uso (Uso excesivo): Número de EAM IDs, Número de Entradas (“logins”).
Una emergencia no debe de ser habitual. Acceso Excesivo (SAP_ALL o roles extensos). La Best Practice son Accesos a Fucio-
nes o Tareas Únicas. Abuso de asignaciones: EAM IDs asignados a muchos usuarios y por períodos muy
grandes o indefinidos. Un uso común (necesitado por muchos) no debe ser de emergencia o excepción, esconce un modelo de roles inficiente.
Tlf: (+34) 886 113 106 - E-mail: [email protected] - twitter: @Inprosec
www.inprosec.com
15