1.

The SAP R/3 authorisation concept [Edit] The SAP R/3 authorisation concept permits the assignment of general and/or finel y detailed user authorisations. These assignments can reach down to the transact ion, field and field value level. These authorisations are centrally administere d in user master records. Actions by a user may require several authorisations. For example, to change a material master record, authorisations are required for the: Transaction 'change' Specific material type Views of the material master record General authorisation to work with the company code The resulting relationships can become very complex. The SAP R/3 authorisation c oncept is based on authorisation objects. Each authorisation object is a combina tion of authorisation fields. An authorisation always refers to an authorisation object and can contain intervals for the authorisation field values. Authorisat ion checks protect the functions or objects a user chooses. Standard-delivered S AP R/3 functions or objects have these checks embedded in the program logic. Authorisation administrators create authorisations that are assigned to users in collections called profiles. The Profile Generator (PG), a standard tool in SAP R/3, usually generates authorisations and authorisation profiles, although auth orisations can also be manually inserted into a profile. 2. Terminology [Edit] Authorisation Object Class Authorisation objects are grouped in logical groupings of authorisation object c lass. Authorisation Object Authorisation objects allow complex user authorisation checks. An authorisation object groups up to 10 authorisation fields in an 'AND' relationship. All the fi elds are checked simultaneously to check whether a user is allowed to perform a certain action. Users may only conduct an activity if they satisfy the authorisa tion check for each of the authorisation field in the authorisation object. Authorisation Field This is the smallest unit against which the authorisation check is done. The fie lds in an authorisation object are linked to data elements in the SAP ABAP Dicti onary. The permissible values constitute an authorisation. When an authorisation check takes place, the system checks the values that you have specified in an a uthorisation against those required to carrying out the action. Users may only c arry out the action if they satisfy the conditions for every field defined for a specific authorisation object. Authorisation An authorisation is the authority to perform a particular action in the SAP R/3 system based on a set of authorisation field values in an authorisation object. Each authorisation refers to exactly one authorisation object and one or more po ssible values for each authorisation field listed for that authorisation object. Authorisations are utilised in the user master record as roles. By themselves, authorisations do not exist. They only have meaning inside a role. Authorisation Profile Authorisation profile contains authorisations for different authorisation object s. User authorisations are assigned using authorisation profiles. Once a profile is changed, the changes will affect all users to whom this profile is assigned

and take effect only when the user logs on. Users who are logged on when the cha nge takes place remain unaffected during their current session, but when they lo g on again, their profile will change accordingly. A user's authorisations are l oaded into the user buffer only when they logon on. To automatically generate an authorisation profile, you must first create a role. Role A role is a set of functions/transactions describing activities or a specific wo rk area. The Account Receivable Accountant role, for example, contains authorisa tions to transactions and Reports needed by the accountants for their daily work . A role can be assigned to any number of users. Besides the normal SAP R/3 logo n users, you can also assign roles to object types such as jobs, organisation un its or positions. Besides the predefined SAP roles available in the system, you can also create your own custom roles. Composite Role & Single Role A composite role (also known as collective role) is a group of several different (single) roles. It is not possible to group composite roles into composite role s. Composite roles do not contain authorisation data. If you want to change the authorisation in a composite role, you must maintain the authorisation data in the (single) roles. Users assigned to a composite role are automatically assigne d to the corresponding (single) roles. The menu tree of a composite role is a co mbination of the menus of all the (single) roles it contained. Merging of menu t rees from (single) roles may lead to certain menu items being listed more than o nce. 3. How Authorisation Works [Edit] If Authorisation A allows the user to perform create, change and display activit ies in company codes 1000 and 2000. And Authorisation B allows the user to perform only display activity in company codes 1000, 2000 and 3000. Then a user who has authorisation A and authorisation B, can perform create, cha nge and display activities in company codes 1000 and 2000, and can only perform display activity in company code 3000. Authorisation Check This check decides whether a user is authorised to execute a particular action. Processes, functions and data access in SAP R/3 system can only be performed whe n user authorisations have been checked successfully in the respective system an d application programs. User Master Record User master record enables the user to log on to the SAP R/3 system and allow li mited access to functions and objects based on authorisation profiles. User mast er records are client-specific. You must maintain user master records for each c lient in an SAP system. 4. Generic User Id's [Edit] All users should have a unique identifier (user ID) for their personal and sole use to ensure that activities can be traced to the responsible individual. In ex ceptional circumstances where there is a clear business benefit the use of a sha red user ID for a group of users or a specific job can be used. Approval by mana gement should be documented for such cases. Additional controls may be required to maintain accountability. SAP*

