Archive for the ‘auditoría.’ Category

Investigación Seguridad en SAP

Tuesday, May 4th, 2010

Un amigo del blog está realizando una investigación y le compartimos este espacio, para que ustedes puedan ayudarle en su investigación. Su participación será mas que agradecida por Sergio.

Estimados Miembros,

Estoy realizando una investigación para realizar un framework que se ejecute dentro de SAP a través de una trx Z… el cual realice un análisis de la seguridad del sistema SAP sobre el que se está ejecutando, esto serviría para todos los administradores Basis y Seguridad para conocer “la foto” de como esta su sistema a nivel de seguridad y ejecutar un plan de acción para corregir estos temas que se informen. En principio obviamente contemplaría los permisos asignados a usuarios que no sean administradores (Ej: SAP_ALL), los accesos a ciertas trx críticas de los distintos módulos, y el acceso a ciertas tablas… Uds., desde su experiencia, podrían ayudarme a contemplar otros tips que debería tener en cuenta para desarrollar esta herramienta?

VN:F [1.8.2_1042]
Rating: 0.0/5 (0 votes cast)
VN:F [1.8.2_1042]
Rating: +3 (from 3 votes)

Auditar SAP – Revisión (II)

Friday, November 6th, 2009

Continuando con los pasos que se habían detallado previamente, seguimos con los puntos a verificar en una auditoría:

6- Verificar que los permisos para trabajar con órdenes de transporte, tareas, y pasajes entre ambientes, estén asignados a las personas que deben cumplir los respectivos roles y que se cumpla la segregación de funciones. Verificar el objeto S_TRANSPRT, y los permisos a las transacciones SE09, SE10, STMS, etc (Ver este link sobre el sistema de transporte, y detalles sobre los objetos de autorización en este link)

7- Verificar que los programas Z (customizados) posean los authority check que requiramos. Esta búsqueda se puede realizar facilmente a través del programa RSABAPSC ejecutado desde la transacción SA38.

