SAP Security Design

<company_name> Security Design

<company_name> SecurityDesign Document

Page 1


Document ControlAuthor Diane Davis /Ramesh Babu/Barry Roberts/Bill WadeFile Name <company_name> Security Design.doc

Version Revision Date Revision Description Author Sign-offV1 04/27/10 1st Draft of All Sections SI 1 N/AV2 11/28/10 Focus on XXX specific

decisionsRamesh B Kommaddi

Target Readership

This document is intended for anyone who has responsibility for, or has a vested interest in SAP Security & GRC Administration at XXX. This includes:

Business Executives Information Services management Technical staff Application development teams User Administration teams Help Desk teams SAP Security Administrator Internal Auditor and External Auditors Training Team and Business owners

Page 2


1. Introduction______________________________________________________________________

1.1. Purpose...............................................................................................................................4

2. Scope___________________________________________________________________________

3. <company_name> Security Practices________________________________________________

3.1. Roles and Responsibilities...............................................................................................53.2. Naming Convention...........................................................................................................53.3. General Security Approach..............................................................................................63.4. Security Testing.................................................................................................................73.5. User and Role Provisioning Processes..........................................................................73.6. Other table access.............................................................................................................8

4. Application Specific Considerations_________________________________________________

4.1. SAP ECC............................................................................................................................84.2. BW/BOB J.........................................................................................................................154.3. SAP GRC..........................................................................................................................174.4. SAP Solution Manager....................................................................................................194.5. Vertex................................................................................................................................19

5. Terminology____________________________________________________________________

6. Tables_________________________________________________________________________

6.1. Security RACI Chart........................................................................................................246.2. ECC Security Parameters..............................................................................................256.3. System Profile Parameters.............................................................................................266.4. SAP ECC Sensitive Authorization Objects..................................................................29

Page 3


1. IntroductionThis document is to describe the overall SAP Security Design that will be adopted for XXX SAP systems. This design supports the configured business processes within the XXX SAP system, whilst ensuring an adequate level of security and controls.

1.1. Purpose

The purpose of this document is to identify the high level design in order to

Define the build that will provide guidance for the build and run of SAP ECC security and GRC Provide an overview of the approach for defining the various user roles in a typical SAP

application environment. Specify particular security configuration decisions for the <company_name> solution

2. ScopeThis document refers to the Security concept within the <company_name> solution for end users.

Both the production and non-production environments are considered within the scope of the security and GRC teams.

The following systems components are considered in scope for this document:

SAP ECC SAP BW & BOBJ GRC modules implemented SAP Solution Manager

The following systems components are not in scope for this document and will follow current XXX practices for their categories, where applicable

Database and operating system security All peripheral SAP components not specified above All components associated with the operation of the IT infrastructure upon which the SAP

systems operate are out of scope of this document Disaster recovery (DR) and business continuity planning (BCP) for SAP and related components

will fall under the XXX’s current IT policies and procedures All components of systems subsidiary to and interfacing with the mySAP.com systems will be

maintained and secured following existing procedures, guidelines and standards. Business Process Controls Strategy, risk assessment and controls recommendation shall be the

responsibility of the <company_name> Process Teams and the <company_name> Internal Control and Compliance team. See the Governance Risk and Compliance Strategy Document

For non-SAP application security requirements, please refer to the standards and guidelines defined within the policies and standard operating procedures as documented on the XXX intranet.

Page 4


Page 5


3. <company_name> Security PracticesWhile specific applications will have unique security considerations, all of the <company_name> components are subject to similar practices to ensure consistency and compliance with the Security Strategy. The following areas will be common to all applications.

3.1. Roles and Responsibilities

Security and GRC Administration requires active involvement from XXX throughout the project. A Responsibility, Accountability, Consult and Inform Chart (RACI) lists the security specific roles and responsibilities for the <company_name> SAP implementation. See the Terminology area for a definition of each role listed.

3.2. Naming Convention

3.2.1. Roles

Where possible, security roles will be kept to a minimum and XXX will first use the out of the box roles provided they sufficiently address access needs and risk management concerns. When custom roles are required a consistent naming convention should be observed across all <company_name> applications as much as possible. See the role naming convention document at: https://thesource.XXX.com/sites/sharedservices/<company_name>/ImplementationTeam/Shared%20Documents/<company_name>%20Program/Realization/ICC/Security/Role%20Naming%20Conventions.docx

3.2.2. Users