The standard SAP user SAP* presents a particularly high risk because it contains full access rights to the SAP system and has standard passwords which are widel y known. SAP* should never be used in any system and shall be controlled via the following measures: Lock the user id SAP* Remove all profiles from user SAP* The ABAP report RSUSR003 should be run on a regular basis to check the security of the standard SAP users in all systems. Background batch user Background jobs are not to be dependent on an individual's user ID. Instead all jobs should be scheduled to run under a specific background job user ID. This us er should be a system user secured to an appropriate user group and will usually have wide access such as SAP_ALL. The ability to schedule a job under such a us er ID will be tightly controlled. Setting up Remote Communications There are minimum acceptable settings that must be followed when setting up an R FC for dial up connection (transaction code SM59). The following guidelines are to be adhered to: Access to transaction SM59 should be limited to only Basis Administration person nel. User accounts used, as interface accounts between two systems must be a non-dial og user type and assigned to the user group NON-DIALOG. SAP account setup for OSS connections Periodically, SAP will need to be able to log on to a client SAP system in order to look into OSS problems that have been submitted. Such requests will require three things be implemented: 1. Open service connection. SAP user account and password. Basis team to open appropriate service connection. Generally, requests are submitted for the non-production environments. However, from time to time, a request for production is submitted. Access to the producti on environment must only be for display and approval must be received from the c ustomer system owner. If the error can be duplicated in a non-production system, access should be granted in a non-production system FIRST. Access to a producti on system should be the last resort. The Basis team is responsible for opening and closing service connections. The S ecurity team is responsible for managing and setting up of user accounts needed by SAP. To facilitate the set up of an SAP user account and to more easily ident ify such accounts later on, standardisation is necessary. The following standards should be applied: User ID - Should be in the format SAP-xx, where xx is the application that is be ing researched (e.g.: SAP-BC, SAP-JV, and SAP-FI). This will allow for identifi cation (if anything is updated in the system) of the appropriate module. It als o allows for multiple SAP users to use the system at the same time and have a un ique id for each. Valid Until - have an end validity date

OSS service connections can only be opened for a maximum of 10 days. Profiles - In the non-production clients, it is recommended that the account be assigned the same access as the person making the request, assuming that ZZ role s are assigned and SAP_ALL and SAP_NEW are not assigned. This will allow all use r transactional access and support access. 5. System Security Parameter Settings [Edit] In addition to the standard R/3 authentication mechanism of each user requiring an individual user id and password the following system parameters should be set : In addition to the standard R/3 authentication mechanism of each user requiring an individual user id and password the following system parameters should be set : Parameter Setting Number of times user can attempt log on login/fails_to_user_lock = 4 4 times thereafter user locked Users locked due to incorrect logons login/failed_user_auto_unlock = 0 Users are not unlocked automatically Number of failed logins before a session is ended login/fails_to_session_end = 3 3 times thereafter session is ended Minimum length of password login/min_password_lng = 8 8 characters Password change enforced login/password_expiration_time = 35 Every 35 days Default client for a system login/system_client = nnn Main client User SAP* automatically created after deletion login/no_automatic_user_sapstar = 1 Switched off Authorisations in user buffer auth/auth_number_in_userbuffer = 3000 Set to Maximum (3000)