8- Revisar los parámetros definidos en el perfil de instancia (a través del reporte RSPARAM (SA38), o la transacción RZ11. (Más info)

9- Verificar todos los usuarios que posean permisos para desarrollar en ambientes productivos (Objeto S_DEVELOP con actividades 01, 02 o 06), y que también dispongan de la transacción SE38

10- Verificar que los permisos de debug con modificación de variables no estén asignados en un ambiente productivo (S_DEVELOP, actividade 02 y tipo de objeto DEBUG) (Más info…)

11- Ejecución de Querys, verificarlo revisando qué usuarios pueden ejecutar la transacción SQ01 y el objeto S_QUERY con 02 o 23.

En un próximo post seguiremos profundizando con el programa de auditoría que venimos elaborando en este blog.

VN:F [1.8.2_1042]
Rating: 5.0/5 (4 votes cast)
VN:F [1.8.2_1042]
Rating: +4 (from 4 votes)

Auditar SAP – Revisión (I)

Wednesday, September 23rd, 2009

En el presente gráfico podemos observar la pirámide de una auditoría completa, pero identificando que en este primer esquema nos vamos a concentrar en la auditoría del Sistema Basis de SAP

image

Recuerden que los primeros pasos a seguir los detallamos en el primer post, y en el presente ya ahondaremos en los primeros controles técnicos a realizar.

1- Verificar el acceso al customizing, específicamente a la transacción SPRO por parte de los usuarios y los permisos del objeto S_IMG_ACTV. Lo ideal es restringir estos permisos a los usuarios en general y solo usuarios de emergencia o funcionales puedan visualizar (03) el customizing en pos de la solución de problemas de desarrollo. Adicionalmente podrían verificarse que no existan permisos innecesarios directamente a muchas de las transacciones del customizing (O*).

Este control es independiente de los permisos definidos para el mandante en general mediante la transacción SCC4, ya que se busca restringir los permisos a fin de evitar que un mandante abierto por error pueda ser modificado, y como siempre también, evitar el otorgamiento de permisos innecesarios.

2- Restringir el acceso a la transacción SCC4 para evitar la gestión del mandante por usuarios no autorizados.

3- Verificar en la transacción SCC4 la configuración del mandante, de forma de no permitir cambios en un mandante productivo, así como tampoco debería permitirse la ejecución de CAATs o eCAATs, ni sobrescribir el mandante (S_TABU_DIS ACTVT=2, Group=SS; S_ADMI_FCD=T000; S_TABU_CLI=X) (Más info)

4- Revisar los permisos otorgados mediante S_TABU_DIS a los usuarios (permisos de modificación directa de tablas) evitando otorgar cualquier permiso a todas las tablas o tablas del sistema (* o SS, entre otros), controlar los permisos a las tablas Z* y que las mismas tengan grupos de autorización vinculados. Verificar en conjunto con el acceso a las transacciones SE16, SE16N, SE17, SM30, SM31 y variantes. (Más info)

5- Verificar la posibilidad de ejecutar programas directamente por parte de usuarios finales (acceso a transacciones SA38, SE38, SE80, SE37), en conjunto con el objeto S_PROGRAM, y la existencia de programas sin grupo de autorización (tabla TRDIR campo SECU). (Más info)

Esto es solo un comienzo de una serie de artículos que detallarán un plan de auditoría y los pasos a seguir. Cualquier sugerencia es bienvenida.

VN:F [1.8.2_1042]
Rating: 4.9/5 (7 votes cast)
VN:F [1.8.2_1042]
Rating: +3 (from 3 votes)

Seminario sobre Seguridad SAP en Buenos Aires

Tuesday, August 11th, 2009

Hacia fines del mes de septiembre estaremos dictando un seminario de un día sobre seguridad en la plataforma SAP en Argentina, a través de la consultora EZGROUP de Buenos Aires.

Si están interesados en participar de la actividad o conocen a alguien que así lo desee pueden ver los detalles del costo, fecha y lugar en el presente link.

VN:F [1.8.2_1042]
Rating: 0.0/5 (0 votes cast)
VN:F [1.8.2_1042]
Rating: 0 (from 0 votes)

Auditar SAP – Introducción

Thursday, July 30th, 2009

A lo largo de varios post en este blog vimos desde artículos introductorios, hasta algunas pequeñas herramientas que SAP nos brinda para ayudarnos a configurar su seguridad.

En este post, y los subsiguientes sobre “Auditar SAP“, trataremos de abarcar paso a paso, las tareas a realizar para evaluar la seguridad de un sistema. En algunos casos repitiéndo conceptos ya definidos en anteriores artículos del blog, e incorporando otros nuevos.

Lo principal a fines de empezar, es entender el alcance de la auditoría que vamos a realizar. Metodológicamente, una auditoría del sistema se concentra en revisar la configuración del mismo, con el fin de exponer las falencias que puedan poner en jaque la seguridad de la información que en el reside.

Tenemos que comenzar entendiendo que el sistema SAP como ERP, es un sistema que puede aportar un alto grado de seguridad en las operaciones, y posee un buen número de controles embebidos en el mismo, tanto configurables como inherentes. Pero esta seguridad tiene que ser configurada, para que sea efectiva.

Y también es importante destacar una característica particular de SAP a la hora de auditarlo, y es que en el mismo no solo se configuran y por consiguiente, se revisan, los controles de aplicación (controles internos del negocio, validaciones de datos, etc) si no que también un gran número de controles de base o generales deben efectuarse en el mismo, ya que desde dentro de un sistema SAP es posible acceder directamente a las tablas de base de datos, ejecutar programas, ver código fuente, ejecutar comandos de sistema operativo, apagar el servicio, realizar debugging, y un largo etc de actividades que en otros sistemas deben controlarse “por fuera de la aplicación” y en el caso de SAP deben controlarse en “ambos lugares”. Y resaltamos “ambos lugares” porque incluso en muchas revisiones de seguridad se pierde el foco y se controlan los permisos dentro del sistema con el fin de verificar controles generales y de aplicación, abandonando un poco el control sobre los servidores de base de datos, de aplicación, etc.

Igualmente como corresponde a este blog, nos ocuparemos, al menos en principio, a la revisión de la seguridad específica en la plataforma SAP y posteriormente incorporaremos tips a verificar en las plataformas subyacentes (pero es tan variado este control, como plataformas y bases de datos sobre las que puede instalarse SAP).

Antes de empezar efectivamente con la auditoría sobre el sistema, hay cierta información que uno debería recopilar, y vamos a explicar porque:

- Versión, o versiones de SAP sobre la que se va a trabajar - Distintos parámetros y configuraciones son posibles dependiendo de la versión del sistema, como así también nuestras recomendaciones varí an según la versión de SAP, salvo que nuestra recomendación se actualizar la versión ;-)

