Security Audit

Surity Authorization QuestionsTo Answer Before Going Live!

In R/3, users’ access capabilities are determined primarily by their user master records, authorization profiles, and authorization value sets. Users who are able to change user master records, profiles and/or authorization value sets need to be controlled to ensure that user access is consistent with management’s procedures and guidelines. The system provides a number of standard authorization objects that can be used for this purpose.The following questions should be answered before going live:

  1. Which users have the ability to change system parameters?
  2. What procedures are followed for changing system parameters?
  3. Is a report of system parameters and changes to those parameters produced and reviewed on a regular basis?
  4. Has there been a user master record created for SAP*?
  5. Has the default password for SAP* been changed?
  6. Has SAP* been placed in the group SUPER?
  7. Which users are authorized to maintain the group SUPER?
  8. Have the capabilities of SAP* been restricted and a secret super user, with a new password, created?
  9. Has the default password for DDIC been changed
  10. What controls have been implemented to ensure that no development (e.g., changing DYNPROs) takes place in a production environment?
  11. Do any users have S_EDITOR authorization object on the production system?
  12. What procedures are in place to identify and lock transactions that are potentially dangerous and not normally required?
  13. Detect transaction that do not have an authorization check ?
  14. Which users have the ability to lock and unlock transactions?
  15. Which users are able to alter and delete the additional authorization checks defined in table TSTC?
  16. Which users have been defined as “Batch Administrators” and is this access appropriate?
  17. Are the functions that users can perform on background job adequately restricted using the Operations on Batch Jobs object?
  18. Have “Batch Users” been set up that enable users to run jobs in the background that they are not authorized to run in the foreground? If so, is the ability of users to specify these “Batch Users” adequately restricted by the Batch User Name object?
  19. Are there adequate procedures to ensure that errors in background jobs are detected and corrected?
  20. What information is input into SAP using batch input?
  21. Does system software adequately restrict users from accessing the batch input session files?
  22. Is the Batch Input object (S_BDC_MONI) used to adequately restrict functions that users may perform on batch input sessions?
  23. What procedures are followed when submitting a batch job?
  24. Do any users have access to the ABAP/4 Dictionary?
  25. Does management review the ABAP/4 Dictionary information system to determine whether any unauthorized changes have been made to the ABAP/4 Dictionary?
  26. Is there a policy that deals with unused table entries?
  27. Are there any unused table entries that have not yet been deleted?
  28. What users have the ability to change tables (object Table Maintenance)(S_TABU_DIS)?
  29. Have all the tables been assigned to appropriate authorization classes in table TDDAT?
  30. Do the authorization classes that have been assigned to users adequately restrict them to updating only necessary tables?
  31. Have critical tables been identified and steps taken to ensure that changes to these tables are logged and the logs followed up?
  32. Are there adequate procedures for copying tables from one client to another and is the access capability adequate?
  33. Which users have the ability to run ABAPs (object S_PROGRAM)?
  34. Are all ABAPs assigned to specific user authorization groups?
  35. Are there programming standards to ensure that authorization checking logic is built into all user written ABAPs using the AUTHORITY-CHECK statement?
  36. Are users restricted by the S_PROGRAM authorization object to only those ABAP authorization groups that are required for their job functions?
  37. Do any users on the production system have the ability to edit or write ABAPs (authorization object S_EDITOR)?
  38. Is the ability of ABAP programmers to include SQL statements in ABAPs appropriately restricted?
  39. What policies and procedures are followed to prevent users from writing down their passwords?
  40. Is the need for password confidentiality communicated to users?
  41. Are the system profile parameters for minimum password length, password expiration period, and number of login failures allowed set to adequate values?
  42. Are history logs reviewed for possible access violations?
  43. Does each user have a unique user ID and password?
  44. Are there policies and procedures over the granting of user access?
  45. Is the security function separated from users and development?
  46. Are security administrators appropriately restricted as to which user groups (User Groups), profiles (Authorization Profile), and authorizations (Authorizations) they are able to work?
  47. Is the ability to modify user master records segregated from the ability to modify profiles and value sets?
  48. Is the ability to activate profiles and authorizations segregated from the ability to change profiles and authorizations?
  49. To what extent does the client make use of the SAP-EDI facilities?
  50. What messages are sent and do they contain financial information?
  51. Are the messages stored in a batch first or are they directly processed by the application?
  52. Has it been ensured that all security measures are in place before going into production?
  53. Is there a procedure to detect users whose accounts have been expired.
  54. Detect users who have not logged on to R/3 since a specific time.

R/3 Reports

The R/3 System is delivered with the following reports useful for auditting:

  1. RSUSR002: List of users according to complex selection criteria
  2. SAPMS013 Replace authorization profile with new profile
Security Auditultima modifica: 2009-10-20T20:44:00+02:00da pedroccda
Reposta per primo quest’articolo

Un pensiero su “Security Audit

Lascia un commento