Profile Generator active in Production auth/no_check_in_some_cases = Y Profile Generator activated in Production RFC's called from ABAP programs perform authority check auth/rfc_authority_check = 1 Switched on Length of inactivity before user is logged out rdisp/gui_auto_logout = 7800 2 hour 6. Sensitive Transactions [Edit] There are many basis or development type functions that should not be available for end users in Production, such as programming, debug with replace, or transpo rt. These should be carefully evaluated and access restricted from business en d users. Most of these transactions are in Basis (beginning with S*), therefore , system-wide impact if used carelessly. Also, they will be flagged by audits a s a high-level risk factor. It is important to note that some of these transactions are still needed by appl ication support, basis, or security administrators. Access to them should be ca refully evaluated and granted where appropriate. There should also be an emergency exception policy in place to accommodate an em ergency request for access to these transactions in production. 7. General Development Standards [Edit] It is important that security is considered during the initial stages of develop ment design and build. The following areas need to be reviewed and communicated to the proper application team members and developers. Report Security Release 4.5 and later For systems implementing in SAP releases 4.6 or later, every report or program m ust be assigned a transaction code and then assigned to a role. Once the chang es have been transported to production, the user will immediately have access to the new functionality. Customer ABAP Security During the gathering and creation of ABAP specifications, serious consideration must be given to data security. Depending on the data level requirements, there are two options for securing ABAP reports or programs. 1. Transaction Level

The first level of security that is checked is at the transaction code level. A ll transaction codes are checked against authorisation object S_TCODE. If no da ta-level security is required, at a minimum, the execution of reports and progra ms can be controlled at this level. This assumes that the following are true: No restrictions are required for the data. Users who can run the report or prog

ram using this transaction code can see data or update all records without regar ds to organisation specific data. The value '*' or ranges of transaction codes are not assigned in any role for au thorisation object S_TCODE. 2. Data Level

Reports or application programs that require read-only or update at the data lev el must have an AUTHORITY-CHECK statement included in the ABAP code. ABAP specs should indicate the authorisation objects that are included in the AUTHORITY-CH ECK. If data security is not required, the specs should state the reasons why i t was not required. It is the responsibility of the ABAP developer to ensure that the security team is contacted for the appropriate security authorisation object to use. Once all required security checks have been incorporated in the ABAP program, they must be tested and signed off by an authorised business approver(s). ABAP specs shou ld be reviewed as part of the transport change control process. Thousands of repository objects are delivered by SAP and the majority of these a re either unsecured or are assigned to inappropriate authorisation groups. Any programs required by the user and not present on a reporting tree (releases prio r to 4.5) must be individually assigned to customer transactions. These transac tions are then protected by S_TCODE. 8. Custom Table Maintenance Security [Edit] Tables within the SAP environment are critical to the reliable and efficient pro cessing of applications. Controls surrounding the maintenance of tables will be determined by the type of information contained within the table and the potent ial impact of a change. Direct customer table maintenance SHOULD NOT be allowed in the production system via transaction SM30 or SM31. Generally, customer tables begin with Z* and mus t be protected by a Z authorisation group. Depending on business security needs , access should be controlled via a parameter or variant transaction, which may call SM30 or SM31 and skip the initial screen, or an application program. To maintain a customer table, a customer transaction must be created and a custo mer authorisation group assigned to the customer table. Then, the customer tran saction must be included in the appropriate role. Tables, customer created or S AP delivered, assigned authorisation group &nc& or spaces should be modified and assigned a Z authorisation group. Direct table maintenance via this method allows maintenance or display for ALL r ecords of the table and does not provide record level security. If record or fi eld level security is required, an application program must be written to update the table. Exceptions to the above approach must go through a very rigorous approval proces s. 1. Table Authorisation Group Naming Standard

Many tables delivered from SAP or customer tables created and not assigned an au thorisation group default to &nc&. Allowing users to access tables assigned aut horisation group &nc& will allow update or display access to a myriad of tables. Therefore, to minimize risk and based upon best practices from SAP, tables whi ch require that a user be able to either display or update should be assigned an authorisation group and not left with the default value.