Dialog users are assigned an application specific account-user master record that may be assigned one or many application roles. XXX Employees and Contractors user ids will be the same as their XXX network ID (Active Directory (ADID). Application userids will model this same convention. Each XXX employee will have one and only application userid (if needed). No generic SAP userids will be created and no userids will be allowed to be shared. Exceptions will be made for testing role functionality and model users in a non-production environment and for service/batch accounts in production. When service accounts are required to support batch processing and Tier 3 level support, a separate batch-id will be established for each process area. Jobs in production systems should not be scheduled using the individual user ids. Each business area will have at least one batch-id to run the jobs related to that area. These accounts will comply with the XXX Information Security Policy requirements.

User Groups

Page 6

https://thesource.ihs.com/sites/sharedservices/vanguard/ImplementationTeam/Shared%20Documents/Vanguard%20Program/Realization/ICC/Security/Role%20Naming%20Conventions.docx




For the SAP solutions in <company_name>, there are two types of User Groups to consider, Administrative User Groups and Authorization User Groups. The Administrative user group is used to distribute the administration of user maintenance. User administrators can be authorized to maintain specific administrative user groups. Administrative user groups do not provide the ability to grant transactional access to users. It just allows for ease of maintenance within security administration. There is no plan to use administrative user groups during the initial release. The following administrative user groups are examples of what may be created and used to assign access for these groups:

DEVELOPMENT Application Developers (ABAP) team BASIS Basis Support Team CONFIGURE Configuration Development Team HELPDESK1 Helpdesk Support Team HELPDESK2 Helpdesk Support Team SECURITY1 Security Design team SECURITY2 Security Design team TEST IDs USER All end-users DESKTOP IT Desktop Support Technical team

The second type of user groups is the authorization user group which is used to assign roles to groups of people at one time. For <company_name> use of ECC, there is no plan to use this type of group during the initial releases. The preference is to assign to the end user due to the need to be flexible with assignment of task based roles.

3.3. General Security Approach

The security design and build is based on an approach with the goal of reducing risk of access to sensitive areas, content while complying with XXX IT Security Policies and Procedures. To align with the internal control requirements and prevent potential deficiencies that can impact an organization, user functions will be segregated with respect to the user’s job descriptions and responsibilities. In general, transactions with a very high sensitivity (IT and Business Sensitive Transactions) will not be combined with other transactions. Unique use of transactions per role is the preferred approach with duplication of transactions within other roles only when no other alternative is present. The role definition process will provide a high level of flexibility, visibility and control to appropriately manage the high-risk transactions and remediate users when necessary.

For each of the in-scope systems, transactions, queries, reports and web addresses, etc. will be included into the role menu. The XXX <company_name> approach to security is to follow standard SDLC methodology that includes “Design, Build, and Test”. The approach took into account:

Transactions listed by process and role Role Build Templates Org level security is high maintenance for user provisioning and therefore has been

determined within XXX that the benefits do not outweigh the costs. XXX will use the Profile Generator as a tool to develop authorization profiles. Once activities

have been saved in a role, the profile generator is used to generate the necessary authorizations and profiles. If a Security Role contains more than 150 authorizations, the profile generator will automatically create additional profiles.

Roles will be directly assigned to a user. <company_name> Training will identify the “to be” operational job function for job role

mapping. Security will collaborate to map task based roles to the specified function in time for UAT

Page 7


Observe best practices where possible:o Limited use of * wildcards for administering roles. Unless there is a thorough

understanding of the scope of transactions or field values a wildcard represents, the use of wildcards can lead to the granting of unintentional access.

o Minimize use of child roles to avoid breakage of parent – child relationship. o Identify sensitive data and restrict access to transactions/reports capable of

accessing that data. o Group like functions together into single roles. o Follow principle of least privilegeo Ensure correct naming convention is used.o Add tcode (s) in alphabetical order to the folder in Role Menu.o XXX will use the default profile names which start with t, unless a custom profile

name has already been assigned to a role/o Do not maintain/update authorization field values that would result in Changed

objects (as opposed to standard or Maintained) without assessing the situation.o Do not manually insert authorization objects without assessing the situation/change

requirementso Role descriptions are to be kept current with the latest changeo Role Owner approval will be obtained before any role modification.

3.4. Security Testing

A security testing strategy will be coordinated with the overall project testing strategy for the appropriate cycle and type of testing. Security testing will consist of:

Unit Testing Integration Testing User Acceptance Testing

During each phase, the Security Team will resolve appropriate authorization failures and make the appropriate changes and/or modifications to the levels associated with each Role per the testing feedback. Considerations for job role mapping will be coordinated with the Testing and Training teams to ensure consistency in the testing objectives and efficient use of the resources deployed for all these areas simultaneously. Role owner approval of role definitions and role assignments will be a required output from the testing cycles. See the Testing Strategy document for specific objectives per testing cycle.

3.5. User and Role Provisioning Processes

Role builds will follow controls defined in the GRC Role Build and Provisioning PDD’s. <company_name> will utilize the GRC RAR simulation functionality to prospectively identify potential SOD risks before role or provisioning efforts are made for ECC. This is a new capability to XXX that will increase role owner visibility and improve work efficiency. Security role builds will utilize the change management controls specified in the GRC Change Management PDD. Security role builds must be transported using the transport process defined.

Page 8

https://thesource.ihs.com/sites/sharedservices/vanguard/ImplementationTeam/Shared%20Documents/Vanguard%20Program/Realization/ICC/Security/Security%20Test%20Insert.docx


3.6. Other table access

Access to tables can occur at the database layer. As such, <company_name> will implement alternative procedures consistent with legacy SOX systems to monitor highly privileged access at the database and server layers. Associated security will follow principle of least privilege and will be reviewed in accordance with IT Global Policy. Access to databases requires approvals as stated in the XXX IT Information Security Policy.

4. Application Specific Considerations

4.1. SAP ECC

ECC is a transactional processing system and most of the action is based on the use of transactions. For ECC, the transactions that have been selected for a role are entered in the menu of the role and the profile generator includes in the authorization data all of the authorization objects that are checked for these transactions. The authorization objects that are brought in to the Profile Generator are about 90-95 percent of what is needed to be considered complete.

4.1.1. Overview

In addition to the general approach for security, the ECC security design and build aims to reduce and potentially eliminate the existence of segregation of duties conflicts within the SAP technical design while adhering to

GRC Access Controls best practice Observance of identified critical sensitive transaction codes

ECC will deploy a compliant security build. Authorization object level access control rules based on the data needed to be accessed will be incorporated around these transactions to provide more granular protection. The ECC build consists of:

Transactions listed within the PDDs or BPPs RICEF Object and sensitive transaction areas identified by best practice resources. Creation of small task-based roles that are free of SOD violations Utilization of the GRC RAR for SOD reviews prior to deployment for role and user

reviews for SAP ECC security Roles will be defined based on a task. Therefore, tasks are assigned to a role

owner having significant functional knowledge of what is required to perform the task. See the detailed security role build.

Use SU24 Maintenance process. Avoid inserting objects manually. Composite roles reduces visibility within roles, therefore limit their use SOD tools interpret the use of * wildcards for administering roles or authorizations

widely which causes issues around SOD and excessive access. Single roles containing similar functions/transactions can be more easily added or

removed from composite roles. Single roles containing dissimilar functions/transactions will typically require more analysis to determine whether a transaction can added or removed.

Limited use derived roles to represent similar job roles. Derived roles are derived from parent roles. Changes to parent roles automatically transfer to derived roles, thus simplifying role maintenance.

Use of composite roles will be used where consistency in the combination of roles warrants this structure for maintenance

Page 9

IHS, 01/16/11,

Insert hyperlink to role build

IHS, 01/17/11,

hyperlink


Use of single roles instead of master roles because derived roles will not be used for org level.

All reports or programs for end users to run will be assigned to a transaction.

Only those people with active user master records can access the system. User ids, roles, profiles, transaction codes and authorization objects protect the system from unauthorized access. Roles are created and maintained via transaction PFCG. Profiles can be created manually using transaction SU02 and automatically by using SAP Profile Generator. It will be XXX’s policy to rely on Profile Generator for creation of security profiles whenever possible as per our systems integrator leading practice design.

SAP transactions are secured through three methods:1. System access to execute the transaction2. Check object for activity to execute the transaction3. Authority checks within the supporting ABAP/4 program

All three of these must be taken into consideration when administering transaction level security.

4.1.2. Authorizations Objects

An authorization object is a template for testing access privileges. It groups up to 10 fields and tests for execution rights utilizing AND-logic in programs to see if a user has the right to carry out an action. A user's action is approved only if the user passes the access test for each field listed in an object. Authorization objects can be described as:

Entities defined by SAP which secure or protect transactions. Consists of fields whose values determine the type of access granted for specific

transactions.Fields identify an element of the system that is to be protected by an access test.SAP has pre-defined sets of authorization objects for each of the SAP modules.

Example: an authorization object for securing accounting documents identifies the type of document that can be processed (invoice, customer payment, credit memo, etc.) and what type of processing can be performed with the document (create, change, display, delete, etc.).

The authorization objects used to secure transactions are dependent on the functional area being executed. There are approximately 22 object classes used to logically group the SAP supplied authorization objects. Refer to the SAP supplied on-line documentation or an actual client for a detailed listing. The objects are maintained in the table TOBJ and can be viewed via transaction SE16.

The system access to execute the transaction is controlled by the authorization object S_TCODE. This particular object requires that the transactions needed for a user, position or role be explicitly defined. This means, that if a user needs access to transactions FB01, FB02, and FB03, then these transactions must be specifically stated. Alternatively, putting in the value of FB* can provide the same access but is not recommended anywhere but in the development environment

4.1.3. Authorization and Field Values

Page 10


An authorization is a set of permissible values that grant system access privileges based upon an authorization object. A user is permitted to perform an action only if he/she passes the test for each field in an authorization object. In this way, objects allow complex, multi-conditional testing of user access privileges. Creating a unique name and assigning values to the fields that are defined for the object create an authorization for an authorization object. Values determine the actions that are permissible. Authorizations must be assigned to simple profiles.

Example: A G/L account authorization object has two fields to which varying degrees of access can be granted, Activity and Company Code. An authorization could be created with a value of 03 (display) assigned to the Activity field and a value assigned to the Company Code field. This authorization would be assigned to a single profile along with the other authorizations required to access G/L accounts.

4.1.4. Authority Check in Custom ABAP

Much of the data in an ECC6 system has to be protected so that unauthorized users cannot access it. Therefore, the appropriate authorization is required before a user can carry out certain actions in the system. When you log on to the ECC6 system, the system checks in the user master record to see which transactions you are authorized to use. An authorization check is implemented for every transaction. In addition to transaction code, the ECC authorization concept includes other authorization objects to secure activities (create, display, delete, modify, etc.), to restrict access to specific parts of the organizations data (Company Code, Plant, etc.) All custom programs, SAP scripts, and interface routines are required to use appropriate authority checks. Prior to the configuration and security being transported to the QA system, the Security Team and Functional Team will verify that the authority checks are in place and functioning adequately.

ECC performs authority checks to ensure execution of the code with security considerations. During the creation process XXX will perform the following when creating new authority checks:

1. Evaluate the need to create new authorization objects or use existing objects2. If necessary, create the new authorization objects and associate them with an

existing object class. All new objects must be transported across the entire system client landscape

3. Identify the values necessary to execute the program4. Identify the position or role that should have access to execute this program, this

may be dependent on each client5. If necessary, add the transaction code to the SAP ECC Profile Generator using

SU246. If using the profile generator, generate the new activity group necessary to execute

the program7. If necessary, create the manual authorizations and profiles necessary to execute

the program8. Transport the profile and/or activity group across the system client landscape

4.1.5. Activation Concept

Profiles and authorizations exist in maintenance and active versions in the system. When creating or editing a profile or authorization, the maintenance version is being used. This concept helps prevent errors in defining or editing authorizations from affecting the system. Changes to profiles and authorizations have to be “activated” or generated before they go in to affect

Page 11


4.1.6. System Security Parameters

The SAP Security Administrator must periodically check the SAP ECC system parameters on each instance. This can be accomplished by using transaction SE38 to execute the ABAP/4 program RSPARAM on each system. In particular, the SAP Security Administrator must verify that the following system parameters are set appropriately. SAP has specific default parameters in the system that can be tailored for each instance. You can use these system profile parameters to set password characteristics, incorrect logon limits, and the default client. The following parameters are presented for later review. Additional details and recommendation can be found in SAP ECC Security Parameters Table. Note: Parameters apply to both the ECC6 and BW systems.

4.1.7. Custom Transactions

There are two minimum requirements for all new custom transactions: S_TCODE must be activated All new transaction must have a check object assigned to them (Table TSTCA)

Creation of custom transactions will follow the process defined in the GRC Role Creation PDD. The following are the necessary steps to establish a check object for a new transaction

1. Review the existing authorization objects to determine the ability to use an SAP supplied object

2. If necessary, create the new authorization object 3. Execute transaction SE934. Enter the new transaction code and click on the ‘Maintain’ icon5. Enter the authorization object selected to be the check object6. Enter the field level values required

Note, this information can be manually entered into the table TSTCA via transaction SE16.

4.1.8. Sensitive Transactions

There are specific transactions contained within SAP that are considered sensitive and powerful in nature. The misuse of these transactions within the system could negatively affect the performance and integrity of the system by providing users with powerful rights. It is important to understand the risks associated with sensitive transactions. The security team will make sure those transactions are accounted for in the SAP GRC RAR rule set. GRC Process Controls will be used for the IT Basis critical areas for Release 1.

4.1.9. Sensitive IDs & Profiles

In addition to monitoring sensitive transactions, SAP has a several powerful userids and profiles that should be monitored closely for appropriate use. Powerful ids will not be granted to individuals in production. In the rare circumstance where it is required, GRC SPM controls will be used to allow for a mitigating control of the activity performed. In non-production environments, these ID’s will be highly restricted to technical personnel only and assigned only as needed for the limited time needed to perform mandatory functions not able to be performed under the properly provisioned ID. Segregation of duties and observance of highly confidential information must be taken into consideration in all environments. The following is a list of SAP ID and profiles should be restricted:

Page 12


Type Detail

Profile SAP_ALL

SAP_NEWS_A.SYSTEMS_A.ADMINS_A.USERS_A.CPIC

S_A.CUSTOMIZ

S_A.TMSADM

S_A.TMSCFG

S_A.TMSWFID SAPCPIC

SAP*

DDIC

EARLYWATCH

Page 13


4.1.10. Restricted Authorization Objects

In addition to powerful IDs and profiles with SAP, there are some authorization objects that should be closely monitored. These authorization objects are considered sensitive in nature. The misuse of these authorization objects within the system could negatively affect the performance and integrity of the system. Some transaction codes do require authorization to some of these objects. However, careful consideration should be taken wherever access is granted. See SAP ECC Sensitive Authorization Objects Table.

4.1.11. Program Security

Programs in SAP are written in a standard fourth generation called ABAP/4; this language was created by SAP and is the foundation for all functionality in SAP. Access to create, maintain and execute ABAP/4 programs will be restricted to those individuals properly trained. Use of ABAP/4 will follow SAP development standards. Access to ABAP/4 programs will be granted based on three elements:

1. Type of access being requested (display, maintain, execute)2. Client where requested3. User making the request

Custom programs will be assigned to custom T-codes which will follow the GRC Role PDD requiring these to be incorporated into an ECC role. XXX will not utilize additional maintenance/assignments at the object or authorization group levels.

4.1.12. Table Security

The ability to perform configuration or view raw SAP data requires access to specific tables within SAP. The ability to maintain table level data affects the integrity and accuracy of information maintained by SAP. Changes to tables must take into consideration the XXX Change Management Policy and therefore access at the application layer will be tightly controlled to protect the integrity, reliability and consistency of the results of the underlying transactional system. Considerations for access will take into account the instance and client needed for compliance purposes. At the application layer, there are two general definitions of tables each having unique security requirements in SAP: client dependent and client independent. When making changes to client dependent tables/data, you only impact the client that you are currently logged into when making the changes. When making a change to a client independent table (T000), you impact every client within that particular instance. When the GUI level access is provisioned, the following should be followed (transaction SE16 and SM31).

I. Development Instance

Limited table access to the user allowed to perform configuration Within the ABAP client, grant the ABAP programmer client dependent table

access Client independent table access should be limited to the key people within the

configuration master client Restrict all users, in every client from having access to Basis and Security related

tables, authorization groups starting with an ‘S’

II. Integration/QA

Allow display access to tables

Page 14


There should be no configuration allowed based on client settings

III. Production

Display only No configuration allowed based on the client settings Functionality within the Profile Generator is considered configuration and may

require special procedures

4.1.13. Table Query Security

SQVI table queries provide powerful SE16 like access into ECC tables which can result in negative system performance. As a result, <company_name> will deploy reporting solutions for adhoc query that may involve other tools than ECC where performance can be better controlled. Access to ECC queries will be limited based on critical business need.

4.1.14. Table Authorization Object Security

Client dependent table access is controlled through the SAP supplied authorization object S_TABU_DIS with two fields: activity and authorization group. There are three basic activities – 01 create, 02 change and 03 display. The authorization group is the key to ensuring that a user only has access to the tables that is required to perform their function or job responsibility. The critical authorization group that should always be restricted is that starting with ‘S’. All SAP basis and security related tables are assigned to an authorization group starting with ‘S’. The SAP supplied authorization object S_TABU_CLI controls access to client independent (cross client) tables. Granting access to configure/maintain client independent cross client should be properly approved and review by the Basis team. This particular object consists of a single field, which a value of “X” grants a user the ability to configure/maintain client independent tables.

4.1.15. Role Build Sequential Process

In order to develop the detailed role build matrix used as the foundation for develop security roles, the process used included…..

4.2. BW/BOB J

The BW system is an analytical processing system that performs complex calculations on data stored in it. As a data warehouse, it does not use transactions the way that ECC does but instead uses three primary types of restrictions to secure reports.

4.2.1. Overview

BW roles can be restricted by the BW structural elements – InfoAreas and InfoCubes. This type of specification gives access to all of the data housed in the InfoArea(s) or InfoCube(s) specified. To be consistent with the overall Security Strategy, organization level (i.e., plant, company, etc) will not be integrated into the design and therefore will also not be built into BW. The security structure for BW is intended to restrict normal functionality where it is important to protect the integrity of the results, but not to restrict similar content. A role in BW typically identifies a collection of reports and queries for a specific business area. Roles

Page 15


often correspond to job titles. Roles are associated with tasks and include all activities that are carried out by the respective users.

The vast majority of XXX’s BW end users will never directly logon to the BW system using the SAPGui but will login from the BOBJ front end,

4.2.2. BW Security Strategy

The strategy for ensuring security in the Business Warehouse is based on a two-part approach that distinguishes between different types of users and the various types of queries or reports they are authorized to read/change/create. BW users can be thought of in three broad groups. These groups are aligned with the nature of their required BW usage according to their job responsibilities. The first group consists of those who go into the BO system accessed through BO infoview to display or execute reports that have been created for them (End Users or Report Users). The second group consists of those who will create queries and reports to be used by them or for the general use of others within their organization (Power Users or Report/Query Creators). The third group consists of those who will administer the BW system. This group generally consists of Basis and Security Administrators. Both End Users and Power Users will be assigned to one or more specific role as required by their XXX responsibilities. When the user logs into the Business Warehouse environment, the user will only see the menu for the access that has been granted via the assigned role.

The first step is to identify the roles that need to be created and what the users will need to access for each role. The simplest way to give access to the End Users is by info provider.

For EX: GL Users will have access to GL cubes. Once the Role has been created and users assigned to that role, authorizations are generated to enable access to the Business Warehouse. .

Power User roles will also need to be defined with the ability to create, change and display queries and reports both for themselves and others in their department. BW Authorization Objects

BW Reporting Authorizations will be based on hierarchy of authorizations as defined in the PDDs a spreadsheet will be used to assign the end user roles to individual users as part of the overall role to job position matrix.

4.2.3. BW Reporting Roles

The 2 main groupings will be called Menu Roles and Security Roles. The menu roles will define the folders that users will see (in addition to their favorites). There are no authorization profiles defined for menu roles. The different security roles may be defined to allow access to an Infoprovider. The idea is to give functional area access to begin with and then build it up by giving appropriate security roles for an individual to perform his/her function. Defining security for BW users becomes a simple exercise of combining the appropriate Menu and Security roles.

When developing report queries, developers should be aware of the defined authorization relevant InfoObjects. All InfoCubes attached to any of these authorization objects require special consideration.

Page 16


4.2.4. BW Administrator Roles

The Administrator users will have the same roles as they have in R3 system as the Basis and Security activities are common to both. There will be a BW specific delta role built and assigned to Basis and Security users to cover any access needs arising out of special t-codes unique to BW environment.

4.2.5. SAP BOBJ Security






4.3. SAP GRC

<company_name> will implement the following SAP GRC Modules during Release 1:

SAP GRC Risk Analysis and Remediation (RAR) SAP GRC Super User Privilege Management (SPM) SAP Process Controls (PC)

All modules will have a small number of users. Administrator rights for will be restricted to just a few individuals. For business users of each tool, security rights with update capability will be given based on just on the functions that each user actually needs to complete his/her job.

Subsequent releases of RAR may include Complaint User Provisioning (CUP) and Enterprise Role Management (ERM). See the GRC Strategy & Design Document. CUP may have hundreds of users depending on the configuration since CUP is a tool that helps provide automation for user provisioning process. ERM is typically just used by basis/security users to help build security using pre-defined leading practices. For Release 1, XXX will not deploy these features of RAR.

4.3.1. Overview

There are 2 different types of roles needed for GRC – Front-end and Back-End Roles. See the GRC Role Build.

Front-end Roles - Front-end roles grant application rights to configure and run the tool Back-end Roles - Back End roles are used with ECC for SPM to provide certain

master data update functionality needed to run the tool

GRC is a java based tool that has security administered using the SAP User Management Engine (UME) for the front-end roles. UME provides a portal like security. GRC comes with preconfigured UME roles which contains various UME actions. These UME roles can be assigned to the UME user ids directly or may be copied in to a custom role and then assigned to the UME users. Customization of these roles is typically not needed. However, it is leading practice to copy the standard GRC UME roles into custom UME roles

Page 17

IHS, 01/17/11,

Diane hyperlink

https://thesource.ihs.com/sites/sharedservices/vanguard/ImplementationTeam/Shared%20Documents/Vanguard%20Program/Realization/ICC/GRC/GRC%20Delivered%20roles%20.xlsx


to prevent any issues related to GRC upgrades. UME roles will be assigned to users based on need. Where possible, XXX will use out of the box GRC roles. At a minimum the main users for GRC are as follows:

Function Modules Level of Access

System Administrator

All Full

SOX Finance All Read

Internal Audit All Read

Role Owners RAR SOD/CUP

Firefighter Support SPM TBD based on function

4.3.2. GRC RAR

XXX’s GRC Risk Analysis and Remediation is a web-based, fully automated security audit and segregation of duties (SoD) analysis application. It provides the largest and most comprehensive database of SoD rules available for SAP. Risk Analysis and Remediation can be used to identify, analyze, and resolve all SoDs and audit issues relating to regulatory compliance. The typical roles and functions assigned for RAR include administrator, Security Admin, control monitor and SOD reporting by using standard UME RAR roles including VIRSA_CC_ADMINISTRATOR, VIRSA_CC_SECURITY_ ADMIN, VIRSA_CC_REPORT and VIRSA_CC_BUSINESS_OWNER and custom roles will be made (if required).

4.3.3. GRC SPM

Super User Privilege Management enables users to perform emergency activities outside their role as a “privileged User”. SPM provides the solution for systematic handling of all emergency situations in a controlled and auditable environment. The typical roles and functions assigned for SPM include SPM User role, SPM Owner role and SPM Administrator role.

4.3.4. GRC PC

text

.

Page 18

IHS, 01/17/11,

Protiviti to advise







GRC configuration will follow best practice and minimization of customizations. Default settings will be evaluated to ensure associated risks are being managed in according with <company_name> Control requirements. See the GRC Configuration Document.

4.4. SAP Solution Manager

Text

4.4.1. Overview






4.5. Vertex

Text

Page 19

IHS, 07/08/22,

Bill to provide

IHS, 01/29/11,

Scott Rolfs to do

GXB37508, 11/24/22,

Ramesh to hyperlink – Update : The document is in progress (not yet ready)


4.5.1. Overview






4.6. Process Integration (PI)

Text

4.6.1. Overview






5. TerminologyAuthorization A set of authorization object specific values that allow a user to perform

certain functions within the XXX system.

Authorization fields Values used to define an authorization for an authorization object

Authorization objectA system template for authorization that relates to a particular system object. Authorization objects consist of fields for specific values relating to certain data or activity with that data.

Authorization profile A group of up to 150 authorizations that are automatically generated via the Profile Generator. If a Role contains more than 150 authorizations, more than one profile is generated

Data Owner The data owners are responsible for protecting (controlling access to) the transactions, tables, and reports that they own.

Functional Team Member of the core development team, with responsibility for a specific

Page 20

dpa25840, 02/25/11,

Michael wei to fill in something


functional area and specifying security requirements from a business perspective.

Governance Risk and Compliance (GRC) Team

A member of the ICC is responsible for establishing the security strategy, GRC strategy, related designs and establishing the associated administration processes.

Profiles A security profile is a collection of Authorization Objects and Authorizations Values.

Role Single Roles consist of authorization profiles, which are generated using the Profile Generator tool. Roles can be directly assigned to user ids.

Role-CompositeConsists of a collection of single/individual roles grouped together. As such, these do not have authorizations or profiles directly assigned to them. Composite Roles may be directly assigned to user ids.

Role-Master May be created for a generic job role (e.g. Accounts Payable Clerk) or task based roles (e.g. Create Vendor) and may be used as a template. If a role is to be used for multiple divisions where each clerk would perform the same functions, but should be restricted to data for their own division, a role will be derived from the Master role.

Role-Simple Single roles consist of one or many authorizations that are required by the SAP system in order to perform transactions (single profile).

Role Owner A business representative assigned with responsibility for certain roles and the assignments of those roles to end users for a functional area.

Security Roles A security role is a collection of linked or associated activities, such as tasks, reports, and transactions. A role is a data container for the SAP Profile Generator to generate authorization profiles and usually represent either a task or job role in the company. A particular task or job may consist of one or more profiles

Security Team Member of the Technical Services team, and is responsible for the security administration process.

System Support Application support having three primary pieces.

The Global Service Center (GSC) - first line of support and the focal point for receiving security requests and problems. The GSC handles the initial contact with end users for all support requests and provides ticketing and escalation support.

XXX SAP Support (Support) provides technical information or support. Support personnel diagnose and document user access issues, troubleshoot user access issues, route requests to appropriate queues based on escalation process flows and provide assistance regarding

Page 21


Basis Administrators perform critical application functions except configuring users, profiles and authorizations. These users have access to perform ABAP functions and full access to all needed SAP transactions, tables and client independent tables to complete their job function on a day-to-day basis.

<company_name> Internal Controls and Compliance (ICC)

Responsible for monitoring that XXX practices are followed and that XXX information resources are properly protected.

User-Dialog Application users that can log on to specific application

User-End Have functional access based on transactions and hierarchy. Access is defined based on job responsibilities, positions within XXX’s organizational structure and environment utilization (i.e., production vs. stage). Access is further restricted based upon segregation of duties restrictions identified by ICC.

User Id Represents the User Identification in the XXX system. User Id’s are required to log on to XXX systems

User group User groups facilitate the process for user reporting within the XXX system. User groups enable security administration of users within the specified user group

User master recordEach user has a unique user account called a master record. A user master record contains a user’s personal data such as name, surname, address, and other often used system parameters such as printer preferences, system access rights, etc. The user master record is automatically associated with a userid.

Page 22


6. Tables

6.1. Security RACI Chart

Task

ICC

GR

C T

eam

Sec

uri

ty

Tea

m

Fu

nct

ion

al

Tea

m

Ro

le O

wn

er

Dat

a O

wn

er

Sys

tem

S

up

po

rt

Establish security review activities A R I

Design security builds A R I C

Configure/Modify security builds R, A I

Ensure critical activities are not combined. A R I

Provision users for <company_name> components and environments.

R A

Identify potential compliance issues A R

Assist the security team in preparing for an audit. R, A

Security is compliant with XXX policies. A R I

Define & document SAP Security and GRC Administration processes

A R R I I C

Obtain approval for the defined processes R, A I I I

Communicate the SAP Security & GRC Administration processes to stakeholders

R, A I I I I I

Resolve complex situations A R R

Define and document security and GRC architecture A R R

Review the design documents for completeness of Security and GRC requirements

R,A C C C

Provide system administration knowledge for post release administration

A R R I

Support Security Testing resolution A I R I C

Specify business needs for access to area I I I R C R

Define navigation expectations impacted by security design

I I R I

Understand security capability to area of responsibility C I R A A I

Assign access to user for area of responsibility C R A A

Security tests results successful C R I A

Role training C R, A

Access Reviews I C R, A R, A I

Validate accuracy of content C I R, A

Page 23


6.2. ECC Security Parameters

Parameter Descriptionlogin/min_password_lng This parameter is used to specify the minimum length of a password. The

Default is three characters. You can set it to any value from 3 to 8. The minimum length will be set to 6 characters. SAP also provides a mechanism for additional customization of password restrictions. Using transaction SM30 and maintaining table USR40, password restrictions for acceptable values may be implemented. Table USR40 is used during logon validation procedures and password checking to make sure the password does not violate any of the guidelines. USR40 is a table with impermissible values. There are two wild card characters that may be used (“?” represents any single character and “*” represents a sequence of any combination of characters of any length.) For XXX, the setting will be 8 characters

login/password_expiration_time

This parameter is used to specify the number of days after which a password must be changed. The SAP default is zero, which never requires the user to change their password. Users should be required to periodically change their password every 30 days. For XXX, the setting will be 90 days

login/fails_to_session_end

Defines the number of unsuccessful logon attempts before the system does not allow any more logon attempts. The SAP default is 3 and can be set to any value between 1 and 99. The typical approach is to permit three attempts. For XXX, the setting will be 3 times

login/fails_to_user_lock This parameter is used to specify the number of times that a user can enter

an incorrect password before the system locks the user against further logon attempts. The SAP default is 12 and can be set to any value between 1 and 99. For XXX, the setting will be 3 times

login/failed_user_auto_unlock

Defines whether user locks due to unsuccessful logon attempts should be automatically removed at midnight. For XXX, the setting will be set to no=0

login/system_clientThis parameter is used to specify the default client. This client is automatically filled in on the system log on screen. Users can type in a different client.

login/no_automatic_user_sap*

This parameter is used to restrict special default properties for SAP*. If the parameter is reset to 0, it would allow logins with SAP*, password “PASS”, and unrestricted system access privileges. The parameter should be set to 1.

rdisp/gui_auto_logoutThis parameter is used to specify the number of seconds before automatically disconnecting inactive users from the system. The SAP default for all instances is 0 and each instance may require a higher setting. This time represents the number of seconds.

Page 24


auth/no_check_in_some_cases

This parameter is used to enable SU24 to activate authorization checks for transactions and to work with the Profile Generator. By default, the function is inactive and the parameter value is N. To activate, the parameter should be set to value Y.

login/ext_securityExternal security activated

auth/no_check_on_tcode This parameter is used to check on object S_TCODE. In certain cases, this

can be shut off, but this results in a big security risk for the system. By default, the function is inactive, and the parameter value is N. To activate, the parameter should be set to value Y.

Auth/tcodes_not_checked Transaction codes that can run without the proper authorization. Examples

maybe SU53 and SU56 that helps analyze authorization failures when a user can’t run a transaction

6.3. System Profile Parameters

XXX Values

PARAMETER DESCRIPTION

Pro

d

QA

DE

V

SA

P

Def

ault

Login/fails_to_session_end Number of times a user can enter an incorrect password before the system terminates the logon attempt. Default is 3.

3 4 4 3

Login/fails_to_user_lock Number of times a user can enter an incorrect password before the system locks the user against further logon attempts. The lock is released at midnight. The default is 12.

3 6 6 12

Login/system_client Specifies the default client. This client is automatically filled in on the system logon screen. Users can overwrite this.

100

Login/failed_user_auto_unlock Enable automatic unlock of locked users at midnight. Default is 1 – allowed

0 0 0 1

Login/min_password_lng Minimum length of a password. Default is 3. Any values from 2 - 8. SAP also provides a mechanism for additional customization of password restrictions. See Security Strategy document for details.

6 6 6 3

Page 25


XXX Values


Pro

d

QA

DE

V

SA

P

Def

ault

Login/password_expiration_time

Number of days after which a password must be changed. When the expiration time is reached, the user is asked to enter a new password. Default is '0' - no time limit.

60 90 90 0

Login/no_automatic_user_sap* Disables special properties for user SAP* when this parameter is set to a value greater than zero. When the parameter is reset to 0, it would allow logins with SAP* using the default delivered password and unrestricted system access privileges. The default is 0 - permitted.

1 1 1 0

Rdisp/gui_auto_logout Specifies the number of seconds a user session can be idle before being automatically logged off by the system. Default is 0

900 1800 1800 0

auth/no_check_in_some_cases Used to enable SU24 to activate authorization checks for transactions and to work with the Profile Generator. Default is N.

Y Y Y N

auth/no_check_on_tcode Checks on object S_TCODE. In certain cases, this can be shut off, but it results in a big security risk for the system. Default is N. Do not change unless absolutely necessary.

N N N N

Auth/check_value_write_on Enables the transaction for authorization analysis SU53, when this parameter is set to a value greater than zero. This is highly recommended as it is the key to determining and resolving SAP ECC6 authorization issues and is essential for Security Administrators

1 1 1

DEFAULT.PFL To make the parameters globally effective in a SAP system, set them in the default profile. To make them instance-specific, you set them in the profiles of each application server in your SAP system.

Auth/authorisation_trace Enables easier diagnosis of security failures since allows running of System Trace (transaction ST01).

Y Y Y

login/disable_multi_gui_login Disable multiple sapgui logons (for same ECC6 account). Default is '0' - off.

0 1 1 0

Page 26


XXX Values


Pro

d

QA

DE

V

SA

P

Def

ault

Rdisp/gui_cleanup_delay Hold user session information after session termination. Set to the value of '0' if preventing multiple dialog logons

0

Page 27


6.4. SAP ECC Sensitive Authorization Objects

SAP Standard Authorization Object

Description

S_ADMI_FCD Allows various system administration functionsS_BDC_MONI Allows to manipulate batch jobsS_BTCH_ADM Enables control Batch Jobs in all clientsS_BTCH_ADM This object for Background Administrator ID with value ‘Y’ should be

only given to Basis team and special users that process background processes like cutting checks and mass processing vendors.

S_CTS_ADMI Access to perform administration functions in transport systemS_DATASET Only certain programs should be allowed to access data files. The

field ABAP: program name should be limited to the program name. Often this object is used in custom transactions (starting with ‘Z’). For those a system trace ST01 has to be performed in DEV QA.

S_DEVELOP Permits ABAP development. ‘Activity’ field is critical. End users should only have value 03 – Display

S_IMG_ACTV Authorization to perform IMG functionsS_LOG_COM Authorization to execute Logical Operating system commandsS_PROGRAM Allows specified programs or reports nodes to be called. When this

object is used most roles should have limitation only to the specific program or report node that is necessary to call. This can be achieved by using authorization groups defined by developers.

S_QUERY Authorization for SAP QueriesS_TABU_CLI Ability to maintain client independent tablesS_TABU_DIS Ability to display or change tables. If a user has access to

transactions SM30, SM31 or SE16, this object should be used with authorization groups for tables. Authorization Administrator can specify authorization groups by using SE54. The value 02 - change access should be granted with special care and authorization from the process owner and system owner, and it should never be used without authorization groups

S_TCODE Access rights to start transactions and should never have value ‘*’ - All for end users, but instead it should have the definition of transaction that the user needs to perform.

S_TRANSPRTS_NUMBER

Access to transport systemNumber Range maintenance

S_USER_AGR Ability to maintain and display rolesS_USER_AUT Ability to display profiles and their change history. This object

should be only used with display ability. Only Security Administration should have all access rights for this object.

S_USER_GRP Ability to display changes to all user master data. This object is only granted with display ability. Only the PA Administration and Security Administration should have the change ability. Help desk should have lock / unlock and password change ability.

Page 28


SAP Standard Authorization Object

Description

S_USER_OBJ Ability to globally deactivate authorization objectsS_USER_PRO Ability to display profiles and their change history. This object

should be only used with display ability. Only Security Administration should have all access rights for this object.

Page 29

Date post:	26-Mar-2015
Category:	Documents
Upload:	jose-garcia
View:	2,725 times
Download:	19 times