- Cualquier informa de auditoría previo – Nos puede dar una idea general del sistema, aunque la revisión deba hacerse de cero.

- Landscape, número y nombre de instancias - Por motivos obvios es necesario conocer el landscape sobre el que se trabaja, servidores involucrados, application servers lógicos, físicos, ambientes de desarrollo, pruebas, producción etc. Es importante que los ambientes se encuentren correctamente aislados el uno del otro.

- Sistema operativo y Base de Datos (Nombre, versiones, etc) – Averiguar el sistema operativo sobre el que está instalado el application server y la base de datos sobre la que corre es importante tanto para  la revisión de software de base, como para algunas transacciones específicas del sistema según donde se instale.

- Mandantes - Conocer los mandantes existentes y el objetivo de los mismos es necesario por las mismas razones que las instancias, y para conocer las necesidades de auditoría.

- Cantidad de usuarios - Complejidad y extensión de la revisión.

- Módulos utilizados/implementados - Para conocer el alcance de la revisión, una aproximación del número de roles involucrados y complejidad, la cual puede depender de los módulos (sobre todo si son incluidos módulos de industria específicos que si bien pueden no agregar muchos controles de seguridad, pueden ser desconocidos para nosotros)

- Esquema general de Sociedades, Centros, Sociedades CO, y otros datos funcionales - Resultan útiles a la hora de evaluar un esquema de roles acorde a las necesidades de la organización.

- Número de desarrollos ABAP o Z - Nos servirá como dato sobre la complejidad del sistema y de su diferencia con el sistema estándar. Este dato es de suma importancia a la hora de saber lo complejo del análisis de roles y en un posible caso de reingeniería de los mismos.

- Toda la documentación del área de sistema definiendo procedimientos, misiones y funciones, organigrama, nómina de empleados del área de sistemas con funciones, monitoreo, etc - Es útil con el fin de confirmar que estos procedimientos y puestos se vean reflejados en la estructura del sistema, y que los permisos de usuarios en el sistema no excedan o limiten sus responsabilidades. Es importante conocer el procedo de gestión de usuarios y accesos, para ver que el mismo se refleje de manera adecuada en el sistema.

- Procedimiento de cambios, y cambios de emergencia Es importante contar con este procedimiento escrito y de no ser así relevar el proceso que debería ser, para comprobar que el sistema de transporte y los permisos estén configurados de manera acorde.

- Procedimiento de ABM de Usuarios y rolesEs de suma importancia conocer el procedimiento para poder contrastar la realidad del sistema con tra lo teóricamente definido, y si lo teóricamente definido es correcto o adecuado.

- Usuarios de Interfaz o no nomenclados - Es importante conocer de antemano cuales son estos usuarios para verificar su correcta parametrización o recomendar su eliminación.

- Esquema de Nomenclatura de roles - Como son nomenclados los roles es vital para entender la estructura de los mismos.

- Nomenclatura de usuarios - Para verificar que se cumpla y comprender la misma.

- Metodología de Acceso al sistema - A través del SAP GUI, Web, interfaz desde otras aplicaciones, usuarios de internet, externos, SAP Router, Citrix. Es importante determinarlo con el fin de verificar el alcance y saber con que estamos tratando.