Table display or maintenance is controlled by authorisation object S_TABU_ DIS. An authorisation group can be assigned to one or more tables. Transaction code SE54 is used to create/maintain authorisation groups and to assign the authorisation group to the table. The following naming standard should be applied when creating table authorisatio n groups: ZABB, where Z - Custom (required for all authorisation groups) A - Closest related SAP module abbreviations BB - Freely definable 9. Custom Transactions [Edit] All ABAP programs, reports, or table maintenance screens must be tied to a trans action code. This ensures that transaction based security (authorisation object S_TCODE) is utilised and can be incorporated in the appropriate security roles. The security team should handle the creation or maintenance of customer transact ions. This ensures that appropriate controls are in place and that the appropri ate security roles are updated with the necessary access. Custom Authorisation Objects Customer authorisation objects are sometimes needed in order to provide data lev el security to customer ABAP programs that are specific to a customer's business need. In such cases, a customer authorisation object must be created. All customer authorisation objects should be placed in a customer authorisation class Naming standards for customer authorisation objects should follow the guidelines below: Z_xxxx_aaa, where xxxx = data type / function (such as customer master, vendor master, business sp ecific data, etc). Use SAP delivered authorisation objects as a guideline. aaa = organisation level requirement (such as BUK, WRK, etc) Documentation for the authorisation object must be completed with the following information and included in the object documentation in SAP: Definition - Explains the purpose of this authorisation object. Fields - Lists out each field contained in the authorisation object and possible valid values for each field. Examples - Provide examples of use where necessary. Ensure that the customer transaction code and required customer authorisation ob jects are updated in USOBT_C/USOBX_C tables (transaction SU24). Custom ABAP Queries

Customer ABAP queries should be transported from a development system, tested in a quality and assurance system, and then promoted to production. Queries should be assigned to a reporting tree (up to release 4.5) and applied a ppropriate authorisation group security as necessary, or attached to a transacti on code (preferred). A member of the Security team should complete the report t ree or create the transaction code to ensure that the appropriate security role is updated as well. 10. Development Security Review Process [Edit] Any custom development work must flow through a security approval process to ens ure that the necessary security requirements have been implemented prior to prom otion to the Quality and Assurance (QA) system for testing. Therefore, program security, used in conjunction with reporting tree security or transaction code s ecurity, is very important in the design process. Development requests for new programs, transaction codes, report tree, or tables should include a security review to ensure that: 1) security needs are met and 2) appropriate security roles have been updated to reflect business requirements. Generally, it should follow the process outlined below: A request is approved for the ABAP team to perform work. ABAP member will contact security team to discuss proper control requirements as required by the business. Security team will work with the business requestor to determine security role to be modified. ABAP member will include proper controls, such as AUTHORITY-CHECK, as needed, in the program code. Security team member or ABAP team member, depending on customer's development te am structure, will create a transaction code (release 4.5 and later). Security team member will make appropriate profile changes. 11. Weaknesses in SAP Security [Edit] Most SAP installations develop huge amounts of custom code. This leads to securi ty problems: The code usually contains security weaknesses so an attacker can use weakness at the code level to bypass role concepts; call critical transactions and imperson ate other users; change or delete critical business data SAP GRC tools are reporting only mechanisms and do not detect such errors - they allow you to input an authorisation concept and but do not act on the implement ation at code level. Also, the sheer complexity of the SAP system often overwhelms the average SAP su pport team and this complexity is increasing by the count of tables, transaction s and security objects in each upgraded version of SAP. The business processes a re multi-dimensional and the main control of subjugation is difficult to achieve . Information is commonly stored in different places with master data, (usually su bject to intense scrutiny and monitoring) ineffective because you can modify dat a coming from master data and configuration tables at several points in a standa rd business process - so not much of a control environment. This weakness with master data is a major control challenge when implementing ef fective SAP security.