- Implementación de Seguridad a través de la estructura organizativa, o la utilización de perfiles estructurales - Cambio nuestro punto de vista sobre como revisar la seguridad del sistema.

- Topología de Red del sistema SAP - Realizar un análisis preliminar de la instalación y su seguridad

- Planes de continuidad del sistema - Además de lo obvio, para conocer la redundancia, el riesgo y otros sistema que debamos verificar.

- Existencia de permisos de visualización para auditar el sistema - Lo dejamos para el final, pero es de suma importancia poseer permisos a todo lo que necesitemos, pero sin modificación, para poder trabajar con tranquilidad sobre el sistema. Ya que de ser negado el acceso interactivo al sistema tendremos que encarar una auditoría COMPLETAMENTE DISTINTA.

Evidentemente todavía no abordamos nada técnico, pero es un paso esencial el de recopilar toda la información que sea posible. Si a ustedes se les ocurre alguna otra información específica a recopilar no duden en hacer comentarios en este artículo.

En el próximo abordaremos ya más en detalle los temas técnicos y cómo proseguimos con una auditoría del sistema.

Continúa aquí…

VN:F [1.8.2_1042]
Rating: 5.0/5 (3 votes cast)
VN:F [1.8.2_1042]
Rating: +8 (from 8 votes)

AIS – Sistema de Información de Auditoría

Wednesday, July 8th, 2009

Las necesidades organizacionales muchas veces llevan a que se efectuen auditorías sobre los sistemas que las empresas tienen en pos de cumplir con requerimientos tanto internos, como externos.

SAP es una herramienta desarrolalda para las grandes corporaciones, y por ello es que dispone de facilidades para realizar auditorías sobre el mismo, que no es lo mismo que decir que es fácil realizar una auditoría de SAP.

En el presente post vamos a hacer un breve resumen del Sistema de Información de Auditoría (AIS), las posiblidades que nos brinda y como utilizarlo.

En las versiones más viejas de SAP, existía una transacción llamada SECR, a través de la cual se accedía a los distintos reportes. Por cuestiones de compatibilidad en las versiones más nuevas se mantiene, aunque está obsoleta.

El AIS de las nuevas versiones (posteriores a la 4.6c) está conformado por un conjunto de roles, los cuales habilitan a realizar distintas actividades en el sistema. Mediante la generación y posteriores asignación de los mismos a los usuarios finales, se otorgan permisos para realizar diferentes reportes y queries sobre el sistema.

Cuando estos roles son asignados a un usuario el mismo dispone de un menú de árbol especial, donde tiene numerosos reportes y acceso a transacciones que pueden brindar información útil para realizar una auditoría.

Los roles que forman parte del AIS son todos los que poseen la siguiente estructura de nombre “SAP*AUDITOR*“, existen numerosos roles simples y también dos compuestos que integran varios otros, SAP_AUDITOR (auditor general) y SAP_AUDITOR_TAX (auditor de impuestos).

El rol SAP_AUDITOR está pensado para una auditoría general de controles y datos en el sistema, en cambio el SAP_AUDITOR_TAX como su nombre lo indica está mayormente enfocado al auditor de impuestos (accesos a la contabilidad en su mayoría)

Estos roles simples también tienen unas características particulares. Existen los roles como SAP_CA_AUDITOR_SYSTEM el cual no contiene menú alguno, solo objetos de autorización que nos brindan permisos tanto de visualización como de modificación en algunas transacciones. A su vez, también encontramos el SAP_CA_AUDITOR_SYSTEM_DISPLAY, el cual solamente permite la visualización de datos, y es más adecuado para un auditor en muchas situaciones.

Estos roles como dijimos no contienen menú alguno, y el menú está dado por otros roles, que no tienen autorizaciones, solo el menú:

SAP_AUDITOR_SA_BC (AIS – Sistema auditoría)
SAP_AUDITOR_SA_BC_CCM_USR   AIS (Sist.auditoría – Usuarios y autorizaciones)
SAP_AUDITOR_SA_BC_CUS_TOL   AIS (Sist.auditoría – Repository / Tablas)

Esta flexibilidad que nos brinda SAP, permite justamente combinarlos para otorgar con el mismo menú, permisos de visualización o modificación.

Siempre debemos respetar la idea global, de no trabajar con los roles estándar si no realizar copias “Z” de los mismos para evitar inconvenientes en upgrade o posibles parches.

En un próximo post profundizaremos en las posibilidades de reporting que nos brindan los roles de AIS, y como encarar una auditoría a través del uso del rol.

VN:F [1.8.2_1042]
Rating: 4.3/5 (4 votes cast)
VN:F [1.8.2_1042]
Rating: 0 (from 0 votes)

Auditoría de Tablas en SAP

Friday, July 3rd, 2009

A la hora de auditar un sistema, una pregunta frecuente es “Cómo monitoreo las modificaciones a los datos”. Con este fin, puede resultar interesante monitorear las modificaciones que determinadas tablas puedan tener en sus datos. SAP nos brinda la posibilidad de registrar las modificaciones de una o varias tablas de manera nativa.

Cabe destacar que este registro es distinto de los “documentos de modificación” que en su mayoría registran las modificaciones a datos maestros y otras informaciones críticas del sistema. El registro de documentos de modificación se encuentra activado por defecto en el sistema y no necesita de una configuración específica para que comience a registrar las modificaciones.

¿Cómo activar la auditoría de tablas?

Para activar la auditoría de modificación de tablas se necesita configurar en un parámetro del sistema rec/client. Mediante el mismo se puede especificar que la grabación se va a realizar para un mandante específico (separados por coma) o para todos (ALL en lugar de *).

Una vez que este parámetro tiene un valor asignado y SAP fue inciado con el parámetro ya definido, los datos de modificación de tablas se comienzan a registrar.

Ahora falta definir (en realidad hay que hacerlo antes de activar la auditoría), que tablas queremos que sean monitoreadas. Esto se hace a través del flag “Log data changes” de la vista técnica de la transacción SE13. Cabe destacar que muchas tablas vienen activadas por defecto y el hecho de actibar el rec/client sin verificar previamente las tablas que graban información puede tener un impacto importante en la performance.

Igualmente también es importante destacar que muchas de las tablas que vienen marcadas por defecto son de customizing y no debieran tener un mayor impacto en cuestiones de performance.

En algunas implementaciones se opta por desactivar masivamente todas las tablas y solo marcar unas pocas para registrar. Si este es su caso, deberán modificar el flag de “Log” (PROTOKOLL) en la tabla DD09L. Para conocer todas las tablas con el flag activo se puede utilizar el reporte RSTBHIST.

La tabla en donde son guardados los registros de modificación es la DBTABLOG (antes DBTABPRT y objeto de archiving BC_DBLOGS), donde por cada modificación a una tabla con el flag seteado se guarda un registro. La consulta a la misma puede hacerse desde la transacción SCU3 o desde el reporte RSTBHIST (SA38).

Una salvedad a tener en cuenta, es que a pesar de su nombre “Log de modificación de tablas”, lo que se registra son las modificaciones realizadas en SAP, no así las modificaciones a las tablas realizadas directamente sobre la base de datos y fuera del sistema. Las mismas en todo caso debieran ser logueadas desde la misma base de datos.

Como comentario final, cabe destacar que una de las excusas para no implementar este tipo de auditoría es la baja en la performance, la cual puede ser muchas veces válida, pero no siempre. La auditoría de tablas se puede activar, pero con la precaución de utilizarla para tablas que no requieran constantes modificaciones, y haciéndolo de manera progresiva, comenzando por unas pocas e ir ampliando lentamente las tablas a monitorear para poder evaluar el impacto en la performance global del sistema.


VN:F [1.8.2_1042]
Rating: 4.7/5 (3 votes cast)
VN:F [1.8.2_1042]
Rating: 0 (from 0 votes)